Re: Is read barrier missed in kfifo?

[Stefani Seibold]

My guts thinks you are right. Feel free to send a patch...

Am Freitag, den 11.05.2018, 15:25 +0800 schrieb Xiao Guangrong:
> Hi,
> 
> Currently, there is no read barrier between reading the index
> (kfifo.in) and fetching the real data from the fifo.
> 
> I am afraid that will cause the vfifo is observed as not empty
> however the data is not actually ready for read. Right?
> 
> Thanks!

Re: Is read barrier missed in kfifo?

[Stefani Seibold]

My guts thinks you are right. Feel free to send a patch...

Am Freitag, den 11.05.2018, 15:25 +0800 schrieb Xiao Guangrong:
> Hi,
> 
> Currently, there is no read barrier between reading the index
> (kfifo.in) and fetching the real data from the fifo.
> 
> I am afraid that will cause the vfifo is observed as not empty
> however the data is not actually ready for read. Right?
> 
> Thanks!

Re: [PATCH v3 26/26] kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit

[Stefani Seibold]

On Thu, 2017-11-30 at 10:29 -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 10 Oct 2017 09:59:42 +0200
> Sean Young <s...@mess.org> escreveu:
> 
> > If you try to store u64 in a kfifo (or a struct with u64 members),
> > then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes
> > padding due to alignment (note that struct __kfifo is 20 bytes
> > on 32 bit).
> > 
> > That in turn causes the __is_kfifo_ptr() to fail, which is caught
> > by kfifo_alloc(), which now returns EINVAL.
> > 
> > So, ensure that __is_kfifo_ptr() compares to the right structure.
> > 
> > Signed-off-by: Sean Young <s...@mess.org>
> > Acked-by: Stefani Seibold <stef...@seibold.net>
> 
> Hi Stefani/Andrew,
> 
> As this patch is required for the LIRC rework, would be ok if I would
> merge it via the media tree?
> 

It is okay by me. But the question remains why this patch wasn't
already merged?

Andrew: Any objections against this patch?


> > 
> > ---
> >  include/linux/kfifo.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
> > index 41eb6fdf87a8..86b5fb08e96c 100644
> > --- a/include/linux/kfifo.h
> > +++ b/include/linux/kfifo.h
> > @@ -113,7 +113,8 @@ struct kfifo_rec_ptr_2
> > __STRUCT_KFIFO_PTR(unsigned char, 2, void);
> >   * array is a part of the structure and the fifo type where the
> > array is
> >   * outside of the fifo structure.
> >   */
> > -#define__is_kfifo_ptr(fifo)(sizeof(*fifo) ==
> > sizeof(struct __kfifo))
> > +#define__is_kfifo_ptr(fifo) \
> > +   (sizeof(*fifo) == sizeof(STRUCT_KFIFO_PTR(typeof(*(fifo)-
> > >type
> >  
> >  /**
> >   * DECLARE_KFIFO_PTR - macro to declare a fifo pointer object
> 
> 
> 
> Thanks,
> Mauro

Re: [PATCH v3 26/26] kfifo: DECLARE_KIFO_PTR(fifo, u64) does not work on arm 32 bit

[Stefani Seibold]

On Thu, 2017-11-30 at 10:29 -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 10 Oct 2017 09:59:42 +0200
> Sean Young  escreveu:
> 
> > If you try to store u64 in a kfifo (or a struct with u64 members),
> > then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes
> > padding due to alignment (note that struct __kfifo is 20 bytes
> > on 32 bit).
> > 
> > That in turn causes the __is_kfifo_ptr() to fail, which is caught
> > by kfifo_alloc(), which now returns EINVAL.
> > 
> > So, ensure that __is_kfifo_ptr() compares to the right structure.
> > 
> > Signed-off-by: Sean Young 
> > Acked-by: Stefani Seibold 
> 
> Hi Stefani/Andrew,
> 
> As this patch is required for the LIRC rework, would be ok if I would
> merge it via the media tree?
> 

It is okay by me. But the question remains why this patch wasn't
already merged?

Andrew: Any objections against this patch?


> > 
> > ---
> >  include/linux/kfifo.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
> > index 41eb6fdf87a8..86b5fb08e96c 100644
> > --- a/include/linux/kfifo.h
> > +++ b/include/linux/kfifo.h
> > @@ -113,7 +113,8 @@ struct kfifo_rec_ptr_2
> > __STRUCT_KFIFO_PTR(unsigned char, 2, void);
> >   * array is a part of the structure and the fifo type where the
> > array is
> >   * outside of the fifo structure.
> >   */
> > -#define__is_kfifo_ptr(fifo)(sizeof(*fifo) ==
> > sizeof(struct __kfifo))
> > +#define__is_kfifo_ptr(fifo) \
> > +   (sizeof(*fifo) == sizeof(STRUCT_KFIFO_PTR(typeof(*(fifo)-
> > >type
> >  
> >  /**
> >   * DECLARE_KFIFO_PTR - macro to declare a fifo pointer object
> 
> 
> 
> Thanks,
> Mauro

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

On Wed, 2017-06-07 at 17:19 -0500, Rob Herring wrote:
> On Wed, Jun 7, 2017 at 3:11 AM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > Hi Stefani,
> > 
> > On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> > > Hi Pantelis,
> > > 
> > > thanks for the suggestion. This feature is not very well
> > > documented. I
> > > tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> > > source is:
> > > 
> > > // rapsi example
> > > /dts-v1/;
> > > /plugin/;
> > > 
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > > 
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <&{/soc/timer@7e003}>;
> > > };
> > > };
> > > };
> > > 
> > > 
> > > The resulting overlay is (decompiled with fdtdump):
> > > 
> > > /dts-v1/;
> > > // magic: 0xd00dfeed
> > > // totalsize: 0x19a (410)
> > > // off_dt_struct: 0x38
> > > // off_dt_strings:0x148
> > > // off_mem_rsvmap:0x28
> > > // version:   17
> > > // last_comp_version: 16
> > > // boot_cpuid_phys:   0x0
> > > // size_dt_strings:   0x52
> > > // size_dt_struct:0x110
> > > 
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <0xdeadbeef>;
> > > };
> > > };
> > > __fixups__ {
> > > /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> > > };
> > > };
> > > 
> > > But this will not apply:
> > > 
> > > OF: resolver: overlay phandle fixup failed: -22
> > > create_overlay: Failed to resolve tree
> > > 
> > > 
> > 
> > Yes, it will not work as it is; my point is that you don't need the
> > magic __*__ node.
> > 
> > You will need to modify the overlay application code to live insert
> > a
> > phandle (if it doesn't exist) when it encounters a /path fixup.
> 
> phandles only exist if something in the base tree refers to that
> node.
> Adding them when they don't exist should definitely be something we
> support for overlays. But don't call that a broken DT. That would be
> a
> separate issue.
> 

Believe me it is broken. Due a NDA i am not able to give you more
details about the vendor. But there forgot do provide an device node
which must refer to the attached network and interrupt controller.

- Stefani

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

On Wed, 2017-06-07 at 17:19 -0500, Rob Herring wrote:
> On Wed, Jun 7, 2017 at 3:11 AM, Pantelis Antoniou
>  wrote:
> > Hi Stefani,
> > 
> > On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> > > Hi Pantelis,
> > > 
> > > thanks for the suggestion. This feature is not very well
> > > documented. I
> > > tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> > > source is:
> > > 
> > > // rapsi example
> > > /dts-v1/;
> > > /plugin/;
> > > 
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > > 
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <&{/soc/timer@7e003}>;
> > > };
> > > };
> > > };
> > > 
> > > 
> > > The resulting overlay is (decompiled with fdtdump):
> > > 
> > > /dts-v1/;
> > > // magic: 0xd00dfeed
> > > // totalsize: 0x19a (410)
> > > // off_dt_struct: 0x38
> > > // off_dt_strings:0x148
> > > // off_mem_rsvmap:0x28
> > > // version:   17
> > > // last_comp_version: 16
> > > // boot_cpuid_phys:   0x0
> > > // size_dt_strings:   0x52
> > > // size_dt_struct:0x110
> > > 
> > > / {
> > > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > > fragment@0 {
> > > target-path = "/soc/i2s@7e203000";
> > > __overlay__ {
> > > #address-cells = <0x0001>;
> > > #size-cells = <0x0001>;
> > > test = "test";
> > > timer = <0xdeadbeef>;
> > > };
> > > };
> > > __fixups__ {
> > > /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> > > };
> > > };
> > > 
> > > But this will not apply:
> > > 
> > > OF: resolver: overlay phandle fixup failed: -22
> > > create_overlay: Failed to resolve tree
> > > 
> > > 
> > 
> > Yes, it will not work as it is; my point is that you don't need the
> > magic __*__ node.
> > 
> > You will need to modify the overlay application code to live insert
> > a
> > phandle (if it doesn't exist) when it encounters a /path fixup.
> 
> phandles only exist if something in the base tree refers to that
> node.
> Adding them when they don't exist should definitely be something we
> support for overlays. But don't call that a broken DT. That would be
> a
> separate issue.
> 

Believe me it is broken. Due a NDA i am not able to give you more
details about the vendor. But there forgot do provide an device node
which must refer to the attached network and interrupt controller.

- Stefani

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

Hi Pantelis,

On Wed, 2017-06-07 at 11:11 +0300, Pantelis Antoniou wrote:
> Hi Stefani,
> 
> On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> > Hi Pantelis,
> > 
> > thanks for the suggestion. This feature is not very well
> > documented. I
> > tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> > source is:
> > 
> > // rapsi example
> > /dts-v1/;
> > /plugin/;
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > 
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <&{/soc/timer@7e003}>;
> > };
> > };
> > };
> > 
> > 
> > The resulting overlay is (decompiled with fdtdump):
> > 
> > /dts-v1/;
> > // magic:   0xd00dfeed
> > // totalsize:   0x19a (410)
> > // off_dt_struct:   0x38
> > // off_dt_strings:  0x148
> > // off_mem_rsvmap:  0x28
> > // version: 17
> > // last_comp_version:   16
> > // boot_cpuid_phys: 0x0
> > // size_dt_strings: 0x52
> > // size_dt_struct:  0x110
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <0xdeadbeef>;
> > };
> > };
> > __fixups__ {
> > /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> > };
> > };
> > 
> > But this will not apply:
> > 
> > OF: resolver: overlay phandle fixup failed: -22
> > create_overlay: Failed to resolve tree
> > 
> > 
> 
> Yes, it will not work as it is; my point is that you don't need the
> magic __*__ node.
> 

The magic __fixups__ node was inserted by the device tree compiler. I
use the dtc from https://github.com/pantoniou/dtc at commit
d990b8013889b816ec054c7e07a77db59c56c400.

> You will need to modify the overlay application code to live insert a
> phandle (if it doesn't exist) when it encounters a /path fixup.
> 

That is part of my patch!

> > Anyway, the reason for my patch is that i can reference to nodes
> > which
> > lacks a phandle. The phandle will be created on the fly and also
> > destroyed when the overlay is unloaded.
> > 
> > I have a real use case for this patch:
> > 
> > I have a BIOS on some ARM64 servers which provides broken device
> > tree.
> > It also lacks some devices in this tree which needs references to
> > other
> > devices which lacks a phandle.
> > 
> > Since the BIOSes are closed source i need a way to work arround
> > this
> > problem without patching all the drivers involved to this devices.
> > 
> > Hope this helps to understand the reason for this patch.
> > 
> 
> FWIW your problem seems like something that would happen on the
> field.
> We can berate the vendor of not providing the correct device tree,
> but
> in the end workarounds for broken vendor things are common in the
> kernel.
> 

Yes, that is the way how linux do the things. Linux has a long history
to bypassing bugs of BIOSes, ACPI or broken devices.

Greetings,
Stefani

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

Hi Pantelis,

On Wed, 2017-06-07 at 11:11 +0300, Pantelis Antoniou wrote:
> Hi Stefani,
> 
> On Tue, 2017-06-06 at 21:17 +0200, Stefani Seibold wrote:
> > Hi Pantelis,
> > 
> > thanks for the suggestion. This feature is not very well
> > documented. I
> > tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
> > source is:
> > 
> > // rapsi example
> > /dts-v1/;
> > /plugin/;
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > 
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <&{/soc/timer@7e003}>;
> > };
> > };
> > };
> > 
> > 
> > The resulting overlay is (decompiled with fdtdump):
> > 
> > /dts-v1/;
> > // magic:   0xd00dfeed
> > // totalsize:   0x19a (410)
> > // off_dt_struct:   0x38
> > // off_dt_strings:  0x148
> > // off_mem_rsvmap:  0x28
> > // version: 17
> > // last_comp_version:   16
> > // boot_cpuid_phys: 0x0
> > // size_dt_strings: 0x52
> > // size_dt_struct:  0x110
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <0xdeadbeef>;
> > };
> > };
> > __fixups__ {
> > /soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
> > };
> > };
> > 
> > But this will not apply:
> > 
> > OF: resolver: overlay phandle fixup failed: -22
> > create_overlay: Failed to resolve tree
> > 
> > 
> 
> Yes, it will not work as it is; my point is that you don't need the
> magic __*__ node.
> 

The magic __fixups__ node was inserted by the device tree compiler. I
use the dtc from https://github.com/pantoniou/dtc at commit
d990b8013889b816ec054c7e07a77db59c56c400.

> You will need to modify the overlay application code to live insert a
> phandle (if it doesn't exist) when it encounters a /path fixup.
> 

That is part of my patch!

> > Anyway, the reason for my patch is that i can reference to nodes
> > which
> > lacks a phandle. The phandle will be created on the fly and also
> > destroyed when the overlay is unloaded.
> > 
> > I have a real use case for this patch:
> > 
> > I have a BIOS on some ARM64 servers which provides broken device
> > tree.
> > It also lacks some devices in this tree which needs references to
> > other
> > devices which lacks a phandle.
> > 
> > Since the BIOSes are closed source i need a way to work arround
> > this
> > problem without patching all the drivers involved to this devices.
> > 
> > Hope this helps to understand the reason for this patch.
> > 
> 
> FWIW your problem seems like something that would happen on the
> field.
> We can berate the vendor of not providing the correct device tree,
> but
> in the end workarounds for broken vendor things are common in the
> kernel.
> 

Yes, that is the way how linux do the things. Linux has a long history
to bypassing bugs of BIOSes, ACPI or broken devices.

Greetings,
Stefani

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

Hi Pantelis,

thanks for the suggestion. This feature is not very well documented. I
tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
source is:

// rapsi example
/dts-v1/;
/plugin/;

/ {
compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

fragment@0 {
target-path = "/soc/i2s@7e203000";
__overlay__ {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
test = "test";
timer = <&{/soc/timer@7e003}>;
};
};
};


The resulting overlay is (decompiled with fdtdump):

/dts-v1/;
// magic:   0xd00dfeed
// totalsize:   0x19a (410)
// off_dt_struct:   0x38
// off_dt_strings:  0x148
// off_mem_rsvmap:  0x28
// version: 17
// last_comp_version:   16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x52
// size_dt_struct:  0x110

/ {
compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
fragment@0 {
target-path = "/soc/i2s@7e203000";
__overlay__ {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
test = "test";
timer = <0xdeadbeef>;
};
};
__fixups__ {
/soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
};
};

But this will not apply:

OF: resolver: overlay phandle fixup failed: -22
create_overlay: Failed to resolve tree


Anyway, the reason for my patch is that i can reference to nodes which
lacks a phandle. The phandle will be created on the fly and also
destroyed when the overlay is unloaded.

I have a real use case for this patch:

I have a BIOS on some ARM64 servers which provides broken device tree.
It also lacks some devices in this tree which needs references to other
devices which lacks a phandle.

Since the BIOSes are closed source i need a way to work arround this
problem without patching all the drivers involved to this devices.

Hope this helps to understand the reason for this patch.

- Stefani

Am Montag, den 05.06.2017, 21:43 +0300 schrieb Pantelis Antoniou:
> Hi Stefani,
> 
> On Mon, 2017-06-05 at 14:59 +0200, Stefani Seibold wrote:
> > From: Stefani Seibold <stef...@seibold.net>
> > 
> > This patch enables external references for symbols which are not
> > exported by the current device tree. For example
> > 
> > // RASPI example (only for testing)
> > /dts-v1/;
> > /plugin/;
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > 
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <>;
> > };
> > };
> > 
> > __external_symbols__ {
> > timer = "/soc/timer@7e003000";
> > };
> > };
> > 
> 
> I understand the problem. I am just not fond of the
> __external_symbols__
> solution.
> 
> There's a facility in the DT source language that allows to declare
> pathspec labels.
> 
> The 'timer = <>;' statement could be rewritten as 
> 'timer = <&{/soc/timer@7e003}>;'
> 
> Internally you can 'catch' that this refers to a symbol in the base
> tree
> and then do the same symbol insertion as the patch you've submitted.
> 
> The benefit to the above is that you don't introduce manually edited
> special nodes.
> 
> Regards
> 
> -- Pantelis
> 
> > The "timer" symbol is not exported by the RASPI device tree,
> > because it is
> > missing in the __symbols__ section of the device tree.
> > 
> > In case of the RASPI device tree this could be simple fixed by
> > modifing
> > the device tree source, but when the device tree is provided by a
> > closed
> > source BIOS this kind of missing symbol could not be fixed.
> > 
> > An additional benefit is to override a (possible broken) symbol
> > exported
> > by the currect live device tree.
> > 
> > The patch is based and tested on linux 4.12-rc3.
> > 
> > Signed-off-by: Stefani Seibold <stefani.seibold@huawei.com>
> > Signed-off-by: Stefani Seibold <stef...@seibold.net>
> > ---
> >  drivers/of/overlay.c  | 19 +++
> >  drivers/of/resolver.c | 27 ++-
> >  2 files changed, 41 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/of/overlay.c b/drivers/of/over

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

Hi Pantelis,

thanks for the suggestion. This feature is not very well documented. I
tried this on my rasp1 running 4.12.0-rc3 and it doesn't work. My
source is:

// rapsi example
/dts-v1/;
/plugin/;

/ {
compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

fragment@0 {
target-path = "/soc/i2s@7e203000";
__overlay__ {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
test = "test";
timer = <&{/soc/timer@7e003}>;
};
};
};


The resulting overlay is (decompiled with fdtdump):

/dts-v1/;
// magic:   0xd00dfeed
// totalsize:   0x19a (410)
// off_dt_struct:   0x38
// off_dt_strings:  0x148
// off_mem_rsvmap:  0x28
// version: 17
// last_comp_version:   16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x52
// size_dt_struct:  0x110

/ {
compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
fragment@0 {
target-path = "/soc/i2s@7e203000";
__overlay__ {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
test = "test";
timer = <0xdeadbeef>;
};
};
__fixups__ {
/soc/timer@7e003 = "/fragment@0/__overlay__:timer:0";
};
};

But this will not apply:

OF: resolver: overlay phandle fixup failed: -22
create_overlay: Failed to resolve tree


Anyway, the reason for my patch is that i can reference to nodes which
lacks a phandle. The phandle will be created on the fly and also
destroyed when the overlay is unloaded.

I have a real use case for this patch:

I have a BIOS on some ARM64 servers which provides broken device tree.
It also lacks some devices in this tree which needs references to other
devices which lacks a phandle.

Since the BIOSes are closed source i need a way to work arround this
problem without patching all the drivers involved to this devices.

Hope this helps to understand the reason for this patch.

- Stefani

Am Montag, den 05.06.2017, 21:43 +0300 schrieb Pantelis Antoniou:
> Hi Stefani,
> 
> On Mon, 2017-06-05 at 14:59 +0200, Stefani Seibold wrote:
> > From: Stefani Seibold 
> > 
> > This patch enables external references for symbols which are not
> > exported by the current device tree. For example
> > 
> > // RASPI example (only for testing)
> > /dts-v1/;
> > /plugin/;
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > 
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <>;
> > };
> > };
> > 
> > __external_symbols__ {
> > timer = "/soc/timer@7e003000";
> > };
> > };
> > 
> 
> I understand the problem. I am just not fond of the
> __external_symbols__
> solution.
> 
> There's a facility in the DT source language that allows to declare
> pathspec labels.
> 
> The 'timer = <>;' statement could be rewritten as 
> 'timer = <&{/soc/timer@7e003}>;'
> 
> Internally you can 'catch' that this refers to a symbol in the base
> tree
> and then do the same symbol insertion as the patch you've submitted.
> 
> The benefit to the above is that you don't introduce manually edited
> special nodes.
> 
> Regards
> 
> -- Pantelis
> 
> > The "timer" symbol is not exported by the RASPI device tree,
> > because it is
> > missing in the __symbols__ section of the device tree.
> > 
> > In case of the RASPI device tree this could be simple fixed by
> > modifing
> > the device tree source, but when the device tree is provided by a
> > closed
> > source BIOS this kind of missing symbol could not be fixed.
> > 
> > An additional benefit is to override a (possible broken) symbol
> > exported
> > by the currect live device tree.
> > 
> > The patch is based and tested on linux 4.12-rc3.
> > 
> > Signed-off-by: Stefani Seibold 
> > Signed-off-by: Stefani Seibold 
> > ---
> >  drivers/of/overlay.c  | 19 +++
> >  drivers/of/resolver.c | 27 ++-
> >  2 files changed, 41 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> > index 7827786718d8..de6516ea0fcd 100644
> > --- a/drivers/of/overlay.c
&g

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

Hi Frank,

On 06.06.2017, 00:20 -0700 Frank Rowand wrote::
> On 06/05/17 05:59, Stefani Seibold wrote:
> > From: Stefani Seibold <stef...@seibold.net>
> > 
> > This patch enables external references for symbols which are not
> > exported by the current device tree. For example
> > 
> > // RASPI example (only for testing)
> > /dts-v1/;
> > /plugin/;
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > 
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <>;
> > };
> > };
> > 
> > __external_symbols__ {
> > timer = "/soc/timer@7e003000";
> > };
> > };
> 
> My hope is that the dtc compiler will stop supporting specification
> of the
> __symbols__ node in dts source, and only generate it automatically in
> the dtb.
> That change to dtc would not allow any node name specified in a dts
> to begin
> with an underscore.  Thus node __external_symbols__ would not be
> allowed.
> 

The name is not so important to me, only the solution.

> > In case of the RASPI device tree this could be simple fixed by
> > modifing
> > the device tree source, but when the device tree is provided by a
> > closed
> > source BIOS this kind of missing symbol could not be fixed.
> 
> Is there a real example of this issue, or is this a theoretical
> concern?
> If this is a real example, we should be discouraging such behavior.
> 

Yes, I have a BIOS on some ARM64 servers which provides broken device tree. It 
also lacks some devices in this tree which needs references to other devices 
which lacks a phandle.


> The suggestion by Pantelis should work, but that is just a hack to
> get
> you out of a bad situation, not a good practice.
> 

I tried it, but it doesn't work. Look at my post to Pantelis.

- Stefani

Re: [PATCH] external references for device tree overlays

[Stefani Seibold]

Hi Frank,

On 06.06.2017, 00:20 -0700 Frank Rowand wrote::
> On 06/05/17 05:59, Stefani Seibold wrote:
> > From: Stefani Seibold 
> > 
> > This patch enables external references for symbols which are not
> > exported by the current device tree. For example
> > 
> > // RASPI example (only for testing)
> > /dts-v1/;
> > /plugin/;
> > 
> > / {
> > compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
> > 
> > fragment@0 {
> > target-path = "/soc/i2s@7e203000";
> > __overlay__ {
> > #address-cells = <0x0001>;
> > #size-cells = <0x0001>;
> > test = "test";
> > timer = <>;
> > };
> > };
> > 
> > __external_symbols__ {
> > timer = "/soc/timer@7e003000";
> > };
> > };
> 
> My hope is that the dtc compiler will stop supporting specification
> of the
> __symbols__ node in dts source, and only generate it automatically in
> the dtb.
> That change to dtc would not allow any node name specified in a dts
> to begin
> with an underscore.  Thus node __external_symbols__ would not be
> allowed.
> 

The name is not so important to me, only the solution.

> > In case of the RASPI device tree this could be simple fixed by
> > modifing
> > the device tree source, but when the device tree is provided by a
> > closed
> > source BIOS this kind of missing symbol could not be fixed.
> 
> Is there a real example of this issue, or is this a theoretical
> concern?
> If this is a real example, we should be discouraging such behavior.
> 

Yes, I have a BIOS on some ARM64 servers which provides broken device tree. It 
also lacks some devices in this tree which needs references to other devices 
which lacks a phandle.


> The suggestion by Pantelis should work, but that is just a hack to
> get
> you out of a bad situation, not a good practice.
> 

I tried it, but it doesn't work. Look at my post to Pantelis.

- Stefani

[PATCH] external references for device tree overlays

[Stefani Seibold]

From: Stefani Seibold <stef...@seibold.net>

This patch enables external references for symbols which are not
exported by the current device tree. For example

// RASPI example (only for testing)
/dts-v1/;
/plugin/;

/ {
compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

fragment@0 {
target-path = "/soc/i2s@7e203000";
__overlay__ {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
test = "test";
timer = <>;
};
};

__external_symbols__ {
timer = "/soc/timer@7e003000";
};
};

The "timer" symbol is not exported by the RASPI device tree, because it is
missing in the __symbols__ section of the device tree.

In case of the RASPI device tree this could be simple fixed by modifing
the device tree source, but when the device tree is provided by a closed
source BIOS this kind of missing symbol could not be fixed.

An additional benefit is to override a (possible broken) symbol exported
by the currect live device tree.

The patch is based and tested on linux 4.12-rc3.

Signed-off-by: Stefani Seibold <stefani.seibold@huawei.com>
Signed-off-by: Stefani Seibold <stef...@seibold.net>
---
 drivers/of/overlay.c  | 19 +++
 drivers/of/resolver.c | 27 ++-
 2 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 7827786718d8..de6516ea0fcd 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -50,6 +50,7 @@ struct of_overlay {
int id;
struct list_head node;
int count;
+   struct device_node *tree;
struct of_overlay_info *ovinfo_tab;
struct of_changeset cset;
 };
@@ -422,6 +423,8 @@ int of_overlay_create(struct device_node *tree)
/* add to the tail of the overlay list */
list_add_tail(>node, _list);
 
+   ov->tree = tree;
+
of_overlay_notify(ov, OF_OVERLAY_POST_APPLY);
 
mutex_unlock(_mutex);
@@ -524,6 +527,7 @@ int of_overlay_destroy(int id)
 {
struct of_overlay *ov;
int err;
+   phandle phandle;
 
mutex_lock(_mutex);
 
@@ -540,6 +544,8 @@ int of_overlay_destroy(int id)
goto out;
}
 
+   phandle = ov->tree->phandle;
+
of_overlay_notify(ov, OF_OVERLAY_PRE_REMOVE);
list_del(>node);
__of_changeset_revert(>cset);
@@ -549,6 +555,19 @@ int of_overlay_destroy(int id)
of_changeset_destroy(>cset);
kfree(ov);
 
+   if (phandle) {
+   struct device_node *node;
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(_lock, flags);
+   for_each_of_allnodes(node) {
+   if (node->phandle >= phandle)
+   node->phandle = 0;
+   }
+   raw_spin_unlock_irqrestore(_lock, flags);
+   }
+
+
err = 0;
 
 out:
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 771f4844c781..31b5f32c9b27 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -286,13 +286,14 @@ static int adjust_local_phandle_references(struct 
device_node *local_fixups,
 int of_resolve_phandles(struct device_node *overlay)
 {
struct device_node *child, *local_fixups, *refnode;
-   struct device_node *tree_symbols, *overlay_fixups;
+   struct device_node *tree_symbols, *ext_symbols, *overlay_fixups;
struct property *prop;
const char *refpath;
phandle phandle, phandle_delta;
int err;
 
tree_symbols = NULL;
+   ext_symbols = NULL;
 
if (!overlay) {
pr_err("null overlay\n");
@@ -321,6 +322,9 @@ int of_resolve_phandles(struct device_node *overlay)
for_each_child_of_node(overlay, child) {
if (!of_node_cmp(child->name, "__fixups__"))
overlay_fixups = child;
+   else
+   if (!of_node_cmp(child->name, "__external_symbols__"))
+   ext_symbols = child;
}
 
if (!overlay_fixups) {
@@ -329,20 +333,30 @@ int of_resolve_phandles(struct device_node *overlay)
}
 
tree_symbols = of_find_node_by_path("/__symbols__");
-   if (!tree_symbols) {
-   pr_err("no symbols in root of device tree.\n");
+   if (!tree_symbols && !ext_symbols) {
+   pr_err("no symbols for resolve in device tree.\n");
err = -EINVAL;
goto out;
}
 
+   phandle_delta = live_tree_max_phandle() + 1;
+
for_each_property_of_node(overlay_fixups, prop) {
 
/* skip properties added automatically */
if (!of_prop_cmp(prop->name, "name"))

[PATCH] external references for device tree overlays

[Stefani Seibold]

From: Stefani Seibold 

This patch enables external references for symbols which are not
exported by the current device tree. For example

// RASPI example (only for testing)
/dts-v1/;
/plugin/;

/ {
compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

fragment@0 {
target-path = "/soc/i2s@7e203000";
__overlay__ {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
test = "test";
timer = <>;
};
};

__external_symbols__ {
timer = "/soc/timer@7e003000";
};
};

The "timer" symbol is not exported by the RASPI device tree, because it is
missing in the __symbols__ section of the device tree.

In case of the RASPI device tree this could be simple fixed by modifing
the device tree source, but when the device tree is provided by a closed
source BIOS this kind of missing symbol could not be fixed.

An additional benefit is to override a (possible broken) symbol exported
by the currect live device tree.

The patch is based and tested on linux 4.12-rc3.

Signed-off-by: Stefani Seibold 
Signed-off-by: Stefani Seibold 
---
 drivers/of/overlay.c  | 19 +++
 drivers/of/resolver.c | 27 ++-
 2 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 7827786718d8..de6516ea0fcd 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -50,6 +50,7 @@ struct of_overlay {
int id;
struct list_head node;
int count;
+   struct device_node *tree;
struct of_overlay_info *ovinfo_tab;
struct of_changeset cset;
 };
@@ -422,6 +423,8 @@ int of_overlay_create(struct device_node *tree)
/* add to the tail of the overlay list */
list_add_tail(>node, _list);
 
+   ov->tree = tree;
+
of_overlay_notify(ov, OF_OVERLAY_POST_APPLY);
 
mutex_unlock(_mutex);
@@ -524,6 +527,7 @@ int of_overlay_destroy(int id)
 {
struct of_overlay *ov;
int err;
+   phandle phandle;
 
mutex_lock(_mutex);
 
@@ -540,6 +544,8 @@ int of_overlay_destroy(int id)
goto out;
}
 
+   phandle = ov->tree->phandle;
+
of_overlay_notify(ov, OF_OVERLAY_PRE_REMOVE);
list_del(>node);
__of_changeset_revert(>cset);
@@ -549,6 +555,19 @@ int of_overlay_destroy(int id)
of_changeset_destroy(>cset);
kfree(ov);
 
+   if (phandle) {
+   struct device_node *node;
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(_lock, flags);
+   for_each_of_allnodes(node) {
+   if (node->phandle >= phandle)
+   node->phandle = 0;
+   }
+   raw_spin_unlock_irqrestore(_lock, flags);
+   }
+
+
err = 0;
 
 out:
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 771f4844c781..31b5f32c9b27 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -286,13 +286,14 @@ static int adjust_local_phandle_references(struct 
device_node *local_fixups,
 int of_resolve_phandles(struct device_node *overlay)
 {
struct device_node *child, *local_fixups, *refnode;
-   struct device_node *tree_symbols, *overlay_fixups;
+   struct device_node *tree_symbols, *ext_symbols, *overlay_fixups;
struct property *prop;
const char *refpath;
phandle phandle, phandle_delta;
int err;
 
tree_symbols = NULL;
+   ext_symbols = NULL;
 
if (!overlay) {
pr_err("null overlay\n");
@@ -321,6 +322,9 @@ int of_resolve_phandles(struct device_node *overlay)
for_each_child_of_node(overlay, child) {
if (!of_node_cmp(child->name, "__fixups__"))
overlay_fixups = child;
+   else
+   if (!of_node_cmp(child->name, "__external_symbols__"))
+   ext_symbols = child;
}
 
if (!overlay_fixups) {
@@ -329,20 +333,30 @@ int of_resolve_phandles(struct device_node *overlay)
}
 
tree_symbols = of_find_node_by_path("/__symbols__");
-   if (!tree_symbols) {
-   pr_err("no symbols in root of device tree.\n");
+   if (!tree_symbols && !ext_symbols) {
+   pr_err("no symbols for resolve in device tree.\n");
err = -EINVAL;
goto out;
}
 
+   phandle_delta = live_tree_max_phandle() + 1;
+
for_each_property_of_node(overlay_fixups, prop) {
 
/* skip properties added automatically */
if (!of_prop_cmp(prop->name, "name"))
continue;
 
-   err = of_property_read_string(tree_symbols,
- 

OHCI unplug kernel crash in kernel 4.3, 4.4 and 4.5

[Stefani Seibold]

I still reported this bug 6 Weeks ago... and i checked it know with the
current kernel 4.5.0-rc5. The bug is yet not fixed.

A unplug of an USB 1.0 OHCI controller express card will result in a
kernel crash. The express card is attached via thunderbolt and a sonnet
express card to thunderbolt adapter. The computer hangs after the
unplug, only a power down fix the situation.

This is the kernel log of a kernel 4.4 via netconsole:

pciehp :06:03.0:pcie24: Card not present on Slot(3)
pciehp :06:03.0:pcie24: slot(3): Link Down event
pciehp :06:03.0:pcie24: Link Down event ignored on slot(3): already
powering off
ehci-pci :0b:00.2: HC died; cleaning up
ehci-pci :0b:00.2: remove, state 4
usb usb5: USB disconnect, device number 1
pciehp :00:1c.4:pcie04: Card not present on Slot(4)
pciehp :00:1c.4:pcie04: slot(4): Link Down event
ehci-pci :0b:00.2: USB bus 5 deregistered
ohci-pci :0b:00.1: HC died; cleaning up
ohci-pci :0b:00.1: remove, state 4
usb usb7: USB disconnect, device number 1
pciehp :00:1c.4:pcie04: Link Down event ignored on slot(4): already
powering off
ohci-pci :0b:00.1: USB bus 7 deregistered
ohci-pci :0b:00.0: HC died; cleaning up
ohci-pci :0b:00.0: remove, state 4
usb usb6: USB disconnect, device number 1
[ cut here ]
kernel BUG at drivers/iommu/intel-iommu.c:3592!
invalid opcode:  [#1] PREEMPT SMP 
Modules linked in: ohci_pci ohci_hcd binfmt_misc netconsole configfs
bbswitch(O) iwlmvm iwlwifi vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
nvidia(PO) vhost_net tun vhost kvm_intel kvm irqbypass dell_smm_hwmon
[last unloaded: netconsole]
CPU: 0 PID: 4857 Comm: kworker/0:3 Tainted: P   O4.4.0-
gentoo #1
Hardware name: Dell Inc. XPS 2720/05R2TK  , BIOS A12 09/21/2015
Workqueue: pciehp-3 pciehp_power_thread
task: 8804070a2300 ti: 8803e4658000 task.ti: 8803e4658000
RIP: 0010:[]  []
intel_unmap+0x1c4/0x1d0
RSP: 0018:8803e465bb98  EFLAGS: 00010246
RAX:  RBX: 8804225fb098 RCX: c000
RDX:  RSI: c000 RDI: 8804225fb098
RBP: 8803e465bbd0 R08:  R09: 
R10: 88046cc000c0 R11:  R12: 
R13: c000 R14: 880468caa400 R15: e8c13800
FS:  () GS:88047f20()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f2515680324 CR3: 0120a000 CR4: 001406f0
Stack:
 8804101e4a78 8803e465bbf0 ea000f915840 
 812a3ec0 880468caa400 e8c13800 8803e465bbf0
 8061ee8a 88045e68f000 8804225fb098 8803e465bc28
Call Trace:
 [] intel_free_coherent+0x5a/0xa0
 [] ohci_stop+0x144/0x1c0 [ohci_hcd]
 [] usb_remove_hcd+0xe4/0x1a0
 [] usb_hcd_pci_remove+0x63/0x130
 [] pci_device_remove+0x39/0xc0
 [] __device_release_driver+0x96/0x130
 [] device_release_driver+0x23/0x30
 [] pci_stop_bus_device+0x8a/0xa0
 [] pci_stop_bus_device+0x31/0xa0
 [] pci_stop_bus_device+0x31/0xa0
 [] pci_stop_bus_device+0x31/0xa0
 [] pci_stop_and_remove_bus_device+0x12/0x20
 [] pciehp_unconfigure_device+0x9b/0x180
 [] pciehp_disable_slot+0x43/0xb0
 [] pciehp_power_thread+0x8d/0xb0
 [] process_one_work+0x144/0x3c0
 [] worker_thread+0x4b/0x440
 [] ? process_one_work+0x3c0/0x3c0
 [] ? process_one_work+0x3c0/0x3c0
 [] kthread+0xc9/0xe0
 [] ? kthread_create_on_node+0x180/0x180
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x180/0x180
Code: f9 48 89 de e8 fe cd ff ff 4c 89 e6 4c 89 f7 e8 23 92 ff ff 4c 89
ef e8 0b cf ff ff 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b
e8 45 cf ff ff e9 f3 fe ff ff 0f 1f 44 00 00 55 48 8b 76 
RIP  [] intel_unmap+0x1c4/0x1d0
 RSP 
---[ end trace ad0596f59dc3d9e0 ]---
BUG: unable to handle kernel paging request at ffd8
IP: [] kthread_data+0x11/0x20
PGD 120b067 PUD 120d067 PMD 0 
Oops:  [#2] PREEMPT SMP 
Modules linked in: ohci_pci ohci_hcd binfmt_misc netconsole configfs
bbswitch(O) iwlmvm iwlwifi vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
nvidia(PO) vhost_net tun vhost kvm_intel kvm irqbypass dell_smm_hwmon
[last unloaded: netconsole]
CPU: 0 PID: 4857 Comm: kworker/0:3 Tainted: P  DO4.4.0-
gentoo #1
Hardware name: Dell Inc. XPS 2720/05R2TK  , BIOS A12 09/21/2015
task: 8804070a2300 ti: 8803e4658000 task.ti: 8803e4658000
RIP: 0010:[]  []
kthread_data+0x11/0x20
RSP: 0018:8803e465b878  EFLAGS: 00010002
RAX:  RBX:  RCX: 814bd980
RDX:  RSI:  RDI: 8804070a2300
RBP: 8803e465b888 R08:  R09: 880468dfe901
R10: 2800 R11: 001a R12: 
R13: 000154c0 R14: 8804070a2300 R15: 88047f2154c0
FS:  () GS:88047f20()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 0120a000 CR4: 

OHCI unplug kernel crash in kernel 4.3, 4.4 and 4.5

[Stefani Seibold]

I still reported this bug 6 Weeks ago... and i checked it know with the
current kernel 4.5.0-rc5. The bug is yet not fixed.

A unplug of an USB 1.0 OHCI controller express card will result in a
kernel crash. The express card is attached via thunderbolt and a sonnet
express card to thunderbolt adapter. The computer hangs after the
unplug, only a power down fix the situation.

This is the kernel log of a kernel 4.4 via netconsole:

pciehp :06:03.0:pcie24: Card not present on Slot(3)
pciehp :06:03.0:pcie24: slot(3): Link Down event
pciehp :06:03.0:pcie24: Link Down event ignored on slot(3): already
powering off
ehci-pci :0b:00.2: HC died; cleaning up
ehci-pci :0b:00.2: remove, state 4
usb usb5: USB disconnect, device number 1
pciehp :00:1c.4:pcie04: Card not present on Slot(4)
pciehp :00:1c.4:pcie04: slot(4): Link Down event
ehci-pci :0b:00.2: USB bus 5 deregistered
ohci-pci :0b:00.1: HC died; cleaning up
ohci-pci :0b:00.1: remove, state 4
usb usb7: USB disconnect, device number 1
pciehp :00:1c.4:pcie04: Link Down event ignored on slot(4): already
powering off
ohci-pci :0b:00.1: USB bus 7 deregistered
ohci-pci :0b:00.0: HC died; cleaning up
ohci-pci :0b:00.0: remove, state 4
usb usb6: USB disconnect, device number 1
[ cut here ]
kernel BUG at drivers/iommu/intel-iommu.c:3592!
invalid opcode:  [#1] PREEMPT SMP 
Modules linked in: ohci_pci ohci_hcd binfmt_misc netconsole configfs
bbswitch(O) iwlmvm iwlwifi vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
nvidia(PO) vhost_net tun vhost kvm_intel kvm irqbypass dell_smm_hwmon
[last unloaded: netconsole]
CPU: 0 PID: 4857 Comm: kworker/0:3 Tainted: P   O4.4.0-
gentoo #1
Hardware name: Dell Inc. XPS 2720/05R2TK  , BIOS A12 09/21/2015
Workqueue: pciehp-3 pciehp_power_thread
task: 8804070a2300 ti: 8803e4658000 task.ti: 8803e4658000
RIP: 0010:[]  []
intel_unmap+0x1c4/0x1d0
RSP: 0018:8803e465bb98  EFLAGS: 00010246
RAX:  RBX: 8804225fb098 RCX: c000
RDX:  RSI: c000 RDI: 8804225fb098
RBP: 8803e465bbd0 R08:  R09: 
R10: 88046cc000c0 R11:  R12: 
R13: c000 R14: 880468caa400 R15: e8c13800
FS:  () GS:88047f20()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f2515680324 CR3: 0120a000 CR4: 001406f0
Stack:
 8804101e4a78 8803e465bbf0 ea000f915840 
 812a3ec0 880468caa400 e8c13800 8803e465bbf0
 8061ee8a 88045e68f000 8804225fb098 8803e465bc28
Call Trace:
 [] intel_free_coherent+0x5a/0xa0
 [] ohci_stop+0x144/0x1c0 [ohci_hcd]
 [] usb_remove_hcd+0xe4/0x1a0
 [] usb_hcd_pci_remove+0x63/0x130
 [] pci_device_remove+0x39/0xc0
 [] __device_release_driver+0x96/0x130
 [] device_release_driver+0x23/0x30
 [] pci_stop_bus_device+0x8a/0xa0
 [] pci_stop_bus_device+0x31/0xa0
 [] pci_stop_bus_device+0x31/0xa0
 [] pci_stop_bus_device+0x31/0xa0
 [] pci_stop_and_remove_bus_device+0x12/0x20
 [] pciehp_unconfigure_device+0x9b/0x180
 [] pciehp_disable_slot+0x43/0xb0
 [] pciehp_power_thread+0x8d/0xb0
 [] process_one_work+0x144/0x3c0
 [] worker_thread+0x4b/0x440
 [] ? process_one_work+0x3c0/0x3c0
 [] ? process_one_work+0x3c0/0x3c0
 [] kthread+0xc9/0xe0
 [] ? kthread_create_on_node+0x180/0x180
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x180/0x180
Code: f9 48 89 de e8 fe cd ff ff 4c 89 e6 4c 89 f7 e8 23 92 ff ff 4c 89
ef e8 0b cf ff ff 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b
e8 45 cf ff ff e9 f3 fe ff ff 0f 1f 44 00 00 55 48 8b 76 
RIP  [] intel_unmap+0x1c4/0x1d0
 RSP 
---[ end trace ad0596f59dc3d9e0 ]---
BUG: unable to handle kernel paging request at ffd8
IP: [] kthread_data+0x11/0x20
PGD 120b067 PUD 120d067 PMD 0 
Oops:  [#2] PREEMPT SMP 
Modules linked in: ohci_pci ohci_hcd binfmt_misc netconsole configfs
bbswitch(O) iwlmvm iwlwifi vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
nvidia(PO) vhost_net tun vhost kvm_intel kvm irqbypass dell_smm_hwmon
[last unloaded: netconsole]
CPU: 0 PID: 4857 Comm: kworker/0:3 Tainted: P  DO4.4.0-
gentoo #1
Hardware name: Dell Inc. XPS 2720/05R2TK  , BIOS A12 09/21/2015
task: 8804070a2300 ti: 8803e4658000 task.ti: 8803e4658000
RIP: 0010:[]  []
kthread_data+0x11/0x20
RSP: 0018:8803e465b878  EFLAGS: 00010002
RAX:  RBX:  RCX: 814bd980
RDX:  RSI:  RDI: 8804070a2300
RBP: 8803e465b888 R08:  R09: 880468dfe901
R10: 2800 R11: 001a R12: 
R13: 000154c0 R14: 8804070a2300 R15: 88047f2154c0
FS:  () GS:88047f20()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 0120a000 CR4: 

[PATCH] kfifo: fix sparse complains

[Stefani Seibold]

This patch fix complains by the sparse tool when using kfifo_put() with non
scalar types like structures (i.e. drivers/iio/industrialio-event.c).

Casting a pointer to the value and read this pointer instead of directly casting
the value will fix this.

The generated code is equal.

Signed-off-by: Stefani Seibold <stef...@seibold.net>
---
 include/linux/kfifo.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 473b436..41eb6fd 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -401,7 +401,7 @@ __kfifo_int_must_check_helper( \
((typeof(__tmp->type))__kfifo->data) : \
(__tmp->buf) \
)[__kfifo->in & __tmp->kfifo.mask] = \
-   (typeof(*__tmp->type))__val; \
+   *(typeof(__tmp->type))&__val; \
smp_wmb(); \
__kfifo->in++; \
} \
-- 
2.7.1

[PATCH] kfifo: fix sparse complains

[Stefani Seibold]

This patch fix complains by the sparse tool when using kfifo_put() with non
scalar types like structures (i.e. drivers/iio/industrialio-event.c).

Casting a pointer to the value and read this pointer instead of directly casting
the value will fix this.

The generated code is equal.

Signed-off-by: Stefani Seibold 
---
 include/linux/kfifo.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 473b436..41eb6fd 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -401,7 +401,7 @@ __kfifo_int_must_check_helper( \
((typeof(__tmp->type))__kfifo->data) : \
(__tmp->buf) \
)[__kfifo->in & __tmp->kfifo.mask] = \
-   (typeof(*__tmp->type))__val; \
+   *(typeof(__tmp->type))&__val; \
smp_wmb(); \
__kfifo->in++; \
} \
-- 
2.7.1

Re: [PATCH] samples: Fix `echo 1 > /proc/int-fifo` never return error

[Stefani Seibold]

The example is intended for int types, not for strings. So it is not a
bug, it's a feature ;-) But anyway, if you prefer to handle with strings
your are okay by me.

Am Dienstag, den 03.02.2015, 11:51 + schrieb Wang Long:
> echo 99 > /proc/int-fifo   > Never return
> echo 1000 > /proc/int-fifo > Never return
> 
> this patch fix it.
> 
> Signed-off-by: Wang Long 
> ---
>  samples/kfifo/inttype-example.c | 51 
> -
>  1 file changed, 40 insertions(+), 11 deletions(-)
> 
> diff --git a/samples/kfifo/inttype-example.c b/samples/kfifo/inttype-example.c
> index 8dc3c2e..cc0db5f 100644
> --- a/samples/kfifo/inttype-example.c
> +++ b/samples/kfifo/inttype-example.c
> @@ -6,6 +6,7 @@
>   * Released under the GPL version 2 only.
>   *
>   */
> +#include 
>  
>  #include 
>  #include 
> @@ -23,6 +24,9 @@
>  /* name of the proc entry */
>  #define  PROC_FIFO   "int-fifo"
>  
> +/* Worst case buffer size needed for holding an integer. */
> +#define PROC_NUMBUF 13
> +
>  /* lock for procfs read access */
>  static DEFINE_MUTEX(read_lock);
>  
> @@ -108,33 +112,58 @@ static int __init testfunc(void)
>  static ssize_t fifo_write(struct file *file, const char __user *buf,
>   size_t count, loff_t *ppos)
>  {
> - int ret;
> - unsigned int copied;
> + char buffer[PROC_NUMBUF];
> + int value;
> + int err;
>  
> - if (mutex_lock_interruptible(_lock))
> - return -ERESTARTSYS;
> + memset(buffer, 0, sizeof(buffer));
>  
> - ret = kfifo_from_user(, buf, count, );
> + if (count > sizeof(buffer) - 1)
> + count = sizeof(buffer) - 1;
> + if (copy_from_user(buffer, buf, count)) {
> + err = -EFAULT;
> + goto out;
> + }
>  
> - mutex_unlock(_lock);
> + err = kstrtoint(strstrip(buffer), 0, );
> + if (err)
> + goto out;
> +
> + if (kfifo_is_full()) {
> + err = -EINVAL;
> + goto out;
> + }
>  
> - return ret ? ret : copied;
> + if (mutex_lock_interruptible(_lock))
> + return -ERESTARTSYS;
> + kfifo_put(, value);
> + mutex_unlock(_lock);
> +out:
> + return err < 0 ? err : count;
>  }
>  
>  static ssize_t fifo_read(struct file *file, char __user *buf,
>   size_t count, loff_t *ppos)
>  {
> - int ret;
> - unsigned int copied;
> + char buffer[PROC_NUMBUF * FIFO_SIZE];
> + int value;
> + size_t  len = 0;
> + ssize_t ret = -1;
> +
> + memset(buffer, 0, sizeof(buffer));
>  
>   if (mutex_lock_interruptible(_lock))
>   return -ERESTARTSYS;
>  
> - ret = kfifo_to_user(, buf, count, );
> + while (!kfifo_is_empty()){
> + ret = kfifo_get(, );
> + len = snprintf(buffer, sizeof(buffer), "%s%d\n", buffer, value);
> + }
>  
>   mutex_unlock(_lock);
> + ret = copy_to_user(buf, buffer, len);
>  
> - return ret ? ret : copied;
> + return ret ? ret : len;
>  }
>  
>  static const struct file_operations fifo_fops = {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] samples: Fix `echo 1 /proc/int-fifo` never return error

[Stefani Seibold]

The example is intended for int types, not for strings. So it is not a
bug, it's a feature ;-) But anyway, if you prefer to handle with strings
your are okay by me.

Am Dienstag, den 03.02.2015, 11:51 + schrieb Wang Long:
 echo 99  /proc/int-fifo    Never return
 echo 1000  /proc/int-fifo  Never return
 
 this patch fix it.
 
 Signed-off-by: Wang Long long.wangl...@huawei.com
 ---
  samples/kfifo/inttype-example.c | 51 
 -
  1 file changed, 40 insertions(+), 11 deletions(-)
 
 diff --git a/samples/kfifo/inttype-example.c b/samples/kfifo/inttype-example.c
 index 8dc3c2e..cc0db5f 100644
 --- a/samples/kfifo/inttype-example.c
 +++ b/samples/kfifo/inttype-example.c
 @@ -6,6 +6,7 @@
   * Released under the GPL version 2 only.
   *
   */
 +#include asm/uaccess.h
  
  #include linux/init.h
  #include linux/module.h
 @@ -23,6 +24,9 @@
  /* name of the proc entry */
  #define  PROC_FIFO   int-fifo
  
 +/* Worst case buffer size needed for holding an integer. */
 +#define PROC_NUMBUF 13
 +
  /* lock for procfs read access */
  static DEFINE_MUTEX(read_lock);
  
 @@ -108,33 +112,58 @@ static int __init testfunc(void)
  static ssize_t fifo_write(struct file *file, const char __user *buf,
   size_t count, loff_t *ppos)
  {
 - int ret;
 - unsigned int copied;
 + char buffer[PROC_NUMBUF];
 + int value;
 + int err;
  
 - if (mutex_lock_interruptible(write_lock))
 - return -ERESTARTSYS;
 + memset(buffer, 0, sizeof(buffer));
  
 - ret = kfifo_from_user(test, buf, count, copied);
 + if (count  sizeof(buffer) - 1)
 + count = sizeof(buffer) - 1;
 + if (copy_from_user(buffer, buf, count)) {
 + err = -EFAULT;
 + goto out;
 + }
  
 - mutex_unlock(write_lock);
 + err = kstrtoint(strstrip(buffer), 0, value);
 + if (err)
 + goto out;
 +
 + if (kfifo_is_full(test)) {
 + err = -EINVAL;
 + goto out;
 + }
  
 - return ret ? ret : copied;
 + if (mutex_lock_interruptible(write_lock))
 + return -ERESTARTSYS;
 + kfifo_put(test, value);
 + mutex_unlock(write_lock);
 +out:
 + return err  0 ? err : count;
  }
  
  static ssize_t fifo_read(struct file *file, char __user *buf,
   size_t count, loff_t *ppos)
  {
 - int ret;
 - unsigned int copied;
 + char buffer[PROC_NUMBUF * FIFO_SIZE];
 + int value;
 + size_t  len = 0;
 + ssize_t ret = -1;
 +
 + memset(buffer, 0, sizeof(buffer));
  
   if (mutex_lock_interruptible(read_lock))
   return -ERESTARTSYS;
  
 - ret = kfifo_to_user(test, buf, count, copied);
 + while (!kfifo_is_empty(test)){
 + ret = kfifo_get(test, value);
 + len = snprintf(buffer, sizeof(buffer), %s%d\n, buffer, value);
 + }
  
   mutex_unlock(read_lock);
 + ret = copy_to_user(buf, buffer, len);
  
 - return ret ? ret : copied;
 + return ret ? ret : len;
  }
  
  static const struct file_operations fifo_fops = {


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)

[Stefani Seibold]

On Mon, 2014-04-28 at 20:20 +0200, Alessandro Zummo wrote:
> On Mon, 28 Apr 2014 11:16:37 -0700
> John Stultz  wrote:
> 
> > >> This breaks the API since there is no more misc device /dev/rtc
> > >> available without a udev rule or a link to /dev/rtc0.  
> > 
> > So yea.. I feel like that /dev/rtcN renaming (and API) break (which
> > was a huge and annoying pain) was back in the 2.6.18-ish era?
> 
>  It's very old and linking/renaming is around since then.
> 
> > But it sounds like the driver/char/rtc bit is dead code, and needs a
> > cleanup? Or is there some use of that code that you need that the
> > generic RTC layer doesn't have?
> 

The driver/char/rtc is not working code and should be a wrapper to the
first rtc device.

>  as far as I know, no recent distribution is using the old code
>  anymore and the new (well, not so new anymore) framework provides the same 
> functionality.
>  

Embedded distribution use it and depending on the /dev/rtc device. So
what is missing is the /dev/rtc misc device 10,135.

- Stefani

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)

[Stefani Seibold]

On Mon, 2014-04-28 at 20:20 +0200, Alessandro Zummo wrote:
 On Mon, 28 Apr 2014 11:16:37 -0700
 John Stultz john.stu...@linaro.org wrote:
 
   This breaks the API since there is no more misc device /dev/rtc
   available without a udev rule or a link to /dev/rtc0.  
  
  So yea.. I feel like that /dev/rtcN renaming (and API) break (which
  was a huge and annoying pain) was back in the 2.6.18-ish era?
 
  It's very old and linking/renaming is around since then.
 
  But it sounds like the driver/char/rtc bit is dead code, and needs a
  cleanup? Or is there some use of that code that you need that the
  generic RTC layer doesn't have?
 

The driver/char/rtc is not working code and should be a wrapper to the
first rtc device.

  as far as I know, no recent distribution is using the old code
  anymore and the new (well, not so new anymore) framework provides the same 
 functionality.
  

Embedded distribution use it and depending on the /dev/rtc device. So
what is missing is the /dev/rtc misc device 10,135.

- Stefani

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:14 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
> 
> > > > usbcore: registered new interface driver USB-SATA-storage
> > > > USB SATA Mass Storage support registered.
> > > > usb 1-4: new high-speed USB device number 4 using ehci-pci
> > > > : ports detected
> > > 
> > > What driver is this?  I've never heard of USB-SATA-storage.
> > > 
> > 
> > This is a special embedded USB SATA driver written by me. It is mostly a
> > fork of the usb-storage driver but handle only one vendor and product ID
> > and does switch on a port bit. On the other side this vendor and product
> > ID is black listed in the regular usb-storage driver. 
> 
> Is it possible that your driver leaves the device in a strange state 
> where it won't initialize properly?
> 

I don't think so, because the driver was not used in this test due a
missing harddisk. But i will do a test tomorrow in the office.

- Stefani



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
> 
> > I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
> > the following dmesg log:
> > 
> > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> > ehci-pci: EHCI PCI platform driver
> > ehci-pci :00:17.2: EHCI Host Controller
> > ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
> > ehci-pci :00:17.2: irq 22, io mem 0xc0006800
> > ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 5 ports detected
> > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> > ohci_hcd :00:17.0: OHCI Host Controller
> > ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
> > ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 3 ports detected
> > ohci_hcd :00:17.1: OHCI Host Controller
> > ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
> > ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
> > hub 3-0:1.0: USB hub found
> > hub 3-0:1.0: 2 ports detected
> ...
> > usbcore: registered new interface driver USB-SATA-storage
> > USB SATA Mass Storage support registered.
> > usb 1-4: new high-speed USB device number 4 using ehci-pci
> > : ports detected
> 
> What driver is this?  I've never heard of USB-SATA-storage.
> 
> > ohci_hcd :00:17.0: remove, state 1
> > usb usb2: USB disconnect, device number 1
> > usb 2-2: USB disconnect, device number 2
> > usb 2-2.1: USB disconnect, device number 3
> > usb 2-2.2: USB disconnect, device number 4
> > ohci_hcd :00:17.0: USB bus 2 deregistered
> > ohci_hcd :00:17.1: remove, state 1
> > usb usb3: USB disconnect, device number 1
> > ohci_hcd :00:17.1: USB bus 3 deregistered
> > ehci-pci :00:17.2: remove, state 1
> > usb usb1: USB disconnect, device number 1
> > usb 1-2: USB disconnect, device number 2
> > usb 1-4: USB disconnect, device number 4
> > ehci-pci :00:17.2: USB bus 1 deregistered
> > ohci_hcd :00:17.0: OHCI Host Controller
> > ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1
> > ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 3 ports detected
> > ohci_hcd :00:17.1: OHCI Host Controller
> > ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2
> > ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 2 ports detected
> > ehci-pci :00:17.2: EHCI Host Controller
> > ehci-pci :00:17.2: new USB bus registered, assigned bus number 3
> > ehci-pci :00:17.2: irq 22, io mem 0xc0006800
> > ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
> > hub 3-0:1.0: USB hub found
> > hub 3-0:1.0: 5 ports detected
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 3 ports detected
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 2 ports detected
> > usb 3-2: new high-speed USB device number 2 using ehci-pci
> > hub 3-2:1.0: USB hub found
> > hub 3-2:1.0: 4 ports detected
> > usb 3-4: new high-speed USB device number 4 using ehci-pci
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: new high-speed USB device number 5 using ehci-pci
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: new high-speed USB device number 6 using ehci-pci
> > usb 3-4: device descriptor read/8, error -110
> > usb 3-4: device descriptor read/8, error -110
> > usb 3-4: new high-speed USB device number 7 using ehci-pci
> > usb 3-4: device descriptor read/8, error -110
> > usb 3-4: device descriptor read/8, error -110
> > hub 3-0:1.0: unable to enumerate USB device on port 4
> > usb 1-2: new full-speed USB device number 2 using ohci_hcd
> > hub 1-2:1.0: USB hub found
> > hub 1-2:1.0: 2 ports detected
> > usb 2-2: new full-speed USB device number 2 using ohci_hcd
> > usb 2-2: device descriptor read/64, error -110
> > usb 2-2: device descriptor read/64, error -110
> > usb 2-2: new full-speed USB device number 3 using ohci_hcd
> > usb 2-2: device descriptor read/64, error -110
> > usb 2-2: device descriptor read/64, error -110
> > usb 2-2: new full-speed USB device number 4 using ohci_hcd
> > usb 2-2: device descriptor read/8, error -110
> > usb 2-2: device descriptor read/8, error -110
> > usb 2-2: n

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:05 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
> 
> > > One other thing you can try is to increase the reset timeout in 
> > > drivers/usb/host/ehci-hub.c.  This is under the USB_PORT_FEAT_RESET 
> > > case in ehci_hub_control(), around line 1225:
> > > 
> > >   /*
> > >* caller must wait, then call GetPortStatus
> > >* usb 2.0 spec says 50 ms resets on root
> > >*/
> > >   ehci->reset_done [wIndex] = jiffies
> > >   + msecs_to_jiffies (50);
> > > 
> > > Increasing the 50 to 100 or more might help.
> > > 
> > > Alan Stern
> > > 
> > 
> > I tried this, when i increase the value to 1000, the reset and
> > enumeration process will be faster after a kexec: 28 Seconds vs. 162
> > Seconds.
> 
> Even 28 seconds is much longer than it should be.  And a 1000-ms long 
> reset signal is a lot longer than any device should need.
> 
> Anyway, since you saw the same problem after unbind and rebind, you 
> don't have to perform a kexec for testing.
> 

Right, but i would prefer a solution for this. Since it works perfectly
in kernel 3.4 i don't think it is a hardware issue.

- Stefani


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
> On Tue, 15 Apr 2014, Stefani Seibold wrote:
> 
> > I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
> > the following dmesg log:
> > 
> > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> > ehci-pci: EHCI PCI platform driver
> > ehci-pci :00:17.2: EHCI Host Controller
> > ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
> > ehci-pci :00:17.2: irq 22, io mem 0xc0006800
> > ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 5 ports detected
> > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> > ohci_hcd :00:17.0: OHCI Host Controller
> > ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
> > ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 3 ports detected
> > ohci_hcd :00:17.1: OHCI Host Controller
> > ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
> > ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
> > hub 3-0:1.0: USB hub found
> > hub 3-0:1.0: 2 ports detected
> ...
> > usbcore: registered new interface driver USB-SATA-storage
> > USB SATA Mass Storage support registered.
> > usb 1-4: new high-speed USB device number 4 using ehci-pci
> > : ports detected
> 
> What driver is this?  I've never heard of USB-SATA-storage.
> 

This is a special embedded USB SATA driver written by me. It is mostly a
fork of the usb-storage driver but handle only one vendor and product ID
and does switch on a port bit. On the other side this vendor and product
ID is black listed in the regular usb-storage driver. 

> > ohci_hcd :00:17.0: remove, state 1
> > usb usb2: USB disconnect, device number 1
> > usb 2-2: USB disconnect, device number 2
> > usb 2-2.1: USB disconnect, device number 3
> > usb 2-2.2: USB disconnect, device number 4
> > ohci_hcd :00:17.0: USB bus 2 deregistered
> > ohci_hcd :00:17.1: remove, state 1
> > usb usb3: USB disconnect, device number 1
> > ohci_hcd :00:17.1: USB bus 3 deregistered
> > ehci-pci :00:17.2: remove, state 1
> > usb usb1: USB disconnect, device number 1
> > usb 1-2: USB disconnect, device number 2
> > usb 1-4: USB disconnect, device number 4
> > ehci-pci :00:17.2: USB bus 1 deregistered
> > ohci_hcd :00:17.0: OHCI Host Controller
> > ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1
> > ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 3 ports detected
> > ohci_hcd :00:17.1: OHCI Host Controller
> > ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2
> > ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 2 ports detected
> > ehci-pci :00:17.2: EHCI Host Controller
> > ehci-pci :00:17.2: new USB bus registered, assigned bus number 3
> > ehci-pci :00:17.2: irq 22, io mem 0xc0006800
> > ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
> > hub 3-0:1.0: USB hub found
> > hub 3-0:1.0: 5 ports detected
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 3 ports detected
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 2 ports detected
> > usb 3-2: new high-speed USB device number 2 using ehci-pci
> > hub 3-2:1.0: USB hub found
> > hub 3-2:1.0: 4 ports detected
> > usb 3-4: new high-speed USB device number 4 using ehci-pci
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: new high-speed USB device number 5 using ehci-pci
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: device descriptor read/64, error -110
> > usb 3-4: new high-speed USB device number 6 using ehci-pci
> > usb 3-4: device descriptor read/8, error -110
> > usb 3-4: device descriptor read/8, error -110
> > usb 3-4: new high-speed USB device number 7 using ehci-pci
> > usb 3-4: device descriptor read/8, error -110
> > usb 3-4: device descriptor read/8, error -110
> > hub 3-0:1.0: unable to enumerate USB device on port 4
> > usb 1-2: new full-speed USB device number 2 using ohci_hcd
> > hub 1-2:1.0: USB hub found
> > hub 1-2:1.0: 2 ports detected
> > usb 2-2: new full-speed USB device number 2 using ohci_hcd
> > usb 2-2: device descriptor read/64, error -110
> > usb 2-2: device descriptor read/64, error -110
> > usb 2-2: new full-speed USB device number 3 using ohci_hcd
> > usb 2-2: device descript

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:49 -0300 schrieb Thadeu Lima de Souza
Cascardo:
> On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote:
> > Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
> > Cascardo:
> > > On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
> > > > 
> > > > Zitat von Thadeu Lima de Souza Cascardo :
> > > > 
> > > > >On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
> > > > >>
> > > > >>Zitat von Thadeu Lima de Souza Cascardo :
> > > > >>
> > > > >>>On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
> > > > >>>>
> > > > >>>>Zitat von Benjamin Herrenschmidt :
> > > > >>>>
> > > > >>>>>I don't know about EHCI specifically but this is a known issue with
> > > > >>>>>XHCI, I observe similar issues on other powerpc platforms (servers)
> > > > >>>>>and this isn't architecture specific (looks more like actualy xhc
> > > > >>>>>implementation specific).
> > > > >>>>>
> > > > >>>>>Thadeu Cascardo (on CC) has been the one investigating that on our 
> > > > >>>>>side,
> > > > >>>>>he might have more to add including patches.
> > > > >>>>>
> > > > >>>>
> > > > >>>>I have now a kernel 3.14 dmesg log of the problem. After a kexec the
> > > > >>>>kexeced 3.14 kernel shows:
> > > > >>>>
> > > > >>>>[1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
> > > > >>>>[1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
> > > > >>>>assigned bus number 1
> > > > >>>>[1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
> > > > >>>>microseconds.
> > > > >>>>[1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
> > > > >>>>[1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
> > > > >>>>[1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
> > > > >>>>[1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error 
> > > > >>>>-110
> > > > >>>>
> > > > >>>
> > > > >>>What is your controller vendor and device IDs? Is that a TI chip?
> > > > >>>
> > > > >>
> > > > >>Yes it is a TI chip, vendor ID 104c and product ID 8241.
> > > > >>
> > > > >>>Can you check if the patch I sent a month ago fixes it? [1] There's 
> > > > >>>the
> > > > >>>whole story there. In fact, you will also need something like the 
> > > > >>>patch
> > > > >>>below. Can you apply only the first one, verify, and, then, the other
> > > > >>>one as well, and report what worked for you?
> > > > >>>
> > > > >>>[1] http://marc.info/?l=linux-usb=139483181809062=2
> > > > >>>
> > > > >>
> > > > >>I tried the attach patch and it did not help. This is what i
> > > > >>expected because this is a fix in the shutdown path, which will
> > > > >>never called when doing a forced kexec.
> > > > >
> > > > >Hi, Stefani.
> > > > >
> > > > >Did you try with both patches applied? How do you evoke the forced
> > > > >kexec? Is that a kexec on panic? Does it really need to be forced? With
> > > > >no clean shutdown, platform and drivers would need to issue resets, 
> > > > >like
> > > > >you mentioned below, to get the system into a clean state.
> > > > >
> > > > 
> > > > Yes, i applied both patches. But without success.
> > > > 
> > > > IMHO i think it is necessary to bring the device i a clean state
> > > > when the driver use the HW.
> > > > 
> > > > >>
> > > > >>I have a running a 3.10.23 kernel. This kernel do a kexec for a
> > > > >>kernel 3.14. Since the kernel 3.10.23 did not performe a clean
> > > > >>shutdown, the state of the XHCI Controller is undefined. So when
&

Re: X86: kexec issues with i915 in 3.14

[Stefani Seibold]

On Tuesday, 15.04.2014, 16:54 +0800 wrote Jiang Liu:
> Hi Stefanin,
>   As David has mentioned, the warning messages indicates the VGA
> controller hasn't been shut down correctly during reboot and keeps doing
> DMA write operations after loading the new kernel. Do you have found
> any older kernel without this issue?
>   There is a patch set to solve similar issue for crashdump,
> please refer to https://lkml.org/lkml/2014/1/10/518.
> 
> Thanks!
> Gerry
> 

I still understand. 

Maybe the above patch will cure the symptoms but i will not heal the
cause.

But the driver for the intel VGA must not assume the current state of
the device. It is necessary to setup the whole VGA device during the
probe phase. 

Otherwise when kexec a kernel there are tons of log entries or in many
cases a garbaged screen output and the whole kernels will hang.

- Stefani


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
Cascardo:
> On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
> > 
> > Zitat von Thadeu Lima de Souza Cascardo :
> > 
> > >On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
> > >>
> > >>Zitat von Thadeu Lima de Souza Cascardo :
> > >>
> > >>>On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
> > 
> > Zitat von Benjamin Herrenschmidt :
> > 
> > >I don't know about EHCI specifically but this is a known issue with
> > >XHCI, I observe similar issues on other powerpc platforms (servers)
> > >and this isn't architecture specific (looks more like actualy xhc
> > >implementation specific).
> > >
> > >Thadeu Cascardo (on CC) has been the one investigating that on our 
> > >side,
> > >he might have more to add including patches.
> > >
> > 
> > I have now a kernel 3.14 dmesg log of the problem. After a kexec the
> > kexeced 3.14 kernel shows:
> > 
> > [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
> > [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
> > assigned bus number 1
> > [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
> > microseconds.
> > [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
> > [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
> > [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
> > [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
> > 
> > >>>
> > >>>What is your controller vendor and device IDs? Is that a TI chip?
> > >>>
> > >>
> > >>Yes it is a TI chip, vendor ID 104c and product ID 8241.
> > >>
> > >>>Can you check if the patch I sent a month ago fixes it? [1] There's the
> > >>>whole story there. In fact, you will also need something like the patch
> > >>>below. Can you apply only the first one, verify, and, then, the other
> > >>>one as well, and report what worked for you?
> > >>>
> > >>>[1] http://marc.info/?l=linux-usb=139483181809062=2
> > >>>
> > >>
> > >>I tried the attach patch and it did not help. This is what i
> > >>expected because this is a fix in the shutdown path, which will
> > >>never called when doing a forced kexec.
> > >
> > >Hi, Stefani.
> > >
> > >Did you try with both patches applied? How do you evoke the forced
> > >kexec? Is that a kexec on panic? Does it really need to be forced? With
> > >no clean shutdown, platform and drivers would need to issue resets, like
> > >you mentioned below, to get the system into a clean state.
> > >
> > 
> > Yes, i applied both patches. But without success.
> > 
> > IMHO i think it is necessary to bring the device i a clean state
> > when the driver use the HW.
> > 
> > >>
> > >>I have a running a 3.10.23 kernel. This kernel do a kexec for a
> > >>kernel 3.14. Since the kernel 3.10.23 did not performe a clean
> > >>shutdown, the state of the XHCI Controller is undefined. So when
> > >
> > >And the clean shutdown requires both of my patches, for TI chips, as far
> > >as I know. It looks like the problem is issuing a halt when there are
> > >pending URBs.
> > >
> > >>kernel 3.14 will probe XHCI it will find a XHCI controller which was
> > >>not performed a reset.
> > >>
> > >
> > >The problem is not that a reset hasn't been issued. A PCI function reset
> > >should fix most of the problems with a bad device state, when the reset
> > >works. However, the problem is that it was not cleanly shut down. URBs
> > >should have been canceled and removed from the controller queue, and it
> > >should have halted after that.
> > 
> > Again, i think it is the job of the driver to bring the chip in a clean 
> > state
> > before using them. A driver should never expect a reset state of a chip.
> > 
> > >
> > >>So i think it is necessary to reset the XHCI controller and all
> > >>devices on this bus. This is what i do with a "echo 1
> > >>>/sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset" before the kexec.
> > >>
> > >
> > >One way to look at that is making the PCI code issue resets to all buses
> > >before doing any other access. That will make booting more slow, and
> > >there are a lot of other corner cases where this might not be enough.
> > >It's probably more sane to try to get the 3.10.23 kernel to do a clean
> > >shutdown, if possible.
> > >
> > 
> > With this driver design the kexec functionality is usesless on PowerPC.
> > X86 looks a little bit better.
> > 
> > - Stefani
> > 
> > 
> 
> What is the vendor and device ID you are using on your X86 system? This
> is not a matter of what architecture you are using, it's the XHCI
> controller which does not behave as well as the one you are using on
> X86, which is likely an Intel one.
> 

It is an Intel 8086:8c31. But this was only a side note. We need a
generic solution not a vendor specific one. Otherwise kexec is useless
on other architectures.

- Stefani


--
To 

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Montag, den 14.04.2014, 13:58 -0400 schrieb Alan Stern:
> On Mon, 14 Apr 2014, Stefani Seibold wrote:
> 
> > > > An other PowerPC device which is nearly eactly the same HW but without  
> > > > this USB HUB works perfectly.
> > > 
> > > Maybe you should replace that hub with a different brand.
> > > 
> > 
> > Thats not possible, because the Hub is soldered on the board. And it is
> > also not a HW issue, since the Hub works perfectly which all previous
> > kernels including 3.4.
> 
> One other thing you can try is to increase the reset timeout in 
> drivers/usb/host/ehci-hub.c.  This is under the USB_PORT_FEAT_RESET 
> case in ehci_hub_control(), around line 1225:
> 
>   /*
>* caller must wait, then call GetPortStatus
>* usb 2.0 spec says 50 ms resets on root
>*/
>   ehci->reset_done [wIndex] = jiffies
>   + msecs_to_jiffies (50);
> 
> Increasing the 50 to 100 or more might help.
> 
> Alan Stern
> 

I tried this, when i increase the value to 1000, the reset and
enumeration process will be faster after a kexec: 28 Seconds vs. 162
Seconds.

- Stefani

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern:
> On Mon, 14 Apr 2014 stef...@seibold.net wrote:
> 
> > Zitat von Alan Stern :
> > 
> > 
> > >> <6>[  167.936921] usb 2-2.1: new full-speed USB device number 3  
> > >> using ohci-pci
> > >> <6>[  168.067890] usb 2-2.1: New USB device found, idVendor=076b,
> > >> idProduct=a021
> > >> <6>[  168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
> > >> SerialNumber=0
> > >> <6>[  168.082226] usb 2-2.1: Product: Smart Card Reader
> > >> <6>[  168.086963] usb 2-2.1: Manufacturer: USB
> > >> <6>[  168.172893] usb 2-2.2: new low-speed USB device number 4  
> > >> using ohci-pci
> > >> <6>[  168.300839] usb 2-2.2: New USB device found, idVendor=0aad,
> > >> idProduct=0024
> > >> <6>[  168.307823] usb 2-2.2: New USB device strings: Mfr=1, Product=2,
> > >> SerialNumber=0
> > >> <6>[  168.315180] usb 2-2.2: Product: FrontPanel USB Keyboard
> > >> <6>[  168.320436] usb 2-2.2: Manufacturer: Rohde
> > >> <6>[  168.337895] input: Rohde FrontPanel USB Keyboard as
> > >> /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
> > >> <6>[  168.360988] input: Rohde FrontPanel USB Keyboard as
> > >> /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1
> > >
> > > Since some devices work and some don't, maybe part of the problem lies
> > > in the particular devices.
> > >
> > 
> > The problem lies on the "Bus 001 Device 002: ID 0424:2514 Standard  
> > Microsystems Corp. USB 2.0 Hub", which hangs for arround 162 seconds  
> > after a kexec.
> > 
> > The "Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card  
> > Reader" and "Bus 002 Device 004: ID 0aad:0024 Rohde & Schwarz GmbH &  
> > Co. KG" are attached to this Hub.

> > > What about if you just do:
> > >
> > >   rmmod ehci-pci
> > >   modprobe ehci-pci
> > >
> > 
> > The kernel is monolitic because the USB HW is needed in a early boot  
> > stage. The problem also occurs with ehci-fsl used in by an other  
> > PowerPC device, which is a part of the SoC and is not attached to the  
> > PCI bus.
> > 
> > One thing is that the "echo 1  
> >  >/sys/bus/pci/drivers/ehci-pci/\:00\:17.2/reset" workaround will  
> > no longer work for kernel 3.14.
> 
> Instead, you could try
> 
>   echo :00:17.2 >/sys/bus/pci/drivers/ehci-pci/unbind
>   echo :00:17.2 >/sys/bus/pci/drivers/ehci-pci/bind
> 

I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
the following dmesg log:

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-pci :00:17.2: EHCI Host Controller
ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
ehci-pci :00:17.2: irq 22, io mem 0xc0006800
ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd :00:17.0: OHCI Host Controller
ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd :00:17.1: OHCI Host Controller
ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
mpc-i2c fef03000.i2c: timeout 100 us
rtc-rs5c372 0-0032: rs5c372a found, 24hr, driver version 0.6
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
mpc-i2c fef03100.i2c: timeout 100 us
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
rsfrontp: using key table SMBV (117)
usbcore: registered new interface driver rsfrontp
rsfrontp: R USB HID Frontpanel driver (v1.2)
usbcore: registered new interface driver rsknop
rsknop: R USB HID Knop support (v1.4)
usb 1-2: new high-speed USB device number 2 using ehci-pci
zram: Created 1 device(s) ...
TCP: cubic registered
NET: Registered protocol family 17
rtc-rs5c372 0-0032: setting system clock to 2014-04-14 14:51:50 UTC (1397487110)
Freeing unused kernel memory: 996K (c032e000 - c0427000)
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 4 ports detected
yaffs: dev is 32505859 name is "mtdblock3" rw
yaffs: passed flags ""
yaffs: yaffs: Attempting MTD mount of 31.3,"mtdblock3"
yaffs: auto selecting yaffs2
yaffs: yaffs_read_super: is_checkpointed 1
usb 2-2: new full-speed USB device number 2 using ohci_hcd
hub 2-2:1.0: USB hub found
hub 2-2:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
usb 2-2.1: new full-speed USB device number 3 using ohci_hcd
usb 2-2.2: new low-speed USB device number 4 using ohci_hcd
input: Rohde FrontPanel USB Keyboard as 
/devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
fsl-gianfar fef24000.ethernet eth0: mac: 00:90:b8:1b:36:37
input: Rohde 

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern:
 On Mon, 14 Apr 2014 stef...@seibold.net wrote:
 
  Zitat von Alan Stern st...@rowland.harvard.edu:
  
  
   6[  167.936921] usb 2-2.1: new full-speed USB device number 3  
   using ohci-pci
   6[  168.067890] usb 2-2.1: New USB device found, idVendor=076b,
   idProduct=a021
   6[  168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
   SerialNumber=0
   6[  168.082226] usb 2-2.1: Product: Smart Card Reader
   6[  168.086963] usb 2-2.1: Manufacturer: USB
   6[  168.172893] usb 2-2.2: new low-speed USB device number 4  
   using ohci-pci
   6[  168.300839] usb 2-2.2: New USB device found, idVendor=0aad,
   idProduct=0024
   6[  168.307823] usb 2-2.2: New USB device strings: Mfr=1, Product=2,
   SerialNumber=0
   6[  168.315180] usb 2-2.2: Product: FrontPanel USB Keyboard
   6[  168.320436] usb 2-2.2: Manufacturer: RohdeSchwarz
   6[  168.337895] input: RohdeSchwarz FrontPanel USB Keyboard as
   /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
   6[  168.360988] input: RohdeSchwarz FrontPanel USB Keyboard as
   /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1
  
   Since some devices work and some don't, maybe part of the problem lies
   in the particular devices.
  
  
  The problem lies on the Bus 001 Device 002: ID 0424:2514 Standard  
  Microsystems Corp. USB 2.0 Hub, which hangs for arround 162 seconds  
  after a kexec.
  
  The Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card  
  Reader and Bus 002 Device 004: ID 0aad:0024 Rohde  Schwarz GmbH   
  Co. KG are attached to this Hub.

   What about if you just do:
  
 rmmod ehci-pci
 modprobe ehci-pci
  
  
  The kernel is monolitic because the USB HW is needed in a early boot  
  stage. The problem also occurs with ehci-fsl used in by an other  
  PowerPC device, which is a part of the SoC and is not attached to the  
  PCI bus.
  
  One thing is that the echo 1  
   /sys/bus/pci/drivers/ehci-pci/\:00\:17.2/reset workaround will  
  no longer work for kernel 3.14.
 
 Instead, you could try
 
   echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/unbind
   echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/bind
 

I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
the following dmesg log:

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-pci :00:17.2: EHCI Host Controller
ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
ehci-pci :00:17.2: irq 22, io mem 0xc0006800
ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd :00:17.0: OHCI Host Controller
ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd :00:17.1: OHCI Host Controller
ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
mpc-i2c fef03000.i2c: timeout 100 us
rtc-rs5c372 0-0032: rs5c372a found, 24hr, driver version 0.6
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
mpc-i2c fef03100.i2c: timeout 100 us
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
rsfrontp: using key table SMBV (117)
usbcore: registered new interface driver rsfrontp
rsfrontp: RS USB HID Frontpanel driver (v1.2)
usbcore: registered new interface driver rsknop
rsknop: RS USB HID Knop support (v1.4)
usb 1-2: new high-speed USB device number 2 using ehci-pci
zram: Created 1 device(s) ...
TCP: cubic registered
NET: Registered protocol family 17
rtc-rs5c372 0-0032: setting system clock to 2014-04-14 14:51:50 UTC (1397487110)
Freeing unused kernel memory: 996K (c032e000 - c0427000)
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 4 ports detected
yaffs: dev is 32505859 name is mtdblock3 rw
yaffs: passed flags 
yaffs: yaffs: Attempting MTD mount of 31.3,mtdblock3
yaffs: auto selecting yaffs2
yaffs: yaffs_read_super: is_checkpointed 1
usb 2-2: new full-speed USB device number 2 using ohci_hcd
hub 2-2:1.0: USB hub found
hub 2-2:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
usb 2-2.1: new full-speed USB device number 3 using ohci_hcd
usb 2-2.2: new low-speed USB device number 4 using ohci_hcd
input: RohdeSchwarz FrontPanel USB Keyboard as 
/devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
fsl-gianfar fef24000.ethernet eth0: mac: 00:90:b8:1b:36:37
input: RohdeSchwarz FrontPanel USB Keyboard as 
/devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1
fsl-gianfar fef24000.ethernet eth0: Running 

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Montag, den 14.04.2014, 13:58 -0400 schrieb Alan Stern:
 On Mon, 14 Apr 2014, Stefani Seibold wrote:
 
An other PowerPC device which is nearly eactly the same HW but without  
this USB HUB works perfectly.
   
   Maybe you should replace that hub with a different brand.
   
  
  Thats not possible, because the Hub is soldered on the board. And it is
  also not a HW issue, since the Hub works perfectly which all previous
  kernels including 3.4.
 
 One other thing you can try is to increase the reset timeout in 
 drivers/usb/host/ehci-hub.c.  This is under the USB_PORT_FEAT_RESET 
 case in ehci_hub_control(), around line 1225:
 
   /*
* caller must wait, then call GetPortStatus
* usb 2.0 spec says 50 ms resets on root
*/
   ehci-reset_done [wIndex] = jiffies
   + msecs_to_jiffies (50);
 
 Increasing the 50 to 100 or more might help.
 
 Alan Stern
 

I tried this, when i increase the value to 1000, the reset and
enumeration process will be faster after a kexec: 28 Seconds vs. 162
Seconds.

- Stefani

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
Cascardo:
 On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:
  
  Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
  
  On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:
  
  Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:
  
  On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
  
  Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:
  
  I don't know about EHCI specifically but this is a known issue with
  XHCI, I observe similar issues on other powerpc platforms (servers)
  and this isn't architecture specific (looks more like actualy xhc
  implementation specific).
  
  Thadeu Cascardo (on CC) has been the one investigating that on our 
  side,
  he might have more to add including patches.
  
  
  I have now a kernel 3.14 dmesg log of the problem. After a kexec the
  kexeced 3.14 kernel shows:
  
  [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
  [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
  assigned bus number 1
  [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
  microseconds.
  [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
  [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
  [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
  [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
  
  
  What is your controller vendor and device IDs? Is that a TI chip?
  
  
  Yes it is a TI chip, vendor ID 104c and product ID 8241.
  
  Can you check if the patch I sent a month ago fixes it? [1] There's the
  whole story there. In fact, you will also need something like the patch
  below. Can you apply only the first one, verify, and, then, the other
  one as well, and report what worked for you?
  
  [1] http://marc.info/?l=linux-usbm=139483181809062w=2
  
  
  I tried the attach patch and it did not help. This is what i
  expected because this is a fix in the shutdown path, which will
  never called when doing a forced kexec.
  
  Hi, Stefani.
  
  Did you try with both patches applied? How do you evoke the forced
  kexec? Is that a kexec on panic? Does it really need to be forced? With
  no clean shutdown, platform and drivers would need to issue resets, like
  you mentioned below, to get the system into a clean state.
  
  
  Yes, i applied both patches. But without success.
  
  IMHO i think it is necessary to bring the device i a clean state
  when the driver use the HW.
  
  
  I have a running a 3.10.23 kernel. This kernel do a kexec for a
  kernel 3.14. Since the kernel 3.10.23 did not performe a clean
  shutdown, the state of the XHCI Controller is undefined. So when
  
  And the clean shutdown requires both of my patches, for TI chips, as far
  as I know. It looks like the problem is issuing a halt when there are
  pending URBs.
  
  kernel 3.14 will probe XHCI it will find a XHCI controller which was
  not performed a reset.
  
  
  The problem is not that a reset hasn't been issued. A PCI function reset
  should fix most of the problems with a bad device state, when the reset
  works. However, the problem is that it was not cleanly shut down. URBs
  should have been canceled and removed from the controller queue, and it
  should have halted after that.
  
  Again, i think it is the job of the driver to bring the chip in a clean 
  state
  before using them. A driver should never expect a reset state of a chip.
  
  
  So i think it is necessary to reset the XHCI controller and all
  devices on this bus. This is what i do with a echo 1
  /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.
  
  
  One way to look at that is making the PCI code issue resets to all buses
  before doing any other access. That will make booting more slow, and
  there are a lot of other corner cases where this might not be enough.
  It's probably more sane to try to get the 3.10.23 kernel to do a clean
  shutdown, if possible.
  
  
  With this driver design the kexec functionality is usesless on PowerPC.
  X86 looks a little bit better.
  
  - Stefani
  
  
 
 What is the vendor and device ID you are using on your X86 system? This
 is not a matter of what architecture you are using, it's the XHCI
 controller which does not behave as well as the one you are using on
 X86, which is likely an Intel one.
 

It is an Intel 8086:8c31. But this was only a side note. We need a
generic solution not a vendor specific one. Otherwise kexec is useless
on other architectures.

- Stefani


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: X86: kexec issues with i915 in 3.14

[Stefani Seibold]

On Tuesday, 15.04.2014, 16:54 +0800 wrote Jiang Liu:
 Hi Stefanin,
   As David has mentioned, the warning messages indicates the VGA
 controller hasn't been shut down correctly during reboot and keeps doing
 DMA write operations after loading the new kernel. Do you have found
 any older kernel without this issue?
   There is a patch set to solve similar issue for crashdump,
 please refer to https://lkml.org/lkml/2014/1/10/518.
 
 Thanks!
 Gerry
 

I still understand. 

Maybe the above patch will cure the symptoms but i will not heal the
cause.

But the driver for the intel VGA must not assume the current state of
the device. It is necessary to setup the whole VGA device during the
probe phase. 

Otherwise when kexec a kernel there are tons of log entries or in many
cases a garbaged screen output and the whole kernels will hang.

- Stefani


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:49 -0300 schrieb Thadeu Lima de Souza
Cascardo:
 On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote:
  Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza
  Cascardo:
   On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote:

Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:

On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote:

Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com:

On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:

Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:

I don't know about EHCI specifically but this is a known issue with
XHCI, I observe similar issues on other powerpc platforms (servers)
and this isn't architecture specific (looks more like actualy xhc
implementation specific).

Thadeu Cascardo (on CC) has been the one investigating that on our 
side,
he might have more to add including patches.


I have now a kernel 3.14 dmesg log of the problem. After a kexec the
kexeced 3.14 kernel shows:

[1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
[1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
assigned bus number 1
[1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
microseconds.
[1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
[1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
[1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
[1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error 
-110


What is your controller vendor and device IDs? Is that a TI chip?


Yes it is a TI chip, vendor ID 104c and product ID 8241.

Can you check if the patch I sent a month ago fixes it? [1] There's 
the
whole story there. In fact, you will also need something like the 
patch
below. Can you apply only the first one, verify, and, then, the other
one as well, and report what worked for you?

[1] http://marc.info/?l=linux-usbm=139483181809062w=2


I tried the attach patch and it did not help. This is what i
expected because this is a fix in the shutdown path, which will
never called when doing a forced kexec.

Hi, Stefani.

Did you try with both patches applied? How do you evoke the forced
kexec? Is that a kexec on panic? Does it really need to be forced? With
no clean shutdown, platform and drivers would need to issue resets, 
like
you mentioned below, to get the system into a clean state.


Yes, i applied both patches. But without success.

IMHO i think it is necessary to bring the device i a clean state
when the driver use the HW.


I have a running a 3.10.23 kernel. This kernel do a kexec for a
kernel 3.14. Since the kernel 3.10.23 did not performe a clean
shutdown, the state of the XHCI Controller is undefined. So when

And the clean shutdown requires both of my patches, for TI chips, as 
far
as I know. It looks like the problem is issuing a halt when there are
pending URBs.

kernel 3.14 will probe XHCI it will find a XHCI controller which was
not performed a reset.


The problem is not that a reset hasn't been issued. A PCI function 
reset
should fix most of the problems with a bad device state, when the reset
works. However, the problem is that it was not cleanly shut down. URBs
should have been canceled and removed from the controller queue, and it
should have halted after that.

Again, i think it is the job of the driver to bring the chip in a clean 
state
before using them. A driver should never expect a reset state of a chip.


So i think it is necessary to reset the XHCI controller and all
devices on this bus. This is what i do with a echo 1
/sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec.


One way to look at that is making the PCI code issue resets to all 
buses
before doing any other access. That will make booting more slow, and
there are a lot of other corner cases where this might not be enough.
It's probably more sane to try to get the 3.10.23 kernel to do a clean
shutdown, if possible.


With this driver design the kexec functionality is usesless on PowerPC.
X86 looks a little bit better.

- Stefani


   
   What is the vendor and device ID you are using on your X86 system? This
   is not a matter of what architecture you are using, it's the XHCI
   controller which does not behave as well as the one you are using on
   X86, which is likely an Intel one.
   
  
  It is an Intel 8086:8c31. But this was only a side note. We need a
  generic solution not a vendor specific one. Otherwise kexec

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
  I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
  the following dmesg log:
  
  ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
  ehci-pci: EHCI PCI platform driver
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 5 ports detected
  ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 2 ports detected
 ...
  usbcore: registered new interface driver USB-SATA-storage
  USB SATA Mass Storage support registered.
  usb 1-4: new high-speed USB device number 4 using ehci-pci
  : ports detected
 
 What driver is this?  I've never heard of USB-SATA-storage.
 

This is a special embedded USB SATA driver written by me. It is mostly a
fork of the usb-storage driver but handle only one vendor and product ID
and does switch on a port bit. On the other side this vendor and product
ID is black listed in the regular usb-storage driver. 

  ohci_hcd :00:17.0: remove, state 1
  usb usb2: USB disconnect, device number 1
  usb 2-2: USB disconnect, device number 2
  usb 2-2.1: USB disconnect, device number 3
  usb 2-2.2: USB disconnect, device number 4
  ohci_hcd :00:17.0: USB bus 2 deregistered
  ohci_hcd :00:17.1: remove, state 1
  usb usb3: USB disconnect, device number 1
  ohci_hcd :00:17.1: USB bus 3 deregistered
  ehci-pci :00:17.2: remove, state 1
  usb usb1: USB disconnect, device number 1
  usb 1-2: USB disconnect, device number 2
  usb 1-4: USB disconnect, device number 4
  ehci-pci :00:17.2: USB bus 1 deregistered
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 3
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 5 ports detected
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  usb 3-2: new high-speed USB device number 2 using ehci-pci
  hub 3-2:1.0: USB hub found
  hub 3-2:1.0: 4 ports detected
  usb 3-4: new high-speed USB device number 4 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 5 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 6 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: new high-speed USB device number 7 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  hub 3-0:1.0: unable to enumerate USB device on port 4
  usb 1-2: new full-speed USB device number 2 using ohci_hcd
  hub 1-2:1.0: USB hub found
  hub 1-2:1.0: 2 ports detected
  usb 2-2: new full-speed USB device number 2 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 3 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 4 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: new full-speed USB device number 5 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  hub 2-0:1.0: unable to enumerate USB device on port 2
  usb 1-2.1: new full-speed USB device number 3 using ohci_hcd
  usb 1-2.2: new low-speed USB device number 4 using ohci_hcd
  input: RohdeSchwarz FrontPanel USB Keyboard as 
  /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input2
  input

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:05 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
   One other thing you can try is to increase the reset timeout in 
   drivers/usb/host/ehci-hub.c.  This is under the USB_PORT_FEAT_RESET 
   case in ehci_hub_control(), around line 1225:
   
 /*
  * caller must wait, then call GetPortStatus
  * usb 2.0 spec says 50 ms resets on root
  */
 ehci-reset_done [wIndex] = jiffies
 + msecs_to_jiffies (50);
   
   Increasing the 50 to 100 or more might help.
   
   Alan Stern
   
  
  I tried this, when i increase the value to 1000, the reset and
  enumeration process will be faster after a kexec: 28 Seconds vs. 162
  Seconds.
 
 Even 28 seconds is much longer than it should be.  And a 1000-ms long 
 reset signal is a lot longer than any device should need.
 
 Anyway, since you saw the same problem after unbind and rebind, you 
 don't have to perform a kexec for testing.
 

Right, but i would prefer a solution for this. Since it works perfectly
in kernel 3.4 i don't think it is a hardware issue.

- Stefani


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
  I did a unbind and bind of the ehci-pci and ohci-pci, after this i got
  the following dmesg log:
  
  ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
  ehci-pci: EHCI PCI platform driver
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 1
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 5 ports detected
  ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 2 ports detected
 ...
  usbcore: registered new interface driver USB-SATA-storage
  USB SATA Mass Storage support registered.
  usb 1-4: new high-speed USB device number 4 using ehci-pci
  : ports detected
 
 What driver is this?  I've never heard of USB-SATA-storage.
 
  ohci_hcd :00:17.0: remove, state 1
  usb usb2: USB disconnect, device number 1
  usb 2-2: USB disconnect, device number 2
  usb 2-2.1: USB disconnect, device number 3
  usb 2-2.2: USB disconnect, device number 4
  ohci_hcd :00:17.0: USB bus 2 deregistered
  ohci_hcd :00:17.1: remove, state 1
  usb usb3: USB disconnect, device number 1
  ohci_hcd :00:17.1: USB bus 3 deregistered
  ehci-pci :00:17.2: remove, state 1
  usb usb1: USB disconnect, device number 1
  usb 1-2: USB disconnect, device number 2
  usb 1-4: USB disconnect, device number 4
  ehci-pci :00:17.2: USB bus 1 deregistered
  ohci_hcd :00:17.0: OHCI Host Controller
  ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1
  ohci_hcd :00:17.0: irq 20, io mem 0xc0004000
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  ohci_hcd :00:17.1: OHCI Host Controller
  ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2
  ohci_hcd :00:17.1: irq 21, io mem 0xc0005000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  ehci-pci :00:17.2: EHCI Host Controller
  ehci-pci :00:17.2: new USB bus registered, assigned bus number 3
  ehci-pci :00:17.2: irq 22, io mem 0xc0006800
  ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: 5 ports detected
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 3 ports detected
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: 2 ports detected
  usb 3-2: new high-speed USB device number 2 using ehci-pci
  hub 3-2:1.0: USB hub found
  hub 3-2:1.0: 4 ports detected
  usb 3-4: new high-speed USB device number 4 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 5 using ehci-pci
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: device descriptor read/64, error -110
  usb 3-4: new high-speed USB device number 6 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: new high-speed USB device number 7 using ehci-pci
  usb 3-4: device descriptor read/8, error -110
  usb 3-4: device descriptor read/8, error -110
  hub 3-0:1.0: unable to enumerate USB device on port 4
  usb 1-2: new full-speed USB device number 2 using ohci_hcd
  hub 1-2:1.0: USB hub found
  hub 1-2:1.0: 2 ports detected
  usb 2-2: new full-speed USB device number 2 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 3 using ohci_hcd
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: device descriptor read/64, error -110
  usb 2-2: new full-speed USB device number 4 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: new full-speed USB device number 5 using ohci_hcd
  usb 2-2: device descriptor read/8, error -110
  usb 2-2: device descriptor read/8, error -110
  hub 2-0:1.0: unable to enumerate USB device on port 2
  usb 1-2.1: new full-speed USB device number 3 using ohci_hcd
  usb 1-2.2: new low-speed USB device number 4 using ohci_hcd
  input: RohdeSchwarz FrontPanel USB Keyboard as 
  /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input2
  input: RohdeSchwarz FrontPanel USB Keyboard as 
  /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.1/input/input3
 
 So two devices failed to initialize after the drivers were rebound: 3-4 
 and 2-2.  We know that 3-4 was the mass-storage device, but I can't 
 tell from this log

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Dienstag, den 15.04.2014, 15:14 -0400 schrieb Alan Stern:
 On Tue, 15 Apr 2014, Stefani Seibold wrote:
 
usbcore: registered new interface driver USB-SATA-storage
USB SATA Mass Storage support registered.
usb 1-4: new high-speed USB device number 4 using ehci-pci
: ports detected
   
   What driver is this?  I've never heard of USB-SATA-storage.
   
  
  This is a special embedded USB SATA driver written by me. It is mostly a
  fork of the usb-storage driver but handle only one vendor and product ID
  and does switch on a port bit. On the other side this vendor and product
  ID is black listed in the regular usb-storage driver. 
 
 Is it possible that your driver leaves the device in a strange state 
 where it won't initialize properly?
 

I don't think so, because the driver was not used in this test due a
missing harddisk. But i will do a test tomorrow in the office.

- Stefani



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: X86: kexec issues with i915 in 3.14

[Stefani Seibold]

Am Montag, den 14.04.2014, 00:28 + schrieb Woodhouse, David:
> On Sun, 2014-04-13 at 22:01 +0200, Stefani Seibold wrote:
> > Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel
> > log messages:
> > 
> > [0.262754] IOMMU: Setting identity map for device :00:1a.0 
> > [0x7c45f000 - 0x7c46bfff]
> > [0.262780] IOMMU: Setting identity map for device :00:14.0 
> > [0x7c45f000 - 0x7c46bfff]
> > [0.262798] IOMMU: Prepare 0-16MiB unity mapping for LPC
> > [0.262807] IOMMU: Setting identity map for device :00:1f.0 [0x0 - 
> > 0xff]
> > [0.262948] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> > [0.262948] dmar: DRHD: handling fault status reg 3
> > [0.262951] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
> > e000 
> > DMAR:[fault reason 05] PTE Write access is not set
> 
> I'm inferring from the subject line that you mean kexec, not
> "rebooting"?
> 

Rebooting via BIOS works, but booting via kexec will result the message
storm or hang kernel with a corrupted display.

> It looks like a peripheral device is being left active and doing DMA by
> the previous kernel, rather than being shut down. So as soon as the new
> kernel resets the IOMMU mappings, that peripheral device is causing
> faults.
> 
> We really ought to rate-limit the faults and isolate the offending
> device before there are 21,000 of them. As discussed elsewhere recently,
> we could do with a way to tell the PCI layer that it offended us but I
> suppose we could at *least* stop the IOMMU from reporting faults for it.
> 
> Is this new behaviour? I'm not sure why this should have changed...
> 

I can reproduce the behaviour also with a 3.13.7 kernel.

One thing i found after the end of the 21.000 messages was a GPU crash:

[5.002484] r8169 :03:00.0 eth0: link up
[5.002489] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[6.745051] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... 
blitter ring idle
[   11.743768] [drm] stuck on render ring
[   11.743773] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[   11.743774] [drm] GPU hangs can indicate a bug anywhere in the entire gfx 
stack, including userspace.
[   11.743775] [drm] Please file a _new_ bug report on bugs.freedesktop.org 
against DRI -> DRM/Intel
[   11.743777] [drm] drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.
[   11.743778] [drm] The gpu crash dump is required to analyze gpu hangs, so 
please always attach it.
[   14.240743] systemd-journald[158]: File 
/var/log/journal/bb613621feef82d686edde0046e9bcea/user-1000.journal corrupted 
or uncleanly shut down, renaming and replacing.

- Stefani


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: EHCI hotplug kernel crash in kernel 3.14 and 3.13

[Stefani Seibold]

Hi Alan,

the patch fix the issue. I tested it on a notebook with a cardbus
controller and on desktop machine with a thunderbolt interface. Both are
working.

Thunderbolt will sometimes crash but i think this is a issue with
dynamic added pci bridges, which cause a lot of trouble and headache  to
me.

Thanks,

Greetings,
Stefani

Am Montag, den 14.04.2014, 11:11 -0400 schrieb Alan Stern:
> On Sun, 13 Apr 2014, Stefani Seibold wrote:
> 
> > A hot plug of an USB 2.0 EHCI controller cardbus card will result in a
> > kernel crash. This is the kernel log of a vanilla 3.14 x86_64 kernel. I
> > will attach my kernel config.
> 
> > [   70.419755] ehci-pci :04:00.2: EHCI Host Controller
> > [   70.419874] ehci-pci :04:00.2: new USB bus registered, assigned bus 
> > number 9
> > [   70.419980] ehci-pci :04:00.2: irq 19, io mem 0xf1402000
> > [   70.422796] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> > [   70.424894] ohci-pci: OHCI PCI platform driver
> > [   70.425072] ehci-pci :04:00.2: USB 2.0 started, EHCI 0.95
> > [   70.425132] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002
> > [   70.425135] usb usb9: New USB device strings: Mfr=3, Product=2, 
> > SerialNumber=1
> > [   70.425138] usb usb9: Product: EHCI Host Controller
> > [   70.425141] usb usb9: Manufacturer: Linux 3.14.0 ehci_hcd
> > [   70.425144] usb usb9: SerialNumber: :04:00.2
> > [   70.425332] hub 9-0:1.0: USB hub found
> > [   70.425344] hub 9-0:1.0: 5 ports detected
> > [   70.425556] BUG: unable to handle kernel NULL pointer dereference at 
> > 0040
> > [   70.425560] IP: [] usb_set_configuration+0x1c/0x7d0
> > [   70.425568] PGD 30d571067 PUD 30d570067 PMD 0 
> > [   70.425572] Oops:  [#1] PREEMPT SMP 
> > [   70.425576] Modules linked in: ohci_pci(+) ohci_hcd rfcomm btusb ppdev 
> > intel_agp intel_gtt 8250 video parport_pc parport serial_core nvidia(PO) 
> > drm agpgart
> > [   70.425604] CPU: 3 PID: 83 Comm: pccardd Tainted: P   O 3.14.0 #1
> > [   70.425607] Hardware name: Dell Inc. Precision M6400 
> > /0G841G, BIOS A13 06/05/2013
> > [   70.425609] task: 88030eefe150 ti: 88030ef86000 task.ti: 
> > 88030ef86000
> > [   70.425611] RIP: 0010:[]  [] 
> > usb_set_configuration+0x1c/0x7d0
> > [   70.425615] RSP: 0018:88030ef87ba0  EFLAGS: 00010286
> > [   70.425617] RAX: 88030c7ce800 RBX:  RCX: 
> > 88030ea57000
> > [   70.425619] RDX: 88030dcb6800 RSI: 0001 RDI: 
> > 
> > [   70.425620] RBP: 88030ef87c38 R08: 88030dfa6910 R09: 
> > 
> > [   70.425622] R10: 4e2e R11:  R12: 
> > 
> > [   70.425624] R13:  R14: 814a0b80 R15: 
> > 88030c7ce800
> > [   70.425626] FS:  () GS:88031fd8() 
> > knlGS:
> > [   70.425628] CS:  0010 DS:  ES:  CR0: 8005003b
> > [   70.425630] CR2: 0040 CR3: 00030c714000 CR4: 
> > 000407e0
> > [   70.425631] Stack:
> > [   70.425632]  81340110 814a0b80 88030ef87bc8 
> > 817b3858
> > [   70.425636]  88030dcb6898 88030ef87c00 813d6daf 
> > 88030f429000
> > [   70.425640]  00010ef87bf0 813d4737 88030ef87c00 
> > 8133f19a
> > [   70.425644] Call Trace:
> > [   70.425650]  [] ? pci_do_find_bus+0x70/0x70
> > [   70.425653]  [] ? hcd_pci_suspend_noirq+0xa0/0xa0
> > [   70.425659]  [] ? klist_iter_exit+0x18/0x30
> > [   70.425663]  [] ? bus_find_device+0x7f/0xb0
> > [   70.425666]  [] ? put_device+0x17/0x20
> > [   70.425669]  [] ? pci_dev_put+0x1a/0x20
> > [   70.425672]  [] ? pci_get_dev_by_id+0x61/0x90
> > [   70.425675]  [] ? hcd_pci_suspend_noirq+0xa0/0xa0
> > [   70.425679]  [] ehci_post_add+0x4b/0x60
> > [   70.425682]  [] for_each_companion+0x80/0xa0
> > [   70.425685]  [] usb_hcd_pci_probe+0x474/0x4e0
> 
> I think I see the problem; the driver data for the companion controller 
> gets set before we expect it.  The patch below should help, by adding a 
> check to see that the companion's root hub has been allocated.
> 
> Alan Stern
> 
> 
> 
> Index: usb-3.14/drivers/usb/core/hcd-pci.c
> ===
> --- usb-3.14.orig/drivers/usb/core/hcd-pci.c
> +++ usb-3.14/drivers/usb/core/hcd-pci.c
> @@ -75,7 +75,7 @@ static void for_each_companion(struct pc
>   PCI_SLOT(companion->devf

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern:
> On Mon, 14 Apr 2014 stef...@seibold.net wrote:
> 
> > Zitat von Alan Stern :
> > 
> > 
> > >> <6>[  167.936921] usb 2-2.1: new full-speed USB device number 3  
> > >> using ohci-pci
> > >> <6>[  168.067890] usb 2-2.1: New USB device found, idVendor=076b,
> > >> idProduct=a021
> > >> <6>[  168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
> > >> SerialNumber=0
> > >> <6>[  168.082226] usb 2-2.1: Product: Smart Card Reader
> > >> <6>[  168.086963] usb 2-2.1: Manufacturer: USB
> > >> <6>[  168.172893] usb 2-2.2: new low-speed USB device number 4  
> > >> using ohci-pci
> > >> <6>[  168.300839] usb 2-2.2: New USB device found, idVendor=0aad,
> > >> idProduct=0024
> > >> <6>[  168.307823] usb 2-2.2: New USB device strings: Mfr=1, Product=2,
> > >> SerialNumber=0
> > >> <6>[  168.315180] usb 2-2.2: Product: FrontPanel USB Keyboard
> > >> <6>[  168.320436] usb 2-2.2: Manufacturer: Rohde
> > >> <6>[  168.337895] input: Rohde FrontPanel USB Keyboard as
> > >> /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
> > >> <6>[  168.360988] input: Rohde FrontPanel USB Keyboard as
> > >> /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1
> > >
> > > Since some devices work and some don't, maybe part of the problem lies
> > > in the particular devices.
> > >
> > 
> > The problem lies on the "Bus 001 Device 002: ID 0424:2514 Standard  
> > Microsystems Corp. USB 2.0 Hub", which hangs for arround 162 seconds  
> > after a kexec.
> > 
> > The "Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card  
> > Reader" and "Bus 002 Device 004: ID 0aad:0024 Rohde & Schwarz GmbH &  
> > Co. KG" are attached to this Hub.
> 
> Actually, it looks like they are plugged into the Texas Instruments
> hub, not the Standard Microsystems hub (because they are on bus 2, not
> bus 1).  Did you rearrange the USB cables?
> 

You are right, sorry for the confusion. I can't rearrange the cables
because the HUB is on board.

> > An other PowerPC device which is nearly eactly the same HW but without  
> > this USB HUB works perfectly.
> 
> Maybe you should replace that hub with a different brand.
> 

Thats not possible, because the Hub is soldered on the board. And it is
also not a HW issue, since the Hub works perfectly which all previous
kernels including 3.4.

> > >> This is the output of lsusb:
> > >>
> > >> Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
> > >> Bus 001 Device 004: ID 0928:0007 Oxford Semiconductor, Ltd
> > >> Bus 002 Device 002: ID 0451:2036 Texas Instruments, Inc. TUSB2036 Hub
> > >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > >> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > >> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > >> Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card Reader
> > >> Bus 002 Device 004: ID 0aad:0024 Rohde & Schwarz GmbH & Co. KG
> 
> Here, the only device that might be plugged into the Standard
> Microsystems hub is the Oxford Semiconductor thing (whatever it is).
> 
> > > What about if you just do:
> > >
> > >   rmmod ehci-pci
> > >   modprobe ehci-pci
> > >
> > 
> > The kernel is monolitic because the USB HW is needed in a early boot  
> > stage. The problem also occurs with ehci-fsl used in by an other  
> > PowerPC device, which is a part of the SoC and is not attached to the  
> > PCI bus.
> > 
> > One thing is that the "echo 1  
> >  >/sys/bus/pci/drivers/ehci-pci/\:00\:17.2/reset" workaround will  
> > no longer work for kernel 3.14.
> 
> Instead, you could try
> 
>   echo :00:17.2 >/sys/bus/pci/drivers/ehci-pci/unbind
>   echo :00:17.2 >/sys/bus/pci/drivers/ehci-pci/bind
> 

I am now at home. I will do this tomorrow. Thanks so much for your
support.

- Stefani



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern:
 On Mon, 14 Apr 2014 stef...@seibold.net wrote:
 
  Zitat von Alan Stern st...@rowland.harvard.edu:
  
  
   6[  167.936921] usb 2-2.1: new full-speed USB device number 3  
   using ohci-pci
   6[  168.067890] usb 2-2.1: New USB device found, idVendor=076b,
   idProduct=a021
   6[  168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2,
   SerialNumber=0
   6[  168.082226] usb 2-2.1: Product: Smart Card Reader
   6[  168.086963] usb 2-2.1: Manufacturer: USB
   6[  168.172893] usb 2-2.2: new low-speed USB device number 4  
   using ohci-pci
   6[  168.300839] usb 2-2.2: New USB device found, idVendor=0aad,
   idProduct=0024
   6[  168.307823] usb 2-2.2: New USB device strings: Mfr=1, Product=2,
   SerialNumber=0
   6[  168.315180] usb 2-2.2: Product: FrontPanel USB Keyboard
   6[  168.320436] usb 2-2.2: Manufacturer: RohdeSchwarz
   6[  168.337895] input: RohdeSchwarz FrontPanel USB Keyboard as
   /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0
   6[  168.360988] input: RohdeSchwarz FrontPanel USB Keyboard as
   /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1
  
   Since some devices work and some don't, maybe part of the problem lies
   in the particular devices.
  
  
  The problem lies on the Bus 001 Device 002: ID 0424:2514 Standard  
  Microsystems Corp. USB 2.0 Hub, which hangs for arround 162 seconds  
  after a kexec.
  
  The Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card  
  Reader and Bus 002 Device 004: ID 0aad:0024 Rohde  Schwarz GmbH   
  Co. KG are attached to this Hub.
 
 Actually, it looks like they are plugged into the Texas Instruments
 hub, not the Standard Microsystems hub (because they are on bus 2, not
 bus 1).  Did you rearrange the USB cables?
 

You are right, sorry for the confusion. I can't rearrange the cables
because the HUB is on board.

  An other PowerPC device which is nearly eactly the same HW but without  
  this USB HUB works perfectly.
 
 Maybe you should replace that hub with a different brand.
 

Thats not possible, because the Hub is soldered on the board. And it is
also not a HW issue, since the Hub works perfectly which all previous
kernels including 3.4.

   This is the output of lsusb:
  
   Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
   Bus 001 Device 004: ID 0928:0007 Oxford Semiconductor, Ltd
   Bus 002 Device 002: ID 0451:2036 Texas Instruments, Inc. TUSB2036 Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card Reader
   Bus 002 Device 004: ID 0aad:0024 Rohde  Schwarz GmbH  Co. KG
 
 Here, the only device that might be plugged into the Standard
 Microsystems hub is the Oxford Semiconductor thing (whatever it is).
 
   What about if you just do:
  
 rmmod ehci-pci
 modprobe ehci-pci
  
  
  The kernel is monolitic because the USB HW is needed in a early boot  
  stage. The problem also occurs with ehci-fsl used in by an other  
  PowerPC device, which is a part of the SoC and is not attached to the  
  PCI bus.
  
  One thing is that the echo 1  
   /sys/bus/pci/drivers/ehci-pci/\:00\:17.2/reset workaround will  
  no longer work for kernel 3.14.
 
 Instead, you could try
 
   echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/unbind
   echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/bind
 

I am now at home. I will do this tomorrow. Thanks so much for your
support.

- Stefani



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: EHCI hotplug kernel crash in kernel 3.14 and 3.13

[Stefani Seibold]

Hi Alan,

the patch fix the issue. I tested it on a notebook with a cardbus
controller and on desktop machine with a thunderbolt interface. Both are
working.

Thunderbolt will sometimes crash but i think this is a issue with
dynamic added pci bridges, which cause a lot of trouble and headache  to
me.

Thanks,

Greetings,
Stefani

Am Montag, den 14.04.2014, 11:11 -0400 schrieb Alan Stern:
 On Sun, 13 Apr 2014, Stefani Seibold wrote:
 
  A hot plug of an USB 2.0 EHCI controller cardbus card will result in a
  kernel crash. This is the kernel log of a vanilla 3.14 x86_64 kernel. I
  will attach my kernel config.
 
  [   70.419755] ehci-pci :04:00.2: EHCI Host Controller
  [   70.419874] ehci-pci :04:00.2: new USB bus registered, assigned bus 
  number 9
  [   70.419980] ehci-pci :04:00.2: irq 19, io mem 0xf1402000
  [   70.422796] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
  [   70.424894] ohci-pci: OHCI PCI platform driver
  [   70.425072] ehci-pci :04:00.2: USB 2.0 started, EHCI 0.95
  [   70.425132] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002
  [   70.425135] usb usb9: New USB device strings: Mfr=3, Product=2, 
  SerialNumber=1
  [   70.425138] usb usb9: Product: EHCI Host Controller
  [   70.425141] usb usb9: Manufacturer: Linux 3.14.0 ehci_hcd
  [   70.425144] usb usb9: SerialNumber: :04:00.2
  [   70.425332] hub 9-0:1.0: USB hub found
  [   70.425344] hub 9-0:1.0: 5 ports detected
  [   70.425556] BUG: unable to handle kernel NULL pointer dereference at 
  0040
  [   70.425560] IP: [814947cc] usb_set_configuration+0x1c/0x7d0
  [   70.425568] PGD 30d571067 PUD 30d570067 PMD 0 
  [   70.425572] Oops:  [#1] PREEMPT SMP 
  [   70.425576] Modules linked in: ohci_pci(+) ohci_hcd rfcomm btusb ppdev 
  intel_agp intel_gtt 8250 video parport_pc parport serial_core nvidia(PO) 
  drm agpgart
  [   70.425604] CPU: 3 PID: 83 Comm: pccardd Tainted: P   O 3.14.0 #1
  [   70.425607] Hardware name: Dell Inc. Precision M6400 
  /0G841G, BIOS A13 06/05/2013
  [   70.425609] task: 88030eefe150 ti: 88030ef86000 task.ti: 
  88030ef86000
  [   70.425611] RIP: 0010:[814947cc]  [814947cc] 
  usb_set_configuration+0x1c/0x7d0
  [   70.425615] RSP: 0018:88030ef87ba0  EFLAGS: 00010286
  [   70.425617] RAX: 88030c7ce800 RBX:  RCX: 
  88030ea57000
  [   70.425619] RDX: 88030dcb6800 RSI: 0001 RDI: 
  
  [   70.425620] RBP: 88030ef87c38 R08: 88030dfa6910 R09: 
  
  [   70.425622] R10: 4e2e R11:  R12: 
  
  [   70.425624] R13:  R14: 814a0b80 R15: 
  88030c7ce800
  [   70.425626] FS:  () GS:88031fd8() 
  knlGS:
  [   70.425628] CS:  0010 DS:  ES:  CR0: 8005003b
  [   70.425630] CR2: 0040 CR3: 00030c714000 CR4: 
  000407e0
  [   70.425631] Stack:
  [   70.425632]  81340110 814a0b80 88030ef87bc8 
  817b3858
  [   70.425636]  88030dcb6898 88030ef87c00 813d6daf 
  88030f429000
  [   70.425640]  00010ef87bf0 813d4737 88030ef87c00 
  8133f19a
  [   70.425644] Call Trace:
  [   70.425650]  [81340110] ? pci_do_find_bus+0x70/0x70
  [   70.425653]  [814a0b80] ? hcd_pci_suspend_noirq+0xa0/0xa0
  [   70.425659]  [817b3858] ? klist_iter_exit+0x18/0x30
  [   70.425663]  [813d6daf] ? bus_find_device+0x7f/0xb0
  [   70.425666]  [813d4737] ? put_device+0x17/0x20
  [   70.425669]  [8133f19a] ? pci_dev_put+0x1a/0x20
  [   70.425672]  [81340361] ? pci_get_dev_by_id+0x61/0x90
  [   70.425675]  [814a0b80] ? hcd_pci_suspend_noirq+0xa0/0xa0
  [   70.425679]  [814a0bcb] ehci_post_add+0x4b/0x60
  [   70.425682]  [814a0070] for_each_companion+0x80/0xa0
  [   70.425685]  [814a0504] usb_hcd_pci_probe+0x474/0x4e0
 
 I think I see the problem; the driver data for the companion controller 
 gets set before we expect it.  The patch below should help, by adding a 
 check to see that the companion's root hub has been allocated.
 
 Alan Stern
 
 
 
 Index: usb-3.14/drivers/usb/core/hcd-pci.c
 ===
 --- usb-3.14.orig/drivers/usb/core/hcd-pci.c
 +++ usb-3.14/drivers/usb/core/hcd-pci.c
 @@ -75,7 +75,7 @@ static void for_each_companion(struct pc
   PCI_SLOT(companion-devfn) != slot)
   continue;
   companion_hcd = pci_get_drvdata(companion);
 - if (!companion_hcd)
 + if (!companion_hcd || !companion_hcd-self.root_hub)
   continue;
   fn(pdev, hcd, companion, companion_hcd);
   }
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body

Re: X86: kexec issues with i915 in 3.14

[Stefani Seibold]

Am Montag, den 14.04.2014, 00:28 + schrieb Woodhouse, David:
 On Sun, 2014-04-13 at 22:01 +0200, Stefani Seibold wrote:
  Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel
  log messages:
  
  [0.262754] IOMMU: Setting identity map for device :00:1a.0 
  [0x7c45f000 - 0x7c46bfff]
  [0.262780] IOMMU: Setting identity map for device :00:14.0 
  [0x7c45f000 - 0x7c46bfff]
  [0.262798] IOMMU: Prepare 0-16MiB unity mapping for LPC
  [0.262807] IOMMU: Setting identity map for device :00:1f.0 [0x0 - 
  0xff]
  [0.262948] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
  [0.262948] dmar: DRHD: handling fault status reg 3
  [0.262951] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
  e000 
  DMAR:[fault reason 05] PTE Write access is not set
 
 I'm inferring from the subject line that you mean kexec, not
 rebooting?
 

Rebooting via BIOS works, but booting via kexec will result the message
storm or hang kernel with a corrupted display.

 It looks like a peripheral device is being left active and doing DMA by
 the previous kernel, rather than being shut down. So as soon as the new
 kernel resets the IOMMU mappings, that peripheral device is causing
 faults.
 
 We really ought to rate-limit the faults and isolate the offending
 device before there are 21,000 of them. As discussed elsewhere recently,
 we could do with a way to tell the PCI layer that it offended us but I
 suppose we could at *least* stop the IOMMU from reporting faults for it.
 
 Is this new behaviour? I'm not sure why this should have changed...
 

I can reproduce the behaviour also with a 3.13.7 kernel.

One thing i found after the end of the 21.000 messages was a GPU crash:

[5.002484] r8169 :03:00.0 eth0: link up
[5.002489] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[6.745051] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... 
blitter ring idle
[   11.743768] [drm] stuck on render ring
[   11.743773] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[   11.743774] [drm] GPU hangs can indicate a bug anywhere in the entire gfx 
stack, including userspace.
[   11.743775] [drm] Please file a _new_ bug report on bugs.freedesktop.org 
against DRI - DRM/Intel
[   11.743777] [drm] drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.
[   11.743778] [drm] The gpu crash dump is required to analyze gpu hangs, so 
please always attach it.
[   14.240743] systemd-journald[158]: File 
/var/log/journal/bb613621feef82d686edde0046e9bcea/user-1000.journal corrupted 
or uncleanly shut down, renaming and replacing.

- Stefani


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

X86: kexec issues with i915 in 3.14

[Stefani Seibold]

Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel
log messages:

[0.262754] IOMMU: Setting identity map for device :00:1a.0 [0x7c45f000 
- 0x7c46bfff]
[0.262780] IOMMU: Setting identity map for device :00:14.0 [0x7c45f000 
- 0x7c46bfff]
[0.262798] IOMMU: Prepare 0-16MiB unity mapping for LPC
[0.262807] IOMMU: Setting identity map for device :00:1f.0 [0x0 - 
0xff]
[0.262948] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
[0.262948] dmar: DRHD: handling fault status reg 3
[0.262951] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
e000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262955] dmar: DRHD: handling fault status reg 3
[0.262959] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
fff3c000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262965] dmar: DRHD: handling fault status reg 3
[0.262968] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
ffe4a000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262974] dmar: DRHD: handling fault status reg 3
[0.262976] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
fff6f000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262983] dmar: DRHD: handling fault status reg 3
[0.262985] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
ffe8c000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262991] dmar: DRHD: handling fault status reg 3
[0.262994] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
fffb3000 
DMAR:[fault reason 05] PTE Write access is not set
[0.263000] dmar: DRHD: handling fault status reg 3
[0.263002] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
ffecf000 
DMAR:[fault reason 05] PTE Write access is not set
[0.263009] dmar: DRHD: handling fault status reg 3
[0.263011] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
d000

this message repeats more the 21000 times. After this the kernel
messages continues with

[0.683267] fbcon: inteldrmfb (fb0) is primary device
[0.864123] Console: switching to colour frame buffer device 320x90
[0.880630] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[0.880632] i915 :00:02.0: registered panic notifier
[0.881077] ACPI Exception: AE_NOT_FOUND, Evaluating _DOD 
(20131218/video-1245)
[0.881081] ACPI: Video Device [PEGN] (multi-head: no  rom: yes  post: no)
[0.881134] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:10/LNXVIDEO:00/input/input2
[0.888055] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[0.888266] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input3
[0.888289] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[0.888571] mei_me :00:16.0: irq 57 for MSI/MSI-X
[0.889545] rtsx_pci :3e:00.0: irq 58 for MSI/MSI-X
[0.889559] rtsx_pci :3e:00.0: rtsx_pci_acquire_irq: pcr->msi_en = 1, 
pci->irq = 58
[0.890098] ACPI Warning: SystemIO range 
0x1828-0x182f conflicts with OpRegion 
0x1800-0x187f (\PMIO) (20131218/utaddress-258)
[0.890104] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[0.890107] ACPI Warning: SystemIO range 
0x1c30-0x1c3f conflicts with OpRegion 
0x1c00-0x1c3f (\GPRL) (20131218/utaddress-258)
[0.890111] ACPI Warning: SystemIO range 
0x1c30-0x1c3f conflicts with OpRegion 
0x1c00-0x1fff (\GPR_) (20131218/utaddress-258)
[0.890114] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[0.890115] ACPI Warning: SystemIO range 
0x1c00-0x1c2f conflicts with OpRegion 
0x1c00-0x1c3f (\GPRL) (20131218/utaddress-258)
[0.890118] ACPI Warning: SystemIO range 
0x1c00-0x1c2f conflicts with OpRegion 
0x1c00-0x1fff (\GPR_) (20131218/utaddress-258)
[0.890122] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[0.890123] lpc_ich: Resource conflict(s) found affecting gpio_ich
[0.890215] ahci :00:1f.2: version 3.0

lspci give me for the device 00:02.0:

VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen
Core Processor Integrated Graphics Controller (rev 06)

After this the system seams in normal condition, X is starting and i can
log on and use the machine. Any idea? 

But mostly the machine will look up and i see only garbage on the
screen.

I will attach my kernel config.



kernel.config.gz
Description: application/gzip

Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

When executing a kexec kernel on a PowerPC board the new started kernel
will not find already enumerated USB devices due a missing reset on the
USB bus.

As a work around a

echo 1 >/sys/bus/pci/drivers/[ex]hci-pci/BUS-ADDRESS-OF-THE-HCD/reset

will solve this. But this is far from beauty.

My latest kernel without this issue was for EHCI kernel 2.6.39 and for
XHCI kernel 3.4, but i have no idea when exactly this behavior was
introduced.

For X86 all is fine.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)

[Stefani Seibold]

Since some kernel version it is impossible to select the Enhanced Real
Time Clock Support (legacy PC RTC driver) because RTC_LIB is set by
default in arch/x86/Kconfig, but the rule for selecting CONFIG_RTC is
RTC_LIB=n. So the code of driver/char/rtc is still useless.

This breaks the API since there is no more misc device /dev/rtc
available without a udev rule or a link to /dev/rtc0. 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

EHCI hotplug kernel crash in kernel 3.14 and 3.13

[Stefani Seibold]

A hot plug of an USB 2.0 EHCI controller cardbus card will result in a
kernel crash. This is the kernel log of a vanilla 3.14 x86_64 kernel. I
will attach my kernel config.

[   70.418181] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into 
slot 0
[   70.418209] pci :04:00.0: [1033:0035] type 00 class 0x0c0310
[   70.418239] pci :04:00.0: reg 0x10: [mem 0x-0x0fff]
[   70.418359] pci :04:00.0: supports D1 D2
[   70.418362] pci :04:00.0: PME# supported from D0 D1 D2 D3hot
[   70.418500] pci :04:00.1: [1033:0035] type 00 class 0x0c0310
[   70.418529] pci :04:00.1: reg 0x10: [mem 0x-0x0fff]
[   70.418653] pci :04:00.1: supports D1 D2
[   70.418655] pci :04:00.1: PME# supported from D0 D1 D2 D3hot
[   70.418756] pci :04:00.2: [1033:00e0] type 00 class 0x0c0320
[   70.418784] pci :04:00.2: reg 0x10: [mem 0x-0x00ff]
[   70.418912] pci :04:00.2: supports D1 D2
[   70.418915] pci :04:00.2: PME# supported from D0 D1 D2 D3hot
[   70.419040] pci :04:00.0: BAR 0: assigned [mem 0xf140-0xf1400fff]
[   70.419051] pci :04:00.1: BAR 0: assigned [mem 0xf1401000-0xf1401fff]
[   70.419059] pci :04:00.2: BAR 0: assigned [mem 0xf1402000-0xf14020ff]
[   70.419112] pci :04:00.0: enabling device ( -> 0002)
[   70.419350] pci :04:00.1: enabling device ( -> 0002)
[   70.419508] pci :04:00.2: enabling device ( -> 0002)
[   70.419755] ehci-pci :04:00.2: EHCI Host Controller
[   70.419874] ehci-pci :04:00.2: new USB bus registered, assigned bus 
number 9
[   70.419980] ehci-pci :04:00.2: irq 19, io mem 0xf1402000
[   70.422796] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   70.424894] ohci-pci: OHCI PCI platform driver
[   70.425072] ehci-pci :04:00.2: USB 2.0 started, EHCI 0.95
[   70.425132] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002
[   70.425135] usb usb9: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   70.425138] usb usb9: Product: EHCI Host Controller
[   70.425141] usb usb9: Manufacturer: Linux 3.14.0 ehci_hcd
[   70.425144] usb usb9: SerialNumber: :04:00.2
[   70.425332] hub 9-0:1.0: USB hub found
[   70.425344] hub 9-0:1.0: 5 ports detected
[   70.425556] BUG: unable to handle kernel NULL pointer dereference at 
0040
[   70.425560] IP: [] usb_set_configuration+0x1c/0x7d0
[   70.425568] PGD 30d571067 PUD 30d570067 PMD 0 
[   70.425572] Oops:  [#1] PREEMPT SMP 
[   70.425576] Modules linked in: ohci_pci(+) ohci_hcd rfcomm btusb ppdev 
intel_agp intel_gtt 8250 video parport_pc parport serial_core nvidia(PO) drm 
agpgart
[   70.425604] CPU: 3 PID: 83 Comm: pccardd Tainted: P   O 3.14.0 #1
[   70.425607] Hardware name: Dell Inc. Precision M6400 
/0G841G, BIOS A13 06/05/2013
[   70.425609] task: 88030eefe150 ti: 88030ef86000 task.ti: 
88030ef86000
[   70.425611] RIP: 0010:[]  [] 
usb_set_configuration+0x1c/0x7d0
[   70.425615] RSP: 0018:88030ef87ba0  EFLAGS: 00010286
[   70.425617] RAX: 88030c7ce800 RBX:  RCX: 88030ea57000
[   70.425619] RDX: 88030dcb6800 RSI: 0001 RDI: 
[   70.425620] RBP: 88030ef87c38 R08: 88030dfa6910 R09: 
[   70.425622] R10: 4e2e R11:  R12: 
[   70.425624] R13:  R14: 814a0b80 R15: 88030c7ce800
[   70.425626] FS:  () GS:88031fd8() 
knlGS:
[   70.425628] CS:  0010 DS:  ES:  CR0: 8005003b
[   70.425630] CR2: 0040 CR3: 00030c714000 CR4: 000407e0
[   70.425631] Stack:
[   70.425632]  81340110 814a0b80 88030ef87bc8 
817b3858
[   70.425636]  88030dcb6898 88030ef87c00 813d6daf 
88030f429000
[   70.425640]  00010ef87bf0 813d4737 88030ef87c00 
8133f19a
[   70.425644] Call Trace:
[   70.425650]  [] ? pci_do_find_bus+0x70/0x70
[   70.425653]  [] ? hcd_pci_suspend_noirq+0xa0/0xa0
[   70.425659]  [] ? klist_iter_exit+0x18/0x30
[   70.425663]  [] ? bus_find_device+0x7f/0xb0
[   70.425666]  [] ? put_device+0x17/0x20
[   70.425669]  [] ? pci_dev_put+0x1a/0x20
[   70.425672]  [] ? pci_get_dev_by_id+0x61/0x90
[   70.425675]  [] ? hcd_pci_suspend_noirq+0xa0/0xa0
[   70.425679]  [] ehci_post_add+0x4b/0x60
[   70.425682]  [] for_each_companion+0x80/0xa0
[   70.425685]  [] usb_hcd_pci_probe+0x474/0x4e0
[   70.425688]  [] pci_device_probe+0x84/0xe0
[   70.425692]  [] driver_probe_device+0x76/0x240
[   70.425695]  [] ? driver_probe_device+0x240/0x240
[   70.425698]  [] __device_attach+0x3b/0x40
[   70.425701]  [] bus_for_each_drv+0x63/0xa0
[   70.425704]  [] device_attach+0x88/0xa0
[   70.425710]  [] pci_bus_add_device+0x3d/0x60
[   70.425714]  [] pci_bus_add_devices+0x39/0xa0
[   70.425717]  [] cb_alloc+0xd5/0xf0
[   70.425722]  [] socket_insert+0xf0/0x110
[   70.425725]  [] 

EHCI hotplug kernel crash in kernel 3.14 and 3.13

[Stefani Seibold]

A hot plug of an USB 2.0 EHCI controller cardbus card will result in a
kernel crash. This is the kernel log of a vanilla 3.14 x86_64 kernel. I
will attach my kernel config.

[   70.418181] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into 
slot 0
[   70.418209] pci :04:00.0: [1033:0035] type 00 class 0x0c0310
[   70.418239] pci :04:00.0: reg 0x10: [mem 0x-0x0fff]
[   70.418359] pci :04:00.0: supports D1 D2
[   70.418362] pci :04:00.0: PME# supported from D0 D1 D2 D3hot
[   70.418500] pci :04:00.1: [1033:0035] type 00 class 0x0c0310
[   70.418529] pci :04:00.1: reg 0x10: [mem 0x-0x0fff]
[   70.418653] pci :04:00.1: supports D1 D2
[   70.418655] pci :04:00.1: PME# supported from D0 D1 D2 D3hot
[   70.418756] pci :04:00.2: [1033:00e0] type 00 class 0x0c0320
[   70.418784] pci :04:00.2: reg 0x10: [mem 0x-0x00ff]
[   70.418912] pci :04:00.2: supports D1 D2
[   70.418915] pci :04:00.2: PME# supported from D0 D1 D2 D3hot
[   70.419040] pci :04:00.0: BAR 0: assigned [mem 0xf140-0xf1400fff]
[   70.419051] pci :04:00.1: BAR 0: assigned [mem 0xf1401000-0xf1401fff]
[   70.419059] pci :04:00.2: BAR 0: assigned [mem 0xf1402000-0xf14020ff]
[   70.419112] pci :04:00.0: enabling device ( - 0002)
[   70.419350] pci :04:00.1: enabling device ( - 0002)
[   70.419508] pci :04:00.2: enabling device ( - 0002)
[   70.419755] ehci-pci :04:00.2: EHCI Host Controller
[   70.419874] ehci-pci :04:00.2: new USB bus registered, assigned bus 
number 9
[   70.419980] ehci-pci :04:00.2: irq 19, io mem 0xf1402000
[   70.422796] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   70.424894] ohci-pci: OHCI PCI platform driver
[   70.425072] ehci-pci :04:00.2: USB 2.0 started, EHCI 0.95
[   70.425132] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002
[   70.425135] usb usb9: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   70.425138] usb usb9: Product: EHCI Host Controller
[   70.425141] usb usb9: Manufacturer: Linux 3.14.0 ehci_hcd
[   70.425144] usb usb9: SerialNumber: :04:00.2
[   70.425332] hub 9-0:1.0: USB hub found
[   70.425344] hub 9-0:1.0: 5 ports detected
[   70.425556] BUG: unable to handle kernel NULL pointer dereference at 
0040
[   70.425560] IP: [814947cc] usb_set_configuration+0x1c/0x7d0
[   70.425568] PGD 30d571067 PUD 30d570067 PMD 0 
[   70.425572] Oops:  [#1] PREEMPT SMP 
[   70.425576] Modules linked in: ohci_pci(+) ohci_hcd rfcomm btusb ppdev 
intel_agp intel_gtt 8250 video parport_pc parport serial_core nvidia(PO) drm 
agpgart
[   70.425604] CPU: 3 PID: 83 Comm: pccardd Tainted: P   O 3.14.0 #1
[   70.425607] Hardware name: Dell Inc. Precision M6400 
/0G841G, BIOS A13 06/05/2013
[   70.425609] task: 88030eefe150 ti: 88030ef86000 task.ti: 
88030ef86000
[   70.425611] RIP: 0010:[814947cc]  [814947cc] 
usb_set_configuration+0x1c/0x7d0
[   70.425615] RSP: 0018:88030ef87ba0  EFLAGS: 00010286
[   70.425617] RAX: 88030c7ce800 RBX:  RCX: 88030ea57000
[   70.425619] RDX: 88030dcb6800 RSI: 0001 RDI: 
[   70.425620] RBP: 88030ef87c38 R08: 88030dfa6910 R09: 
[   70.425622] R10: 4e2e R11:  R12: 
[   70.425624] R13:  R14: 814a0b80 R15: 88030c7ce800
[   70.425626] FS:  () GS:88031fd8() 
knlGS:
[   70.425628] CS:  0010 DS:  ES:  CR0: 8005003b
[   70.425630] CR2: 0040 CR3: 00030c714000 CR4: 000407e0
[   70.425631] Stack:
[   70.425632]  81340110 814a0b80 88030ef87bc8 
817b3858
[   70.425636]  88030dcb6898 88030ef87c00 813d6daf 
88030f429000
[   70.425640]  00010ef87bf0 813d4737 88030ef87c00 
8133f19a
[   70.425644] Call Trace:
[   70.425650]  [81340110] ? pci_do_find_bus+0x70/0x70
[   70.425653]  [814a0b80] ? hcd_pci_suspend_noirq+0xa0/0xa0
[   70.425659]  [817b3858] ? klist_iter_exit+0x18/0x30
[   70.425663]  [813d6daf] ? bus_find_device+0x7f/0xb0
[   70.425666]  [813d4737] ? put_device+0x17/0x20
[   70.425669]  [8133f19a] ? pci_dev_put+0x1a/0x20
[   70.425672]  [81340361] ? pci_get_dev_by_id+0x61/0x90
[   70.425675]  [814a0b80] ? hcd_pci_suspend_noirq+0xa0/0xa0
[   70.425679]  [814a0bcb] ehci_post_add+0x4b/0x60
[   70.425682]  [814a0070] for_each_companion+0x80/0xa0
[   70.425685]  [814a0504] usb_hcd_pci_probe+0x474/0x4e0
[   70.425688]  [8133f614] pci_device_probe+0x84/0xe0
[   70.425692]  [813d89f6] driver_probe_device+0x76/0x240
[   70.425695]  [813d8bc0] ? driver_probe_device+0x240/0x240
[   70.425698]  [813d8bfb] __device_attach+0x3b/0x40
[ 

X86: Impossible select Enhanced Real Time Clock Support (legacy PC RTC driver)

[Stefani Seibold]

Since some kernel version it is impossible to select the Enhanced Real
Time Clock Support (legacy PC RTC driver) because RTC_LIB is set by
default in arch/x86/Kconfig, but the rule for selecting CONFIG_RTC is
RTC_LIB=n. So the code of driver/char/rtc is still useless.

This breaks the API since there is no more misc device /dev/rtc
available without a udev rule or a link to /dev/rtc0. 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Missing USB XHCI and EHCI reset for kexec

[Stefani Seibold]

When executing a kexec kernel on a PowerPC board the new started kernel
will not find already enumerated USB devices due a missing reset on the
USB bus.

As a work around a

echo 1 /sys/bus/pci/drivers/[ex]hci-pci/BUS-ADDRESS-OF-THE-HCD/reset

will solve this. But this is far from beauty.

My latest kernel without this issue was for EHCI kernel 2.6.39 and for
XHCI kernel 3.4, but i have no idea when exactly this behavior was
introduced.

For X86 all is fine.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

X86: kexec issues with i915 in 3.14

[Stefani Seibold]

Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel
log messages:

[0.262754] IOMMU: Setting identity map for device :00:1a.0 [0x7c45f000 
- 0x7c46bfff]
[0.262780] IOMMU: Setting identity map for device :00:14.0 [0x7c45f000 
- 0x7c46bfff]
[0.262798] IOMMU: Prepare 0-16MiB unity mapping for LPC
[0.262807] IOMMU: Setting identity map for device :00:1f.0 [0x0 - 
0xff]
[0.262948] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
[0.262948] dmar: DRHD: handling fault status reg 3
[0.262951] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
e000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262955] dmar: DRHD: handling fault status reg 3
[0.262959] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
fff3c000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262965] dmar: DRHD: handling fault status reg 3
[0.262968] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
ffe4a000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262974] dmar: DRHD: handling fault status reg 3
[0.262976] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
fff6f000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262983] dmar: DRHD: handling fault status reg 3
[0.262985] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
ffe8c000 
DMAR:[fault reason 05] PTE Write access is not set
[0.262991] dmar: DRHD: handling fault status reg 3
[0.262994] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
fffb3000 
DMAR:[fault reason 05] PTE Write access is not set
[0.263000] dmar: DRHD: handling fault status reg 3
[0.263002] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
ffecf000 
DMAR:[fault reason 05] PTE Write access is not set
[0.263009] dmar: DRHD: handling fault status reg 3
[0.263011] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 
d000

this message repeats more the 21000 times. After this the kernel
messages continues with

[0.683267] fbcon: inteldrmfb (fb0) is primary device
[0.864123] Console: switching to colour frame buffer device 320x90
[0.880630] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[0.880632] i915 :00:02.0: registered panic notifier
[0.881077] ACPI Exception: AE_NOT_FOUND, Evaluating _DOD 
(20131218/video-1245)
[0.881081] ACPI: Video Device [PEGN] (multi-head: no  rom: yes  post: no)
[0.881134] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:10/LNXVIDEO:00/input/input2
[0.888055] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[0.888266] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input3
[0.888289] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[0.888571] mei_me :00:16.0: irq 57 for MSI/MSI-X
[0.889545] rtsx_pci :3e:00.0: irq 58 for MSI/MSI-X
[0.889559] rtsx_pci :3e:00.0: rtsx_pci_acquire_irq: pcr-msi_en = 1, 
pci-irq = 58
[0.890098] ACPI Warning: SystemIO range 
0x1828-0x182f conflicts with OpRegion 
0x1800-0x187f (\PMIO) (20131218/utaddress-258)
[0.890104] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[0.890107] ACPI Warning: SystemIO range 
0x1c30-0x1c3f conflicts with OpRegion 
0x1c00-0x1c3f (\GPRL) (20131218/utaddress-258)
[0.890111] ACPI Warning: SystemIO range 
0x1c30-0x1c3f conflicts with OpRegion 
0x1c00-0x1fff (\GPR_) (20131218/utaddress-258)
[0.890114] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[0.890115] ACPI Warning: SystemIO range 
0x1c00-0x1c2f conflicts with OpRegion 
0x1c00-0x1c3f (\GPRL) (20131218/utaddress-258)
[0.890118] ACPI Warning: SystemIO range 
0x1c00-0x1c2f conflicts with OpRegion 
0x1c00-0x1fff (\GPR_) (20131218/utaddress-258)
[0.890122] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[0.890123] lpc_ich: Resource conflict(s) found affecting gpio_ich
[0.890215] ahci :00:1f.2: version 3.0

lspci give me for the device 00:02.0:

VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen
Core Processor Integrated Graphics Controller (rev 06)

After this the system seams in normal condition, X is starting and i can
log on and use the machine. Any idea? 

But mostly the machine will look up and i see only garbage on the
screen.

I will attach my kernel config.



kernel.config.gz
Description: application/gzip

Re: [PATCH] x86: Fix the symbol versions on the 32-bit vDSO

[Stefani Seibold]

I think it is in review. I still wait for the confirmation of my assign
form.

Am Sonntag, den 30.03.2014, 09:59 -0700 schrieb H. Peter Anvin:
> Has your glibc patch been accepted upstream yet? I'm assuming not, in which 
> case this is a legitimate patch.
> 
> On March 29, 2014 11:33:37 PM PDT, Stefani Seibold  
> wrote:
> >Am Samstag, den 29.03.2014, 13:15 -0700 schrieb Andy Lutomirski:
> >> The new symbols provide the same API as the 64-bit variants, so they
> >> should have the same symbol version name.  This can't break
> >> userspace, since these symbols are new for 32-bit Linux.
> >> 
> >
> >This breaks my glibc patch... What is the benefit for doing this in
> >that
> >way?
> >
> >> Signed-off-by: Andy Lutomirski 
> >> ---
> >>  arch/x86/vdso/vdso32/vdso32.lds.S | 10 +++---
> >>  1 file changed, 7 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/arch/x86/vdso/vdso32/vdso32.lds.S
> >b/arch/x86/vdso/vdso32/vdso32.lds.S
> >> index 28c4607..aadb8b9 100644
> >> --- a/arch/x86/vdso/vdso32/vdso32.lds.S
> >> +++ b/arch/x86/vdso/vdso32/vdso32.lds.S
> >> @@ -23,14 +23,18 @@ ENTRY(__kernel_vsyscall);
> >>   */
> >>  VERSION
> >>  {
> >> +  LINUX_2.6 {
> >> +  global:
> >> +  __vdso_clock_gettime;
> >> +  __vdso_gettimeofday;
> >> +  __vdso_time;
> >> +  };
> >> +
> >>LINUX_2.5 {
> >>global:
> >>__kernel_vsyscall;
> >>__kernel_sigreturn;
> >>__kernel_rt_sigreturn;
> >> -  __vdso_clock_gettime;
> >> -  __vdso_gettimeofday;
> >> -  __vdso_time;
> >>local: *;
> >>};
> >>  }
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Fix the symbol versions on the 32-bit vDSO

[Stefani Seibold]

Am Samstag, den 29.03.2014, 13:15 -0700 schrieb Andy Lutomirski:
> The new symbols provide the same API as the 64-bit variants, so they
> should have the same symbol version name.  This can't break
> userspace, since these symbols are new for 32-bit Linux.
> 

This breaks my glibc patch... What is the benefit for doing this in that
way?

> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/vdso/vdso32/vdso32.lds.S | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/vdso/vdso32/vdso32.lds.S 
> b/arch/x86/vdso/vdso32/vdso32.lds.S
> index 28c4607..aadb8b9 100644
> --- a/arch/x86/vdso/vdso32/vdso32.lds.S
> +++ b/arch/x86/vdso/vdso32/vdso32.lds.S
> @@ -23,14 +23,18 @@ ENTRY(__kernel_vsyscall);
>   */
>  VERSION
>  {
> + LINUX_2.6 {
> + global:
> + __vdso_clock_gettime;
> + __vdso_gettimeofday;
> + __vdso_time;
> + };
> +
>   LINUX_2.5 {
>   global:
>   __kernel_vsyscall;
>   __kernel_sigreturn;
>   __kernel_rt_sigreturn;
> - __vdso_clock_gettime;
> - __vdso_gettimeofday;
> - __vdso_time;
>   local: *;
>   };
>  }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Fix the symbol versions on the 32-bit vDSO

[Stefani Seibold]

Am Samstag, den 29.03.2014, 13:15 -0700 schrieb Andy Lutomirski:
 The new symbols provide the same API as the 64-bit variants, so they
 should have the same symbol version name.  This can't break
 userspace, since these symbols are new for 32-bit Linux.
 

This breaks my glibc patch... What is the benefit for doing this in that
way?

 Signed-off-by: Andy Lutomirski l...@amacapital.net
 ---
  arch/x86/vdso/vdso32/vdso32.lds.S | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/arch/x86/vdso/vdso32/vdso32.lds.S 
 b/arch/x86/vdso/vdso32/vdso32.lds.S
 index 28c4607..aadb8b9 100644
 --- a/arch/x86/vdso/vdso32/vdso32.lds.S
 +++ b/arch/x86/vdso/vdso32/vdso32.lds.S
 @@ -23,14 +23,18 @@ ENTRY(__kernel_vsyscall);
   */
  VERSION
  {
 + LINUX_2.6 {
 + global:
 + __vdso_clock_gettime;
 + __vdso_gettimeofday;
 + __vdso_time;
 + };
 +
   LINUX_2.5 {
   global:
   __kernel_vsyscall;
   __kernel_sigreturn;
   __kernel_rt_sigreturn;
 - __vdso_clock_gettime;
 - __vdso_gettimeofday;
 - __vdso_time;
   local: *;
   };
  }


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Fix the symbol versions on the 32-bit vDSO

[Stefani Seibold]

I think it is in review. I still wait for the confirmation of my assign
form.

Am Sonntag, den 30.03.2014, 09:59 -0700 schrieb H. Peter Anvin:
 Has your glibc patch been accepted upstream yet? I'm assuming not, in which 
 case this is a legitimate patch.
 
 On March 29, 2014 11:33:37 PM PDT, Stefani Seibold stef...@seibold.net 
 wrote:
 Am Samstag, den 29.03.2014, 13:15 -0700 schrieb Andy Lutomirski:
  The new symbols provide the same API as the 64-bit variants, so they
  should have the same symbol version name.  This can't break
  userspace, since these symbols are new for 32-bit Linux.
  
 
 This breaks my glibc patch... What is the benefit for doing this in
 that
 way?
 
  Signed-off-by: Andy Lutomirski l...@amacapital.net
  ---
   arch/x86/vdso/vdso32/vdso32.lds.S | 10 +++---
   1 file changed, 7 insertions(+), 3 deletions(-)
  
  diff --git a/arch/x86/vdso/vdso32/vdso32.lds.S
 b/arch/x86/vdso/vdso32/vdso32.lds.S
  index 28c4607..aadb8b9 100644
  --- a/arch/x86/vdso/vdso32/vdso32.lds.S
  +++ b/arch/x86/vdso/vdso32/vdso32.lds.S
  @@ -23,14 +23,18 @@ ENTRY(__kernel_vsyscall);
*/
   VERSION
   {
  +  LINUX_2.6 {
  +  global:
  +  __vdso_clock_gettime;
  +  __vdso_gettimeofday;
  +  __vdso_time;
  +  };
  +
 LINUX_2.5 {
 global:
 __kernel_vsyscall;
 __kernel_sigreturn;
 __kernel_rt_sigreturn;
  -  __vdso_clock_gettime;
  -  __vdso_gettimeofday;
  -  __vdso_time;
 local: *;
 };
   }
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Fix size of get_unmapped_area()

[tip-bot for Stefani Seibold]

Commit-ID:  645a387ecbdb4aa78c8451a66416340616134537
Gitweb: http://git.kernel.org/tip/645a387ecbdb4aa78c8451a66416340616134537
Author: Stefani Seibold 
AuthorDate: Sun, 23 Mar 2014 17:38:14 +0100
Committer:  H. Peter Anvin 
CommitDate: Mon, 24 Mar 2014 09:31:23 -0700

x86, vdso: Fix size of get_unmapped_area()

The size of the reserved memory for a 32 bit vdso must be the size of the
32 bit vDSO in pages + HPET page + VVAR page.

One page is not enough for this. G silly copy and paste bug,
was right in previous patch.

Signed-off-by: Stefani Seibold 
Cc: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/1395592694-20571-1-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/vdso/vdso32-setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 791c1cb..0034898 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -165,12 +165,14 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
 
down_write(>mmap_sem);
 
-   addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
+   addr = get_unmapped_area(NULL, 0, vdso32_size + 
VDSO_OFFSET(VDSO_PREV_PAGES), 0, 0);
if (IS_ERR_VALUE(addr)) {
ret = addr;
goto up_fail;
}
 
+   addr += VDSO_OFFSET(VDSO_PREV_PAGES);
+
current->mm->context.vdso = (void *)addr;
 
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Fix size of get_unmapped_area()

[tip-bot for Stefani Seibold]

Commit-ID:  645a387ecbdb4aa78c8451a66416340616134537
Gitweb: http://git.kernel.org/tip/645a387ecbdb4aa78c8451a66416340616134537
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Sun, 23 Mar 2014 17:38:14 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Mon, 24 Mar 2014 09:31:23 -0700

x86, vdso: Fix size of get_unmapped_area()

The size of the reserved memory for a 32 bit vdso must be the size of the
32 bit vDSO in pages + HPET page + VVAR page.

One page is not enough for this. G silly copy and paste bug,
was right in previous patch.

Signed-off-by: Stefani Seibold stef...@seibold.net
Cc: Andy Lutomirski l...@amacapital.net
Link: 
http://lkml.kernel.org/r/1395592694-20571-1-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/vdso/vdso32-setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 791c1cb..0034898 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -165,12 +165,14 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
 
down_write(mm-mmap_sem);
 
-   addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
+   addr = get_unmapped_area(NULL, 0, vdso32_size + 
VDSO_OFFSET(VDSO_PREV_PAGES), 0, 0);
if (IS_ERR_VALUE(addr)) {
ret = addr;
goto up_fail;
}
 
+   addr += VDSO_OFFSET(VDSO_PREV_PAGES);
+
current-mm-context.vdso = (void *)addr;
 
/*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86, vdso: fix size of get_unmapped_area()

[Stefani Seibold]

The size of the reserved memory for a 32 bit vdso must be the size of the
32 bit vDSO in pages + HPET page + VVAR page.

One page is not enough for this. G silly copy and paste bug,
was right in previous patch.

The patch is against 3c1b63b9e4862fb16352a0646439c2dd6d9e0e5c

Signed-off-by: Stefani Seibold 
---
 arch/x86/vdso/vdso32-setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 791c1cb..0034898 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -165,12 +165,14 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
 
down_write(>mmap_sem);
 
-   addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
+   addr = get_unmapped_area(NULL, 0, vdso32_size + 
VDSO_OFFSET(VDSO_PREV_PAGES), 0, 0);
if (IS_ERR_VALUE(addr)) {
ret = addr;
goto up_fail;
}
 
+   addr += VDSO_OFFSET(VDSO_PREV_PAGES);
+
current->mm->context.vdso = (void *)addr;
 
/*
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [x86,vdso32] kernel BUG at mm/swap.c:134!

[Stefani Seibold]

Sorry,

i forgot do adjust the size of get_unmapped_area(). I will send a
incremental patch for this issue.

Thanks
Stefani

Am Samstag, den 22.03.2014, 19:47 +0800 schrieb Fengguang Wu:
> Greetings,
> 
> I got the below dmesg and the first bad commit is
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso
> 
> commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74
> Author: Stefani Seibold 
> AuthorDate: Mon Mar 17 23:22:13 2014 +0100
> Commit: H. Peter Anvin 
> CommitDate: Tue Mar 18 12:52:54 2014 -0700
> 
> x86, vdso32: handle 32 bit vDSO larger one page
> 
> This patch enables 32 bit vDSO which are larger than a page.
> 
> Signed-off-by: Stefani Seibold 
> Link: 
> http://lkml.kernel.org/r/1395094933-14252-14-git-send-email-stef...@seibold.net
> Signed-off-by: H. Peter Anvin 
> 
> +++---+
> || 4e40112c4f | next-20140320 |
> +++---+
> | boot_successes | 0  | 0 |
> | boot_failures  | 21 | 19|
> | kernel_BUG_at_mm/swap.c| 21 | 19|
> | invalid_opcode:PREEMPT_DEBUG_PAGEALLOC | 21 | 19|
> | EIP_is_at_put_compound_page| 21 | 19|
> | backtrace:do_execve| 8  | 11|
> | backtrace:SyS_execve   | 8  | 11|
> | backtrace:do_group_exit| 13 | 8 |
> | backtrace:SyS_exit_group   | 13 | 8 |
> +++---+
> 
> [9.196432] page:8670b3e8 count:0 mapcount:1 mapping:  (null) index:0x0
> [9.199071] page flags: 0x40008004(referenced|tail)
> [9.216380] [ cut here ]
> [9.218008] kernel BUG at mm/swap.c:134!
> [9.220257] invalid opcode:  [#1] PREEMPT DEBUG_PAGEALLOC
> [9.222817] Modules linked in:
> [9.224080] CPU: 0 PID: 69 Comm: init Not tainted 
> 3.14.0-rc7-next-20140320-10753-ga654dc7 #1
> [9.225460] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [9.225460] task: 7ef39880 ti: 78a02000 task.ti: 78a02000
> [9.225460] EIP: 0060:[<7907ae36>] EFLAGS: 00010246 CPU: 0
> [9.225460] EIP is at put_compound_page+0x7d/0x1da
> [9.225460] EAX: 795143df EBX: 8670b3c0 ECX: 7904b884 EDX: 0001
> [9.225460] ESI: 8670b3e8 EDI:  EBP: 78a03d40 ESP: 78a03d34
> [9.225460]  DS: 007b ES: 007b FS:  GS:  SS: 0068
> [9.225460] CR0: 8005003b CR2: 77bd1f38 CR3: 00a05000 CR4: 06d0
> [9.225460] Stack:
> [9.225460]  8670b3e8   78a03d78 7907b036 0001 
> 78a03d64 
> [9.225460]  00e1 78a0700c 0246 0092 865509a4 8654e26c 
> 78a07000 78a03db0
> [9.225460]  78a03dc4 78a03d8c 79086cb7 78a03db0 78960280  
> 78a03d9c 79086cd8
> [9.225460] Call Trace:
> [9.225460]  [<7907b036>] release_pages+0x58/0x175
> [9.225460]  [<79086cb7>] tlb_flush_mmu+0x30/0x45
> [9.225460]  [<79086cd8>] tlb_finish_mmu+0xc/0x2b
> [9.225460]  [<7908cab1>] exit_mmap+0x84/0xcb
> [9.225460]  [<79025a31>] mmput+0x2c/0xb1
> [9.225460]  [<790a2c79>] flush_old_exec+0x4af/0x564
> [9.225460]  [<790c3030>] load_elf_binary+0x272/0xb86
> [9.225460]  [<790a2220>] search_binary_handler+0x5f/0x145
> [9.225460]  [<790c2c06>] load_script+0x17a/0x183
> [9.225460]  [<79041c35>] ? sched_clock_cpu+0xaa/0xd3
> [9.225460]  [<790482bd>] ? lock_release+0x13c/0x19a
> [9.225460]  [<79311444>] ? _raw_read_unlock+0x27/0x38
> [9.225460]  [<790a2220>] search_binary_handler+0x5f/0x145
> [9.225460]  [<790a32eb>] do_execve+0x371/0x47c
> [9.225460]  [<790a354a>] SyS_execve+0x1c/0x20
> [9.225460]  [<793154d5>] sysenter_do_call+0x12/0x37
> [9.225460] Code: 0f 84 a3 00 00 00 89 d8 e8 73 fc ff ff 85 c0 75 0b 31 d2 
> 89 d8 e8 f5 c5 ff ff 0f 0b 8b 46 0c 40 74 0b 31 d2 89 f0 e8 e4 c5 ff ff <0f> 
> 0b 89 d8 e8 e5 fc ff ff 85 c0 0f 84 47 01 00 00 8b 03 a8 80
> [9.225460] EIP: [<7907ae36>] put_compound_page+0x7d/0x1da SS:ESP 
> 0068:78a03d34
> [9.379006] ---[ end trace cdeaef9772248ae3 ]---
> 
> git bisect start 016319d375c00db40dac165fcdaec78b67094243 v3.11 --
> git bisect good 843f4f4bb1a2c4c196a1af1d18bb6477a580ac78  # 16:35 21+ 
>  0  Merge tag 'trace-fixes-3.13-rc2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git

Re: [x86,vdso32] kernel BUG at mm/swap.c:134!

[Stefani Seibold]

Sorry,

i forgot do adjust the size of get_unmapped_area(). I will send a
incremental patch for this issue.

Thanks
Stefani

Am Samstag, den 22.03.2014, 19:47 +0800 schrieb Fengguang Wu:
 Greetings,
 
 I got the below dmesg and the first bad commit is
 
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso
 
 commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74
 Author: Stefani Seibold stef...@seibold.net
 AuthorDate: Mon Mar 17 23:22:13 2014 +0100
 Commit: H. Peter Anvin h...@linux.intel.com
 CommitDate: Tue Mar 18 12:52:54 2014 -0700
 
 x86, vdso32: handle 32 bit vDSO larger one page
 
 This patch enables 32 bit vDSO which are larger than a page.
 
 Signed-off-by: Stefani Seibold stef...@seibold.net
 Link: 
 http://lkml.kernel.org/r/1395094933-14252-14-git-send-email-stef...@seibold.net
 Signed-off-by: H. Peter Anvin h...@linux.intel.com
 
 +++---+
 || 4e40112c4f | next-20140320 |
 +++---+
 | boot_successes | 0  | 0 |
 | boot_failures  | 21 | 19|
 | kernel_BUG_at_mm/swap.c| 21 | 19|
 | invalid_opcode:PREEMPT_DEBUG_PAGEALLOC | 21 | 19|
 | EIP_is_at_put_compound_page| 21 | 19|
 | backtrace:do_execve| 8  | 11|
 | backtrace:SyS_execve   | 8  | 11|
 | backtrace:do_group_exit| 13 | 8 |
 | backtrace:SyS_exit_group   | 13 | 8 |
 +++---+
 
 [9.196432] page:8670b3e8 count:0 mapcount:1 mapping:  (null) index:0x0
 [9.199071] page flags: 0x40008004(referenced|tail)
 [9.216380] [ cut here ]
 [9.218008] kernel BUG at mm/swap.c:134!
 [9.220257] invalid opcode:  [#1] PREEMPT DEBUG_PAGEALLOC
 [9.222817] Modules linked in:
 [9.224080] CPU: 0 PID: 69 Comm: init Not tainted 
 3.14.0-rc7-next-20140320-10753-ga654dc7 #1
 [9.225460] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 [9.225460] task: 7ef39880 ti: 78a02000 task.ti: 78a02000
 [9.225460] EIP: 0060:[7907ae36] EFLAGS: 00010246 CPU: 0
 [9.225460] EIP is at put_compound_page+0x7d/0x1da
 [9.225460] EAX: 795143df EBX: 8670b3c0 ECX: 7904b884 EDX: 0001
 [9.225460] ESI: 8670b3e8 EDI:  EBP: 78a03d40 ESP: 78a03d34
 [9.225460]  DS: 007b ES: 007b FS:  GS:  SS: 0068
 [9.225460] CR0: 8005003b CR2: 77bd1f38 CR3: 00a05000 CR4: 06d0
 [9.225460] Stack:
 [9.225460]  8670b3e8   78a03d78 7907b036 0001 
 78a03d64 
 [9.225460]  00e1 78a0700c 0246 0092 865509a4 8654e26c 
 78a07000 78a03db0
 [9.225460]  78a03dc4 78a03d8c 79086cb7 78a03db0 78960280  
 78a03d9c 79086cd8
 [9.225460] Call Trace:
 [9.225460]  [7907b036] release_pages+0x58/0x175
 [9.225460]  [79086cb7] tlb_flush_mmu+0x30/0x45
 [9.225460]  [79086cd8] tlb_finish_mmu+0xc/0x2b
 [9.225460]  [7908cab1] exit_mmap+0x84/0xcb
 [9.225460]  [79025a31] mmput+0x2c/0xb1
 [9.225460]  [790a2c79] flush_old_exec+0x4af/0x564
 [9.225460]  [790c3030] load_elf_binary+0x272/0xb86
 [9.225460]  [790a2220] search_binary_handler+0x5f/0x145
 [9.225460]  [790c2c06] load_script+0x17a/0x183
 [9.225460]  [79041c35] ? sched_clock_cpu+0xaa/0xd3
 [9.225460]  [790482bd] ? lock_release+0x13c/0x19a
 [9.225460]  [79311444] ? _raw_read_unlock+0x27/0x38
 [9.225460]  [790a2220] search_binary_handler+0x5f/0x145
 [9.225460]  [790a32eb] do_execve+0x371/0x47c
 [9.225460]  [790a354a] SyS_execve+0x1c/0x20
 [9.225460]  [793154d5] sysenter_do_call+0x12/0x37
 [9.225460] Code: 0f 84 a3 00 00 00 89 d8 e8 73 fc ff ff 85 c0 75 0b 31 d2 
 89 d8 e8 f5 c5 ff ff 0f 0b 8b 46 0c 40 74 0b 31 d2 89 f0 e8 e4 c5 ff ff 0f 
 0b 89 d8 e8 e5 fc ff ff 85 c0 0f 84 47 01 00 00 8b 03 a8 80
 [9.225460] EIP: [7907ae36] put_compound_page+0x7d/0x1da SS:ESP 
 0068:78a03d34
 [9.379006] ---[ end trace cdeaef9772248ae3 ]---
 
 git bisect start 016319d375c00db40dac165fcdaec78b67094243 v3.11 --
 git bisect good 843f4f4bb1a2c4c196a1af1d18bb6477a580ac78  # 16:35 21+ 
  0  Merge tag 'trace-fixes-3.13-rc2' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
 git bisect good 5a5e75f4714a592f31e57f248b8f5c866f278b8d  # 17:03 21+ 
  0  tile: remove compat_sys_lookup_dcookie declaration to fix compile error
 git bisect good 721f0c126075294e66df73051cc2e1d795ef2095  # 17:46 21+ 
  0  Merge tag 'trace-fixes-v3.14-rc5' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
 git bisect good

[PATCH] x86, vdso: fix size of get_unmapped_area()

[Stefani Seibold]

The size of the reserved memory for a 32 bit vdso must be the size of the
32 bit vDSO in pages + HPET page + VVAR page.

One page is not enough for this. G silly copy and paste bug,
was right in previous patch.

The patch is against 3c1b63b9e4862fb16352a0646439c2dd6d9e0e5c

Signed-off-by: Stefani Seibold stef...@seibold.net
---
 arch/x86/vdso/vdso32-setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 791c1cb..0034898 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -165,12 +165,14 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
 
down_write(mm-mmap_sem);
 
-   addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
+   addr = get_unmapped_area(NULL, 0, vdso32_size + 
VDSO_OFFSET(VDSO_PREV_PAGES), 0, 0);
if (IS_ERR_VALUE(addr)) {
ret = addr;
goto up_fail;
}
 
+   addr += VDSO_OFFSET(VDSO_PREV_PAGES);
+
current-mm-context.vdso = (void *)addr;
 
/*
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] x86, vdso32: fix out of memory handling setup vDSO

[Stefani Seibold]

This patch add a correct out of memory handling for setup a 32 bit vDSO.

The patch is against tip commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74

Signed-off-by: Stefani Seibold 
---
 arch/x86/vdso/vdso32-setup.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 0bc363a..b77fdb2 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -134,8 +134,14 @@ int __init sysenter_setup(void)
}
 
vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
-   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, 
GFP_ATOMIC); 
-   vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC);
+
+   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_KERNEL);
+   if (!vdso32_pages)
+   goto fail;
+
+   vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_KERNEL);
+   if (!vdso_pages)
+   goto fail;
 
for(i = 0; i != vdso32_size; ++i)
vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));
@@ -144,6 +150,12 @@ int __init sysenter_setup(void)
patch_vdso32(vdso_pages, vdso_len);
 
return 0;
+fail:
+   kfree(vdso32_pages);
+   kfree(vdso_pages);
+   vdso32_size = 0;
+
+   return -ENOMEM;
 }
 
 /* Setup a VMA at program startup for the vsyscall page */
@@ -162,6 +174,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
if (vdso_enabled != 1)  /* Other values all mean "disabled" */
return 0;
 
+   if (!vdso32_size)
+   return 0;
+
down_write(>mmap_sem);
 
addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO

[Stefani Seibold]

Am Donnerstag, den 20.03.2014, 10:53 +0100 schrieb Thomas Gleixner:
> On Thu, 20 Mar 2014, Stefani Seibold wrote:
> 
> > This patch add a correct out of memory handling for setup a 32 bit vDSO.
> > 
> > The patch is against tip commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74
> > 
> > Signed-off-by: Stefani Seibold 
> > ---
> >  arch/x86/vdso/vdso32-setup.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
> > index 0bc363a..e1171c2 100644
> > --- a/arch/x86/vdso/vdso32-setup.c
> > +++ b/arch/x86/vdso/vdso32-setup.c
> > @@ -134,8 +134,14 @@ int __init sysenter_setup(void)
> > }
> >  
> > vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
> > -   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, 
> > GFP_ATOMIC); 
> > +
> > +   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC);
> 
> Why is this GFP_ATOMIC and not GFP_ATOMIC ?
> 
> That code is called either from identify_boot_cpu(), where GFP_KERNEL
> is perfectly valid and from subsys_initcall(sysenter_setup) which is
> way late in the boot process where GFP_KERNEL is the RightThing.
> 
> Aside of that, why do we need to call it early for X86_32 and late for
> X86_64?
> 
> We need the vdso before we head off to user space, but not in the
> early boot process.
> 

All complains are design decisions not made by me. I will send a patch
for the GFP_ATOMIC thing. For the other one it would be the best to ask
Andy for the reason.

- Stefani



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86, vdso32: fix out of memory handling setup vDSO

[Stefani Seibold]

This patch add a correct out of memory handling for setup a 32 bit vDSO.

The patch is against tip commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74

Signed-off-by: Stefani Seibold 
---
 arch/x86/vdso/vdso32-setup.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 0bc363a..e1171c2 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -134,8 +134,14 @@ int __init sysenter_setup(void)
}
 
vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
-   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, 
GFP_ATOMIC); 
+
+   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC);
+   if (!vdso32_pages)
+   goto fail;
+
vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC);
+   if (!vdso_pages)
+   goto fail;
 
for(i = 0; i != vdso32_size; ++i)
vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));
@@ -144,6 +150,12 @@ int __init sysenter_setup(void)
patch_vdso32(vdso_pages, vdso_len);
 
return 0;
+fail:
+   kfree(vdso32_pages);
+   kfree(vdso_pages);
+   vdso32_size = 0;
+
+   return -ENOMEM;
 }
 
 /* Setup a VMA at program startup for the vsyscall page */
@@ -162,6 +174,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
if (vdso_enabled != 1)  /* Other values all mean "disabled" */
return 0;
 
+   if (!vdso32_size)
+   return 0;
+
down_write(>mmap_sem);
 
addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86, vdso32: fix out of memory handling setup vDSO

[Stefani Seibold]

This patch add a correct out of memory handling for setup a 32 bit vDSO.

The patch is against tip commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74

Signed-off-by: Stefani Seibold stef...@seibold.net
---
 arch/x86/vdso/vdso32-setup.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 0bc363a..e1171c2 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -134,8 +134,14 @@ int __init sysenter_setup(void)
}
 
vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
-   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, 
GFP_ATOMIC); 
+
+   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC);
+   if (!vdso32_pages)
+   goto fail;
+
vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC);
+   if (!vdso_pages)
+   goto fail;
 
for(i = 0; i != vdso32_size; ++i)
vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));
@@ -144,6 +150,12 @@ int __init sysenter_setup(void)
patch_vdso32(vdso_pages, vdso_len);
 
return 0;
+fail:
+   kfree(vdso32_pages);
+   kfree(vdso_pages);
+   vdso32_size = 0;
+
+   return -ENOMEM;
 }
 
 /* Setup a VMA at program startup for the vsyscall page */
@@ -162,6 +174,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
if (vdso_enabled != 1)  /* Other values all mean disabled */
return 0;
 
+   if (!vdso32_size)
+   return 0;
+
down_write(mm-mmap_sem);
 
addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO

[Stefani Seibold]

Am Donnerstag, den 20.03.2014, 10:53 +0100 schrieb Thomas Gleixner:
 On Thu, 20 Mar 2014, Stefani Seibold wrote:
 
  This patch add a correct out of memory handling for setup a 32 bit vDSO.
  
  The patch is against tip commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74
  
  Signed-off-by: Stefani Seibold stef...@seibold.net
  ---
   arch/x86/vdso/vdso32-setup.c | 17 -
   1 file changed, 16 insertions(+), 1 deletion(-)
  
  diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
  index 0bc363a..e1171c2 100644
  --- a/arch/x86/vdso/vdso32-setup.c
  +++ b/arch/x86/vdso/vdso32-setup.c
  @@ -134,8 +134,14 @@ int __init sysenter_setup(void)
  }
   
  vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
  -   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, 
  GFP_ATOMIC); 
  +
  +   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC);
 
 Why is this GFP_ATOMIC and not GFP_ATOMIC ?
 
 That code is called either from identify_boot_cpu(), where GFP_KERNEL
 is perfectly valid and from subsys_initcall(sysenter_setup) which is
 way late in the boot process where GFP_KERNEL is the RightThing.
 
 Aside of that, why do we need to call it early for X86_32 and late for
 X86_64?
 
 We need the vdso before we head off to user space, but not in the
 early boot process.
 

All complains are design decisions not made by me. I will send a patch
for the GFP_ATOMIC thing. For the other one it would be the best to ask
Andy for the reason.

- Stefani



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] x86, vdso32: fix out of memory handling setup vDSO

[Stefani Seibold]

This patch add a correct out of memory handling for setup a 32 bit vDSO.

The patch is against tip commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74

Signed-off-by: Stefani Seibold stef...@seibold.net
---
 arch/x86/vdso/vdso32-setup.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 0bc363a..b77fdb2 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -134,8 +134,14 @@ int __init sysenter_setup(void)
}
 
vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
-   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, 
GFP_ATOMIC); 
-   vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC);
+
+   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_KERNEL);
+   if (!vdso32_pages)
+   goto fail;
+
+   vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_KERNEL);
+   if (!vdso_pages)
+   goto fail;
 
for(i = 0; i != vdso32_size; ++i)
vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));
@@ -144,6 +150,12 @@ int __init sysenter_setup(void)
patch_vdso32(vdso_pages, vdso_len);
 
return 0;
+fail:
+   kfree(vdso32_pages);
+   kfree(vdso_pages);
+   vdso32_size = 0;
+
+   return -ENOMEM;
 }
 
 /* Setup a VMA at program startup for the vsyscall page */
@@ -162,6 +174,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
if (vdso_enabled != 1)  /* Other values all mean disabled */
return 0;
 
+   if (!vdso32_size)
+   return 0;
+
down_write(mm-mmap_sem);
 
addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: __vdso_clock_gettime() cleanup

[tip-bot for Stefani Seibold]

Commit-ID:  ce39c64028a075d14af32bfb8336bfe1370c0443
Gitweb: http://git.kernel.org/tip/ce39c64028a075d14af32bfb8336bfe1370c0443
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:04 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:52:01 -0700

x86, vdso: __vdso_clock_gettime() cleanup

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 Seibold 
Link: 
http://lkml.kernel.org/r/1395094933-14252-5-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/vdso/vclock_gettime.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index bbc8065..fd074dd 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -209,7 +209,7 @@ notrace static int do_monotonic(struct timespec *ts)
return mode;
 }
 
-notrace static int do_realtime_coarse(struct timespec *ts)
+notrace static void do_realtime_coarse(struct timespec *ts)
 {
unsigned long seq;
do {
@@ -217,10 +217,9 @@ notrace static int do_realtime_coarse(struct timespec *ts)
ts->tv_sec = gtod->wall_time_coarse.tv_sec;
ts->tv_nsec = gtod->wall_time_coarse.tv_nsec;
} while (unlikely(read_seqcount_retry(>seq, seq)));
-   return 0;
 }
 
-notrace static int do_monotonic_coarse(struct timespec *ts)
+notrace static void do_monotonic_coarse(struct timespec *ts)
 {
unsigned long seq;
do {
@@ -228,30 +227,32 @@ notrace static int do_monotonic_coarse(struct timespec 
*ts)
ts->tv_sec = gtod->monotonic_time_coarse.tv_sec;
ts->tv_nsec = gtod->monotonic_time_coarse.tv_nsec;
} while (unlikely(read_seqcount_retry(>seq, seq)));
-
-   return 0;
 }
 
 notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
 {
-   int ret = VCLOCK_NONE;
-
switch (clock) {
case CLOCK_REALTIME:
-   ret = do_realtime(ts);
+   if (do_realtime(ts) == VCLOCK_NONE)
+   goto fallback;
break;
case CLOCK_MONOTONIC:
-   ret = do_monotonic(ts);
+   if (do_monotonic(ts) == VCLOCK_NONE)
+   goto fallback;
break;
case CLOCK_REALTIME_COARSE:
-   return do_realtime_coarse(ts);
+   do_realtime_coarse(ts);
+   break;
case CLOCK_MONOTONIC_COARSE:
-   return do_monotonic_coarse(ts);
+   do_monotonic_coarse(ts);
+   break;
+   default:
+   goto fallback;
}
 
-   if (ret == VCLOCK_NONE)
-   return vdso_fallback_gettime(clock, ts);
return 0;
+fallback:
+   return vdso_fallback_gettime(clock, ts);
 }
 int clock_gettime(clockid_t, struct timespec *)
__attribute__((weak, alias("__vdso_clock_gettime")));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Introduce VVAR marco for vdso32

[tip-bot for Stefani Seibold]

Commit-ID:  ef721987aef0cc0abba08c88810f2155f76b0b1f
Gitweb: http://git.kernel.org/tip/ef721987aef0cc0abba08c88810f2155f76b0b1f
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:07 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:52:29 -0700

x86, vdso: Introduce VVAR marco for vdso32

This patch revamps the vvar.h for introduce the VVAR macro for vdso32.

Reviewed-by: Andy Lutomirski 
Signed-off-by: Stefani Seibold 
Link: 
http://lkml.kernel.org/r/1395094933-14252-8-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 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..52c79ff 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -26,6 +26,15 @@
 
 #else
 
+#ifdef BUILD_VDSO32
+
+#define DECLARE_VVAR(offset, type, name)   \
+   extern type vvar_ ## name __attribute__((visibility("hidden")));
+
+#define VVAR(name) (vvar_ ## name)
+
+#else
+
 extern char __vvar_page;
 
 /* Base address of vvars.  This is not ABI. */
@@ -39,12 +48,13 @@ extern char __vvar_page;
static type const * const vvaraddr_ ## name =   \
(void *)(VVAR_ADDRESS + (offset));
 
+#define VVAR(name) (*vvaraddr_ ## name)
+#endif
+
 #define DEFINE_VVAR(type, name)
\
type name   \
__attribute__((section(".vvar_" #name), aligned(16))) __visible
 
-#define VVAR(name) (*vvaraddr_ ## name)
-
 #endif
 
 /* DECLARE_VVAR(offset, type, name) */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Add 32 bit VDSO time support for 64 bit kernel

[tip-bot for Stefani Seibold]

Commit-ID:  7c03156f34d113f885f045d8fb8cc3efd9e64751
Gitweb: http://git.kernel.org/tip/7c03156f34d113f885f045d8fb8cc3efd9e64751
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:10 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:52:41 -0700

x86, vdso: Add 32 bit VDSO time support for 64 bit kernel

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 for optimal performance.

The vsyscall_gtod_data struture must be a rearranged to serve 32- and
64-bit code access at the same time:

- The seqcount_t was replaced by an unsigned, this makes the
  vsyscall_gtod_data intedepend of kernel configuration and internal functions.
- All kernel internal structures are replaced by fix size elements
  which works for 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 
Link: 
http://lkml.kernel.org/r/1395094933-14252-11-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/vgtod.h  | 71 +--
 arch/x86/include/asm/vvar.h   |  5 ++
 arch/x86/kernel/vsyscall_gtod.c   | 34 -
 arch/x86/vdso/vclock_gettime.c| 91 +++
 arch/x86/vdso/vdso32/vclock_gettime.c | 21 
 5 files changed, 155 insertions(+), 67 deletions(-)

diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index 46e24d3..3c3366c 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -1,30 +1,73 @@
 #ifndef _ASM_X86_VGTOD_H
 #define _ASM_X86_VGTOD_H
 
-#include 
+#include 
 #include 
 
+#ifdef BUILD_VDSO32_64
+typedef u64 gtod_long_t;
+#else
+typedef unsigned long gtod_long_t;
+#endif
+/*
+ * vsyscall_gtod_data will be accessed by 32 and 64 bit code at the same time
+ * so be carefull by modifying this structure.
+ */
 struct vsyscall_gtod_data {
-   seqcount_t  seq;
+   unsigned seq;
 
-   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;
u64 wall_time_snsec;
+   gtod_long_t wall_time_sec;
+   gtod_long_t monotonic_time_sec;
u64 monotonic_time_snsec;
-   time_t  monotonic_time_sec;
+   gtod_long_t wall_time_coarse_sec;
+   gtod_long_t wall_time_coarse_nsec;
+   gtod_long_t monotonic_time_coarse_sec;
+   gtod_long_t monotonic_time_coarse_nsec;
 
-   struct timezone sys_tz;
-   struct timespec wall_time_coarse;
-   struct timespec monotonic_time_coarse;
+   int tz_minuteswest;
+   int tz_dsttime;
 };
 extern struct vsyscall_gtod_data vsyscall_gtod_data;
 
+static inline unsigned gtod_read_begin(const struct vsyscall_gtod_data *s)
+{
+   unsigned ret;
+
+repeat:
+   ret = ACCESS_ONCE(s->seq);
+   if (unlikely(ret & 1)) {
+   cpu_relax();
+   goto repeat;
+   }
+   smp_rmb();
+   return ret;
+}
+
+static inline int gtod_read_retry(const struct vsyscall_gtod_data *s,
+   unsigned start)
+{
+   smp_rmb();
+   return unlikely(s->seq != start);
+}
+
+static inline void gtod_write_begin(struct vsyscall_gtod_data *s)
+{
+   ++s->seq;
+   smp_wmb();
+}
+
+static inline void gtod_write_end(struct vsyscall_gtod_data *s)
+{
+   smp_wmb();
+   ++s->seq;
+}
+
 #endif /* _ASM_X86_VGTOD_H */
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index 52c79ff..081d909 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -16,6 +16,9 @@
  * you mess up, the linker will catch it.)
  */
 
+#ifndef _ASM_X86_VVAR_H
+#define _ASM_X86_VVAR_H
+
 #if defined(__VVAR_KERNEL_LDS)
 
 /* The kernel linker script defines its own magic to put vvars in the
@@ -64,3 +67,5 @@ DECLARE_VVAR(16, int, vgetcpu_mode)
 DECLARE_VVAR(128, struct vsyscall_gtod_data, vsyscall_gtod_data)
 
 #undef DECLARE_VVAR
+
+#endif
diff --git a/arch/x86/kernel/vsyscall_gtod.c b/arch/x86/kernel/vsyscall_gtod.c
index b5a943d..f9c6e56 100644
--- a/arch/x86/kernel/vsyscall_gtod.c
+++ b/arch/x86/kernel/vsyscall_gtod.c
@@ -4,6 +4,7 @@
  *
  *  Modified for x86 32 bit architecture by
  *  Stefani Seibold 
+ *  sponsored by Rohde & Schwarz GmbH & Co. KG Munich/Germany
  *
  *  Thanks to 

[tip:x86/vdso] x86, vdso: Make vsyscall_gtod_data handling x86 generic

[tip-bot for Stefani Seibold]

Commit-ID:  d2312e3379d581d2c3603357a0181046448e1de3
Gitweb: http://git.kernel.org/tip/d2312e3379d581d2c3603357a0181046448e1de3
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:01 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:51:52 -0700

x86, vdso: Make vsyscall_gtod_data handling x86 generic

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 
Link: 
http://lkml.kernel.org/r/1395094933-14252-2-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/Kconfig   |  4 +--
 arch/x86/include/asm/clocksource.h |  4 ---
 arch/x86/include/asm/vvar.h| 12 ++--
 arch/x86/kernel/Makefile   |  2 +-
 arch/x86/kernel/hpet.c |  2 --
 arch/x86/kernel/tsc.c  |  2 --
 arch/x86/kernel/vmlinux.lds.S  |  3 --
 arch/x86/kernel/vsyscall_64.c  | 45 -
 arch/x86/kernel/vsyscall_gtod.c| 59 ++
 arch/x86/tools/relocs.c|  2 +-
 10 files changed, 72 insertions(+), 63 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9122f6b..ab3ebc8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -107,9 +107,9 @@ config X86
select HAVE_ARCH_SOFT_DIRTY
select CLOCKSOURCE_WATCHDOG
select GENERIC_CLOCKEVENTS
-   select ARCH_CLOCKSOURCE_DATA if X86_64
+   select ARCH_CLOCKSOURCE_DATA
select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && 
X86_LOCAL_APIC)
-   select GENERIC_TIME_VSYSCALL if X86_64
+   select GENERIC_TIME_VSYSCALL
select KTIME_SCALAR if X86_32
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/x86/include/asm/clocksource.h 
b/arch/x86/include/asm/clocksource.h
index 16a57f4..eda81dc 100644
--- a/arch/x86/include/asm/clocksource.h
+++ b/arch/x86/include/asm/clocksource.h
@@ -3,8 +3,6 @@
 #ifndef _ASM_X86_CLOCKSOURCE_H
 #define _ASM_X86_CLOCKSOURCE_H
 
-#ifdef CONFIG_X86_64
-
 #define VCLOCK_NONE 0  /* No vDSO clock available. */
 #define VCLOCK_TSC  1  /* vDSO should use vread_tsc.   */
 #define VCLOCK_HPET 2  /* vDSO should use vread_hpet.  */
@@ -14,6 +12,4 @@ struct arch_clocksource_data {
int vclock_mode;
 };
 
-#endif /* CONFIG_X86_64 */
-
 #endif /* _ASM_X86_CLOCKSOURCE_H */
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index d76ac40..0a534ea 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -16,9 +16,6 @@
  * you mess up, the linker will catch it.)
  */
 
-/* Base address of vvars.  This is not ABI. */
-#define VVAR_ADDRESS (-10*1024*1024 - 4096)
-
 #if defined(__VVAR_KERNEL_LDS)
 
 /* The kernel linker script defines its own magic to put vvars in the
@@ -29,6 +26,15 @@
 
 #else
 
+extern char __vvar_page;
+
+/* Base address of vvars.  This is not ABI. */
+#ifdef CONFIG_X86_64
+#define VVAR_ADDRESS (-10*1024*1024 - 4096)
+#else
+#define VVAR_ADDRESS (&__vvar_page)
+#endif
+
 #define DECLARE_VVAR(offset, type, name)   \
static type const * const vvaraddr_ ## name =   \
(void *)(VVAR_ADDRESS + (offset));
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index cb648c8..f4d9600 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y  += probe_roms.o
 obj-$(CONFIG_X86_32)   += i386_ksyms_32.o
 obj-$(CONFIG_X86_64)   += sys_x86_64.o x8664_ksyms_64.o
-obj-y  += syscall_$(BITS).o
+obj-y  += syscall_$(BITS).o vsyscall_gtod.o
 obj-$(CONFIG_X86_64)   += vsyscall_64.o
 obj-$(CONFIG_X86_64)   += vsyscall_emu_64.o
 obj-$(CONFIG_SYSFS)+= ksysfs.o
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index da85a8e..e4b86ab 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -752,9 +752,7 @@ static struct clocksource clocksource_hpet = {
.mask   = HPET_MASK,
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
.resume = hpet_resume_counter,
-#ifdef CONFIG_X86_64
.archdata   = { .vclock_mode = VCLOCK_HPET },
-#endif
 };
 
 static int hpet_clocksource_register(void)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfbe99f..227dcfc 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -985,9 +985,7 @@ static struct clocksource clocksource_tsc = {
.mask   = CLOCKSOURCE_MASK(64),
.flags  = CLOCK_SOURCE_IS_CONTINUOUS |
  CLOCK_SOURCE_MUST_VERIFY,
-#ifdef CONFIG_X86_64
.archdata   = { .vclock_mode = VCLOCK_TS

[tip:x86/vdso] x86, vdso: Cleanup __vdso_gettimeofday()

[tip-bot for Stefani Seibold]

Commit-ID:  0df1ea2b7955d3cb311a549c44ed482452b859ff
Gitweb: http://git.kernel.org/tip/0df1ea2b7955d3cb311a549c44ed482452b859ff
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:06 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:52:26 -0700

x86, vdso: Cleanup __vdso_gettimeofday()

This patch cleans up the __vdso_gettimeofday() function a little.

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 
Link: 
http://lkml.kernel.org/r/1395094933-14252-7-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/vdso/vclock_gettime.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 743f277..09dae4a 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -259,13 +259,12 @@ int clock_gettime(clockid_t, struct timespec *)
 
 notrace int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz)
 {
-   long ret = VCLOCK_NONE;
-
if (likely(tv != NULL)) {
BUILD_BUG_ON(offsetof(struct timeval, tv_usec) !=
 offsetof(struct timespec, tv_nsec) ||
 sizeof(*tv) != sizeof(struct timespec));
-   ret = do_realtime((struct timespec *)tv);
+   if (unlikely(do_realtime((struct timespec *)tv) == VCLOCK_NONE))
+   return vdso_fallback_gtod(tv, tz);
tv->tv_usec /= 1000;
}
if (unlikely(tz != NULL)) {
@@ -274,8 +273,6 @@ notrace int __vdso_gettimeofday(struct timeval *tv, struct 
timezone *tz)
tz->tz_dsttime = gtod->sys_tz.tz_dsttime;
}
 
-   if (ret == VCLOCK_NONE)
-   return vdso_fallback_gtod(tv, tz);
return 0;
 }
 int gettimeofday(struct timeval *, struct timezone *)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Revamp vclock_gettime.c

[tip-bot for Stefani Seibold]

Commit-ID:  411f790cd7e91fac0db80d3cf789cb6deeac298e
Gitweb: http://git.kernel.org/tip/411f790cd7e91fac0db80d3cf789cb6deeac298e
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:03 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:51:59 -0700

x86, vdso: Revamp vclock_gettime.c

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 
Link: 
http://lkml.kernel.org/r/1395094933-14252-4-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/vdso/vclock_gettime.c | 85 +-
 1 file changed, 42 insertions(+), 43 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index eb5d7a5..bbc8065 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -26,41 +26,26 @@
 
 #define gtod ((vsyscall_gtod_data))
 
-notrace static cycle_t vread_tsc(void)
+static notrace cycle_t vread_hpet(void)
 {
-   cycle_t ret;
-   u64 last;
-
-   /*
-* Empirically, a fence (of type that depends on the CPU)
-* before rdtsc is enough to ensure that rdtsc is ordered
-* with respect to loads.  The various CPU manuals are unclear
-* as to whether rdtsc can be reordered with later loads,
-* but no one has ever seen it happen.
-*/
-   rdtsc_barrier();
-   ret = (cycle_t)vget_cycles();
-
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
-
-   if (likely(ret >= last))
-   return ret;
+   return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
+}
 
-   /*
-* GCC likes to generate cmov here, but this branch is extremely
-* predictable (it's just a funciton of time and the likely is
-* very likely) and there's a data dependence, so force GCC
-* to generate a branch instead.  I don't barrier() because
-* we don't actually need a barrier, and if this function
-* ever gets inlined it will generate worse code.
-*/
-   asm volatile ("");
-   return last;
+notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+{
+   long ret;
+   asm("syscall" : "=a" (ret) :
+   "0" (__NR_clock_gettime), "D" (clock), "S" (ts) : "memory");
+   return ret;
 }
 
-static notrace cycle_t vread_hpet(void)
+notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
 {
-   return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
+   long ret;
+
+   asm("syscall" : "=a" (ret) :
+   "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
+   return ret;
 }
 
 #ifdef CONFIG_PARAVIRT_CLOCK
@@ -133,23 +118,37 @@ static notrace cycle_t vread_pvclock(int *mode)
 }
 #endif
 
-notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+notrace static cycle_t vread_tsc(void)
 {
-   long ret;
-   asm("syscall" : "=a" (ret) :
-   "0" (__NR_clock_gettime),"D" (clock), "S" (ts) : "memory");
-   return ret;
-}
+   cycle_t ret;
+   u64 last;
 
-notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
-{
-   long ret;
+   /*
+* Empirically, a fence (of type that depends on the CPU)
+* before rdtsc is enough to ensure that rdtsc is ordered
+* with respect to loads.  The various CPU manuals are unclear
+* as to whether rdtsc can be reordered with later loads,
+* but no one has ever seen it happen.
+*/
+   rdtsc_barrier();
+   ret = (cycle_t)vget_cycles();
 
-   asm("syscall" : "=a" (ret) :
-   "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
-   return ret;
-}
+   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
 
+   if (likely(ret >= last))
+   return ret;
+
+   /*
+* GCC likes to generate cmov here, but this branch is extremely
+* predictable (it's just a funciton of time and the likely is
+* very likely) and there's a data dependence, so force GCC
+* to generate a branch instead.  I don't barrier() because
+* we don't actually need a barrier, and if this function
+* ever gets inlined it will generate worse code.
+*/
+   asm volatile ("");
+   return last;
+}
 
 notrace static inline u64 vgetsns(int *mode)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso32: handle 32 bit vDSO larger one page

[tip-bot for Stefani Seibold]

Commit-ID:  4e40112c4ff6a577dd06d92b2a54cdf06265bf74
Gitweb: http://git.kernel.org/tip/4e40112c4ff6a577dd06d92b2a54cdf06265bf74
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:13 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:52:54 -0700

x86, vdso32: handle 32 bit vDSO larger one page

This patch enables 32 bit vDSO which are larger than a page.

Signed-off-by: Stefani Seibold 
Link: 
http://lkml.kernel.org/r/1395094933-14252-14-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/vdso/vdso32-setup.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index e10abdf..5b4aaef 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -69,7 +70,8 @@ __setup_param("vdso=", vdso32_setup, vdso_setup, 0);
 EXPORT_SYMBOL_GPL(vdso_enabled);
 #endif
 
-static struct page *vdso32_pages[1];
+static struct page **vdso32_pages;
+static unsigned int vdso32_size;
 
 #ifdef CONFIG_X86_64
 
@@ -115,11 +117,10 @@ void enable_sep_cpu(void)
 
 int __init sysenter_setup(void)
 {
-   void *vdso_page = (void *)get_zeroed_page(GFP_ATOMIC);
+   void *vdso_pages;
const void *vdso;
size_t vdso_len;
-
-   vdso32_pages[0] = virt_to_page(vdso_page);
+   unsigned int i;
 
if (vdso32_syscall()) {
vdso = _syscall_start;
@@ -132,8 +133,15 @@ int __init sysenter_setup(void)
vdso_len = _int80_end - _int80_start;
}
 
-   memcpy(vdso_page, vdso, vdso_len);
-   patch_vdso32(vdso_page, vdso_len);
+   vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
+   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC);
+   vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC);
+
+   for(i = 0; i != vdso32_size; ++i)
+   vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));
+
+   memcpy(vdso_pages, vdso, vdso_len);
+   patch_vdso32(vdso_pages, vdso_len);
 
return 0;
 }
@@ -169,7 +177,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
 */
ret = install_special_mapping(mm,
addr,
-   VDSO_OFFSET(VDSO_PAGES - VDSO_PREV_PAGES),
+   VDSO_OFFSET(vdso32_size),
VM_READ|VM_EXEC|
VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
vdso32_pages);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Add 32 bit VDSO time support for 32 bit kernel

[tip-bot for Stefani Seibold]

Commit-ID:  7a59ed415f5b57469e22e41fc4188d5399e0b194
Gitweb: http://git.kernel.org/tip/7a59ed415f5b57469e22e41fc4188d5399e0b194
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:09 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:52:37 -0700

x86, vdso: Add 32 bit VDSO time support for 32 bit kernel

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 
Link: 
http://lkml.kernel.org/r/1395094933-14252-10-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/vdso.h   |  5 +++
 arch/x86/include/asm/vdso32.h | 11 +
 arch/x86/vdso/Makefile|  8 
 arch/x86/vdso/vclock_gettime.c| 76 +++
 arch/x86/vdso/vdso-layout.lds.S   | 22 ++
 arch/x86/vdso/vdso32-setup.c  | 47 --
 arch/x86/vdso/vdso32/vclock_gettime.c |  9 +
 arch/x86/vdso/vdso32/vdso32.lds.S | 11 +
 8 files changed, 178 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index f8605e6..bde4359 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -2,6 +2,11 @@
 #define _ASM_X86_VDSO_H
 
 #if defined CONFIG_X86_32 || defined CONFIG_COMPAT
+
+#include 
+
+extern const char VDSO32_PRELINK[];
+
 /*
  * Given a pointer to the vDSO image, find the pointer to VDSO32_name
  * as that symbol is defined in the vDSO sources or linker script.
diff --git a/arch/x86/include/asm/vdso32.h b/arch/x86/include/asm/vdso32.h
new file mode 100644
index 000..7efb701
--- /dev/null
+++ b/arch/x86/include/asm/vdso32.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_X86_VDSO32_H
+#define _ASM_X86_VDSO32_H
+
+#define VDSO_BASE_PAGE 0
+#define VDSO_VVAR_PAGE 1
+#define VDSO_HPET_PAGE 2
+#define VDSO_PAGES 3
+#define VDSO_PREV_PAGES2
+#define VDSO_OFFSET(x) ((x) * PAGE_SIZE)
+
+#endif
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 7a3d13e..6cef7a1 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -146,8 +146,16 @@ KBUILD_AFLAGS_32 := $(filter-out -m64,$(KBUILD_AFLAGS))
 $(vdso32-images:%=$(obj)/%.dbg): KBUILD_AFLAGS = $(KBUILD_AFLAGS_32)
 $(vdso32-images:%=$(obj)/%.dbg): asflags-$(CONFIG_X86_64) += -m32
 
+KBUILD_CFLAGS_32 := $(filter-out -m64,$(KBUILD_CFLAGS))
+KBUILD_CFLAGS_32 := $(filter-out -mcmodel=kernel,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
+$(vdso32-images:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
+
 $(vdso32-images:%=$(obj)/%.dbg): $(obj)/vdso32-%.so.dbg: FORCE \
 $(obj)/vdso32/vdso32.lds \
+$(obj)/vdso32/vclock_gettime.o \
 $(obj)/vdso32/note.o \
 $(obj)/vdso32/%.o
$(call if_changed,vdso)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 09dae4a..90bb5e8 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -4,6 +4,9 @@
  *
  * Fast user context implementation of clock_gettime, gettimeofday, and time.
  *
+ * 32 Bit compat layer by Stefani Seibold 
+ *  sponsored by Rohde & Schwarz GmbH & Co. KG Munich/Germany
+ *
  * The code should have no internal unresolved relocations.
  * Check with readelf after changing.
  */
@@ -12,13 +15,11 @@
 #define DISABLE_BRANCH_PROFILING
 
 #include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,12 @@
 
 #define gtod ((vsyscall_gtod_data))
 
+extern int __vdso_clock_gettime(clockid_t clock, struct timespec *ts);
+extern int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz);
+extern time_t __vdso_time(time_t *t);
+
+#ifndef BUILD_VDSO32
+
 static notrace cycle_t vread_hpet(void)
 {
return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
@@ -118,6 +125,59 @@ static notrace cycle_t vread_pvclock(int *mode)
 }
 #endif
 
+#else
+
+extern u8 hpet_page
+   __attribute__((visibility("hidden")));
+
+#ifdef CONFIG_HPET_TIMER
+static notrace cycle_t vread_hpet(void)
+{
+   return readl((const void __iomem *)(_page + HPET_COUNTER));
+}
+#endif
+
+notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+{
+   long ret;
+
+   asm(
+   "mov %%ebx, %%edx \n"
+   "mov %2, %%ebx \n"
+   "call VDSO32_vsyscall \n"
+   "mov %%edx, %%ebx \n"
+   : "=a" (ret)
+   : "0"

[tip:x86/vdso] mm: Add new func _install_special_mapping() to mmap.c

[tip-bot for Stefani Seibold]

Commit-ID:  3935ed6a3a533c1736e3ca65bff72afd1773be27
Gitweb: http://git.kernel.org/tip/3935ed6a3a533c1736e3ca65bff72afd1773be27
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:02 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:51:56 -0700

mm: Add new func _install_special_mapping() to mmap.c

The _install_special_mapping() is the new base function for
install_special_mapping(). This function will return a pointer of the
created VMA or a error code in an ERR_PTR()

This new function will be needed by the for the vdso 32 bit support to map the
additonal vvar and hpet pages into the 32 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 
Link: 
http://lkml.kernel.org/r/1395094933-14252-3-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 include/linux/mm.h |  3 +++
 mm/mmap.c  | 20 
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index c1b7414..6c7fedf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1750,6 +1750,9 @@ extern void set_mm_exe_file(struct mm_struct *mm, struct 
file *new_exe_file);
 extern struct file *get_mm_exe_file(struct mm_struct *mm);
 
 extern int may_expand_vm(struct mm_struct *mm, unsigned long npages);
+extern struct vm_area_struct *_install_special_mapping(struct mm_struct *mm,
+  unsigned long addr, unsigned long len,
+  unsigned long flags, struct page **pages);
 extern int install_special_mapping(struct mm_struct *mm,
   unsigned long addr, unsigned long len,
   unsigned long flags, struct page **pages);
diff --git a/mm/mmap.c b/mm/mmap.c
index 20ff0c3..81ba54f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2918,7 +2918,7 @@ static const struct vm_operations_struct 
special_mapping_vmops = {
  * The array pointer and the pages it points to are assumed to stay alive
  * for as long as this mapping might exist.
  */
-int install_special_mapping(struct mm_struct *mm,
+struct vm_area_struct *_install_special_mapping(struct mm_struct *mm,
unsigned long addr, unsigned long len,
unsigned long vm_flags, struct page **pages)
 {
@@ -2927,7 +2927,7 @@ int install_special_mapping(struct mm_struct *mm,
 
vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
if (unlikely(vma == NULL))
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
INIT_LIST_HEAD(>anon_vma_chain);
vma->vm_mm = mm;
@@ -2948,11 +2948,23 @@ int install_special_mapping(struct mm_struct *mm,
 
perf_event_mmap(vma);
 
-   return 0;
+   return vma;
 
 out:
kmem_cache_free(vm_area_cachep, vma);
-   return ret;
+   return ERR_PTR(ret);
+}
+
+int install_special_mapping(struct mm_struct *mm,
+   unsigned long addr, unsigned long len,
+   unsigned long vm_flags, struct page **pages)
+{
+   struct vm_area_struct *vma = _install_special_mapping(mm,
+   addr, len, vm_flags, pages);
+
+   if (IS_ERR(vma))
+   return PTR_ERR(vma);
+   return 0;
 }
 
 static DEFINE_MUTEX(mm_all_locks_mutex);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Replace VVAR(vsyscall_gtod_data) by gtod macro

[tip-bot for Stefani Seibold]

Commit-ID:  af8c93d8d9809c3cf71cae2c398069399e64efa3
Gitweb: http://git.kernel.org/tip/af8c93d8d9809c3cf71cae2c398069399e64efa3
Author: Stefani Seibold 
AuthorDate: Mon, 17 Mar 2014 23:22:05 +0100
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Mar 2014 12:52:03 -0700

x86, vdso: Replace VVAR(vsyscall_gtod_data) by gtod macro

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 
Link: 
http://lkml.kernel.org/r/1395094933-14252-6-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 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/x86/vdso/vclock_gettime.c
index fd074dd..743f277 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -109,7 +109,7 @@ static notrace cycle_t vread_pvclock(int *mode)
*mode = VCLOCK_NONE;
 
/* refer to tsc.c read_tsc() comment for rationale */
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
+   last = gtod->clock.cycle_last;
 
if (likely(ret >= last))
return ret;
@@ -133,7 +133,7 @@ notrace static cycle_t vread_tsc(void)
rdtsc_barrier();
ret = (cycle_t)vget_cycles();
 
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
+   last = gtod->clock.cycle_last;
 
if (likely(ret >= last))
return ret;
@@ -288,7 +288,7 @@ int gettimeofday(struct timeval *, struct timezone *)
 notrace time_t __vdso_time(time_t *t)
 {
/* This is atomic on x86_64 so we don't need any locks. */
-   time_t result = ACCESS_ONCE(VVAR(vsyscall_gtod_data).wall_time_sec);
+   time_t result = ACCESS_ONCE(gtod->wall_time_sec);
 
if (t)
*t = result;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] mm: Add new func _install_special_mapping() to mmap.c

[tip-bot for Stefani Seibold]

Commit-ID:  3935ed6a3a533c1736e3ca65bff72afd1773be27
Gitweb: http://git.kernel.org/tip/3935ed6a3a533c1736e3ca65bff72afd1773be27
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:02 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:51:56 -0700

mm: Add new func _install_special_mapping() to mmap.c

The _install_special_mapping() is the new base function for
install_special_mapping(). This function will return a pointer of the
created VMA or a error code in an ERR_PTR()

This new function will be needed by the for the vdso 32 bit support to map the
additonal vvar and hpet pages into the 32 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 l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-3-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 include/linux/mm.h |  3 +++
 mm/mmap.c  | 20 
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index c1b7414..6c7fedf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1750,6 +1750,9 @@ extern void set_mm_exe_file(struct mm_struct *mm, struct 
file *new_exe_file);
 extern struct file *get_mm_exe_file(struct mm_struct *mm);
 
 extern int may_expand_vm(struct mm_struct *mm, unsigned long npages);
+extern struct vm_area_struct *_install_special_mapping(struct mm_struct *mm,
+  unsigned long addr, unsigned long len,
+  unsigned long flags, struct page **pages);
 extern int install_special_mapping(struct mm_struct *mm,
   unsigned long addr, unsigned long len,
   unsigned long flags, struct page **pages);
diff --git a/mm/mmap.c b/mm/mmap.c
index 20ff0c3..81ba54f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2918,7 +2918,7 @@ static const struct vm_operations_struct 
special_mapping_vmops = {
  * The array pointer and the pages it points to are assumed to stay alive
  * for as long as this mapping might exist.
  */
-int install_special_mapping(struct mm_struct *mm,
+struct vm_area_struct *_install_special_mapping(struct mm_struct *mm,
unsigned long addr, unsigned long len,
unsigned long vm_flags, struct page **pages)
 {
@@ -2927,7 +2927,7 @@ int install_special_mapping(struct mm_struct *mm,
 
vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
if (unlikely(vma == NULL))
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
INIT_LIST_HEAD(vma-anon_vma_chain);
vma-vm_mm = mm;
@@ -2948,11 +2948,23 @@ int install_special_mapping(struct mm_struct *mm,
 
perf_event_mmap(vma);
 
-   return 0;
+   return vma;
 
 out:
kmem_cache_free(vm_area_cachep, vma);
-   return ret;
+   return ERR_PTR(ret);
+}
+
+int install_special_mapping(struct mm_struct *mm,
+   unsigned long addr, unsigned long len,
+   unsigned long vm_flags, struct page **pages)
+{
+   struct vm_area_struct *vma = _install_special_mapping(mm,
+   addr, len, vm_flags, pages);
+
+   if (IS_ERR(vma))
+   return PTR_ERR(vma);
+   return 0;
 }
 
 static DEFINE_MUTEX(mm_all_locks_mutex);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Add 32 bit VDSO time support for 64 bit kernel

[tip-bot for Stefani Seibold]

Commit-ID:  7c03156f34d113f885f045d8fb8cc3efd9e64751
Gitweb: http://git.kernel.org/tip/7c03156f34d113f885f045d8fb8cc3efd9e64751
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:10 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:52:41 -0700

x86, vdso: Add 32 bit VDSO time support for 64 bit kernel

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 for optimal performance.

The vsyscall_gtod_data struture must be a rearranged to serve 32- and
64-bit code access at the same time:

- The seqcount_t was replaced by an unsigned, this makes the
  vsyscall_gtod_data intedepend of kernel configuration and internal functions.
- All kernel internal structures are replaced by fix size elements
  which works for 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 stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-11-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/include/asm/vgtod.h  | 71 +--
 arch/x86/include/asm/vvar.h   |  5 ++
 arch/x86/kernel/vsyscall_gtod.c   | 34 -
 arch/x86/vdso/vclock_gettime.c| 91 +++
 arch/x86/vdso/vdso32/vclock_gettime.c | 21 
 5 files changed, 155 insertions(+), 67 deletions(-)

diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index 46e24d3..3c3366c 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -1,30 +1,73 @@
 #ifndef _ASM_X86_VGTOD_H
 #define _ASM_X86_VGTOD_H
 
-#include asm/vsyscall.h
+#include linux/compiler.h
 #include linux/clocksource.h
 
+#ifdef BUILD_VDSO32_64
+typedef u64 gtod_long_t;
+#else
+typedef unsigned long gtod_long_t;
+#endif
+/*
+ * vsyscall_gtod_data will be accessed by 32 and 64 bit code at the same time
+ * so be carefull by modifying this structure.
+ */
 struct vsyscall_gtod_data {
-   seqcount_t  seq;
+   unsigned seq;
 
-   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;
u64 wall_time_snsec;
+   gtod_long_t wall_time_sec;
+   gtod_long_t monotonic_time_sec;
u64 monotonic_time_snsec;
-   time_t  monotonic_time_sec;
+   gtod_long_t wall_time_coarse_sec;
+   gtod_long_t wall_time_coarse_nsec;
+   gtod_long_t monotonic_time_coarse_sec;
+   gtod_long_t monotonic_time_coarse_nsec;
 
-   struct timezone sys_tz;
-   struct timespec wall_time_coarse;
-   struct timespec monotonic_time_coarse;
+   int tz_minuteswest;
+   int tz_dsttime;
 };
 extern struct vsyscall_gtod_data vsyscall_gtod_data;
 
+static inline unsigned gtod_read_begin(const struct vsyscall_gtod_data *s)
+{
+   unsigned ret;
+
+repeat:
+   ret = ACCESS_ONCE(s-seq);
+   if (unlikely(ret  1)) {
+   cpu_relax();
+   goto repeat;
+   }
+   smp_rmb();
+   return ret;
+}
+
+static inline int gtod_read_retry(const struct vsyscall_gtod_data *s,
+   unsigned start)
+{
+   smp_rmb();
+   return unlikely(s-seq != start);
+}
+
+static inline void gtod_write_begin(struct vsyscall_gtod_data *s)
+{
+   ++s-seq;
+   smp_wmb();
+}
+
+static inline void gtod_write_end(struct vsyscall_gtod_data *s)
+{
+   smp_wmb();
+   ++s-seq;
+}
+
 #endif /* _ASM_X86_VGTOD_H */
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index 52c79ff..081d909 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -16,6 +16,9 @@
  * you mess up, the linker will catch it.)
  */
 
+#ifndef _ASM_X86_VVAR_H
+#define _ASM_X86_VVAR_H
+
 #if defined(__VVAR_KERNEL_LDS)
 
 /* The kernel linker script defines its own magic to put vvars in the
@@ -64,3 +67,5 @@ DECLARE_VVAR(16, int, vgetcpu_mode)
 DECLARE_VVAR(128, struct vsyscall_gtod_data, vsyscall_gtod_data)
 
 #undef DECLARE_VVAR
+
+#endif
diff --git a/arch/x86/kernel/vsyscall_gtod.c b/arch/x86/kernel/vsyscall_gtod.c
index b5a943d..f9c6e56 100644
--- a/arch/x86/kernel/vsyscall_gtod.c
+++ b/arch/x86/kernel/vsyscall_gtod.c
@@ -4,6 +4,7 @@
  *
  *  Modified for x86 32 bit architecture by
  *  Stefani

[tip:x86/vdso] x86, vdso: Make vsyscall_gtod_data handling x86 generic

[tip-bot for Stefani Seibold]

Commit-ID:  d2312e3379d581d2c3603357a0181046448e1de3
Gitweb: http://git.kernel.org/tip/d2312e3379d581d2c3603357a0181046448e1de3
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:01 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:51:52 -0700

x86, vdso: Make vsyscall_gtod_data handling x86 generic

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 l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-2-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/Kconfig   |  4 +--
 arch/x86/include/asm/clocksource.h |  4 ---
 arch/x86/include/asm/vvar.h| 12 ++--
 arch/x86/kernel/Makefile   |  2 +-
 arch/x86/kernel/hpet.c |  2 --
 arch/x86/kernel/tsc.c  |  2 --
 arch/x86/kernel/vmlinux.lds.S  |  3 --
 arch/x86/kernel/vsyscall_64.c  | 45 -
 arch/x86/kernel/vsyscall_gtod.c| 59 ++
 arch/x86/tools/relocs.c|  2 +-
 10 files changed, 72 insertions(+), 63 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9122f6b..ab3ebc8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -107,9 +107,9 @@ config X86
select HAVE_ARCH_SOFT_DIRTY
select CLOCKSOURCE_WATCHDOG
select GENERIC_CLOCKEVENTS
-   select ARCH_CLOCKSOURCE_DATA if X86_64
+   select ARCH_CLOCKSOURCE_DATA
select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32  
X86_LOCAL_APIC)
-   select GENERIC_TIME_VSYSCALL if X86_64
+   select GENERIC_TIME_VSYSCALL
select KTIME_SCALAR if X86_32
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/x86/include/asm/clocksource.h 
b/arch/x86/include/asm/clocksource.h
index 16a57f4..eda81dc 100644
--- a/arch/x86/include/asm/clocksource.h
+++ b/arch/x86/include/asm/clocksource.h
@@ -3,8 +3,6 @@
 #ifndef _ASM_X86_CLOCKSOURCE_H
 #define _ASM_X86_CLOCKSOURCE_H
 
-#ifdef CONFIG_X86_64
-
 #define VCLOCK_NONE 0  /* No vDSO clock available. */
 #define VCLOCK_TSC  1  /* vDSO should use vread_tsc.   */
 #define VCLOCK_HPET 2  /* vDSO should use vread_hpet.  */
@@ -14,6 +12,4 @@ struct arch_clocksource_data {
int vclock_mode;
 };
 
-#endif /* CONFIG_X86_64 */
-
 #endif /* _ASM_X86_CLOCKSOURCE_H */
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index d76ac40..0a534ea 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -16,9 +16,6 @@
  * you mess up, the linker will catch it.)
  */
 
-/* Base address of vvars.  This is not ABI. */
-#define VVAR_ADDRESS (-10*1024*1024 - 4096)
-
 #if defined(__VVAR_KERNEL_LDS)
 
 /* The kernel linker script defines its own magic to put vvars in the
@@ -29,6 +26,15 @@
 
 #else
 
+extern char __vvar_page;
+
+/* Base address of vvars.  This is not ABI. */
+#ifdef CONFIG_X86_64
+#define VVAR_ADDRESS (-10*1024*1024 - 4096)
+#else
+#define VVAR_ADDRESS (__vvar_page)
+#endif
+
 #define DECLARE_VVAR(offset, type, name)   \
static type const * const vvaraddr_ ## name =   \
(void *)(VVAR_ADDRESS + (offset));
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index cb648c8..f4d9600 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y  += probe_roms.o
 obj-$(CONFIG_X86_32)   += i386_ksyms_32.o
 obj-$(CONFIG_X86_64)   += sys_x86_64.o x8664_ksyms_64.o
-obj-y  += syscall_$(BITS).o
+obj-y  += syscall_$(BITS).o vsyscall_gtod.o
 obj-$(CONFIG_X86_64)   += vsyscall_64.o
 obj-$(CONFIG_X86_64)   += vsyscall_emu_64.o
 obj-$(CONFIG_SYSFS)+= ksysfs.o
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index da85a8e..e4b86ab 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -752,9 +752,7 @@ static struct clocksource clocksource_hpet = {
.mask   = HPET_MASK,
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
.resume = hpet_resume_counter,
-#ifdef CONFIG_X86_64
.archdata   = { .vclock_mode = VCLOCK_HPET },
-#endif
 };
 
 static int hpet_clocksource_register(void)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfbe99f..227dcfc 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -985,9 +985,7 @@ static struct clocksource clocksource_tsc = {
.mask   = CLOCKSOURCE_MASK(64),
.flags  = CLOCK_SOURCE_IS_CONTINUOUS |
  CLOCK_SOURCE_MUST_VERIFY

[tip:x86/vdso] x86, vdso: Replace VVAR(vsyscall_gtod_data) by gtod macro

[tip-bot for Stefani Seibold]

Commit-ID:  af8c93d8d9809c3cf71cae2c398069399e64efa3
Gitweb: http://git.kernel.org/tip/af8c93d8d9809c3cf71cae2c398069399e64efa3
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:05 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:52:03 -0700

x86, vdso: Replace VVAR(vsyscall_gtod_data) by gtod macro

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 l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-6-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 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/x86/vdso/vclock_gettime.c
index fd074dd..743f277 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -109,7 +109,7 @@ static notrace cycle_t vread_pvclock(int *mode)
*mode = VCLOCK_NONE;
 
/* refer to tsc.c read_tsc() comment for rationale */
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
+   last = gtod-clock.cycle_last;
 
if (likely(ret = last))
return ret;
@@ -133,7 +133,7 @@ notrace static cycle_t vread_tsc(void)
rdtsc_barrier();
ret = (cycle_t)vget_cycles();
 
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
+   last = gtod-clock.cycle_last;
 
if (likely(ret = last))
return ret;
@@ -288,7 +288,7 @@ int gettimeofday(struct timeval *, struct timezone *)
 notrace time_t __vdso_time(time_t *t)
 {
/* This is atomic on x86_64 so we don't need any locks. */
-   time_t result = ACCESS_ONCE(VVAR(vsyscall_gtod_data).wall_time_sec);
+   time_t result = ACCESS_ONCE(gtod-wall_time_sec);
 
if (t)
*t = result;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Cleanup __vdso_gettimeofday()

[tip-bot for Stefani Seibold]

Commit-ID:  0df1ea2b7955d3cb311a549c44ed482452b859ff
Gitweb: http://git.kernel.org/tip/0df1ea2b7955d3cb311a549c44ed482452b859ff
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:06 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:52:26 -0700

x86, vdso: Cleanup __vdso_gettimeofday()

This patch cleans up the __vdso_gettimeofday() function a little.

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 l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-7-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/vdso/vclock_gettime.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 743f277..09dae4a 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -259,13 +259,12 @@ int clock_gettime(clockid_t, struct timespec *)
 
 notrace int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz)
 {
-   long ret = VCLOCK_NONE;
-
if (likely(tv != NULL)) {
BUILD_BUG_ON(offsetof(struct timeval, tv_usec) !=
 offsetof(struct timespec, tv_nsec) ||
 sizeof(*tv) != sizeof(struct timespec));
-   ret = do_realtime((struct timespec *)tv);
+   if (unlikely(do_realtime((struct timespec *)tv) == VCLOCK_NONE))
+   return vdso_fallback_gtod(tv, tz);
tv-tv_usec /= 1000;
}
if (unlikely(tz != NULL)) {
@@ -274,8 +273,6 @@ notrace int __vdso_gettimeofday(struct timeval *tv, struct 
timezone *tz)
tz-tz_dsttime = gtod-sys_tz.tz_dsttime;
}
 
-   if (ret == VCLOCK_NONE)
-   return vdso_fallback_gtod(tv, tz);
return 0;
 }
 int gettimeofday(struct timeval *, struct timezone *)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Revamp vclock_gettime.c

[tip-bot for Stefani Seibold]

Commit-ID:  411f790cd7e91fac0db80d3cf789cb6deeac298e
Gitweb: http://git.kernel.org/tip/411f790cd7e91fac0db80d3cf789cb6deeac298e
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:03 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:51:59 -0700

x86, vdso: Revamp vclock_gettime.c

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 l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-4-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/vdso/vclock_gettime.c | 85 +-
 1 file changed, 42 insertions(+), 43 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index eb5d7a5..bbc8065 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -26,41 +26,26 @@
 
 #define gtod (VVAR(vsyscall_gtod_data))
 
-notrace static cycle_t vread_tsc(void)
+static notrace cycle_t vread_hpet(void)
 {
-   cycle_t ret;
-   u64 last;
-
-   /*
-* Empirically, a fence (of type that depends on the CPU)
-* before rdtsc is enough to ensure that rdtsc is ordered
-* with respect to loads.  The various CPU manuals are unclear
-* as to whether rdtsc can be reordered with later loads,
-* but no one has ever seen it happen.
-*/
-   rdtsc_barrier();
-   ret = (cycle_t)vget_cycles();
-
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
-
-   if (likely(ret = last))
-   return ret;
+   return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
+}
 
-   /*
-* GCC likes to generate cmov here, but this branch is extremely
-* predictable (it's just a funciton of time and the likely is
-* very likely) and there's a data dependence, so force GCC
-* to generate a branch instead.  I don't barrier() because
-* we don't actually need a barrier, and if this function
-* ever gets inlined it will generate worse code.
-*/
-   asm volatile ();
-   return last;
+notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+{
+   long ret;
+   asm(syscall : =a (ret) :
+   0 (__NR_clock_gettime), D (clock), S (ts) : memory);
+   return ret;
 }
 
-static notrace cycle_t vread_hpet(void)
+notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
 {
-   return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
+   long ret;
+
+   asm(syscall : =a (ret) :
+   0 (__NR_gettimeofday), D (tv), S (tz) : memory);
+   return ret;
 }
 
 #ifdef CONFIG_PARAVIRT_CLOCK
@@ -133,23 +118,37 @@ static notrace cycle_t vread_pvclock(int *mode)
 }
 #endif
 
-notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+notrace static cycle_t vread_tsc(void)
 {
-   long ret;
-   asm(syscall : =a (ret) :
-   0 (__NR_clock_gettime),D (clock), S (ts) : memory);
-   return ret;
-}
+   cycle_t ret;
+   u64 last;
 
-notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
-{
-   long ret;
+   /*
+* Empirically, a fence (of type that depends on the CPU)
+* before rdtsc is enough to ensure that rdtsc is ordered
+* with respect to loads.  The various CPU manuals are unclear
+* as to whether rdtsc can be reordered with later loads,
+* but no one has ever seen it happen.
+*/
+   rdtsc_barrier();
+   ret = (cycle_t)vget_cycles();
 
-   asm(syscall : =a (ret) :
-   0 (__NR_gettimeofday), D (tv), S (tz) : memory);
-   return ret;
-}
+   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
 
+   if (likely(ret = last))
+   return ret;
+
+   /*
+* GCC likes to generate cmov here, but this branch is extremely
+* predictable (it's just a funciton of time and the likely is
+* very likely) and there's a data dependence, so force GCC
+* to generate a branch instead.  I don't barrier() because
+* we don't actually need a barrier, and if this function
+* ever gets inlined it will generate worse code.
+*/
+   asm volatile ();
+   return last;
+}
 
 notrace static inline u64 vgetsns(int *mode)
 {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso32: handle 32 bit vDSO larger one page

[tip-bot for Stefani Seibold]

Commit-ID:  4e40112c4ff6a577dd06d92b2a54cdf06265bf74
Gitweb: http://git.kernel.org/tip/4e40112c4ff6a577dd06d92b2a54cdf06265bf74
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:13 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:52:54 -0700

x86, vdso32: handle 32 bit vDSO larger one page

This patch enables 32 bit vDSO which are larger than a page.

Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-14-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/vdso/vdso32-setup.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index e10abdf..5b4aaef 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -16,6 +16,7 @@
 #include linux/mm.h
 #include linux/err.h
 #include linux/module.h
+#include linux/slab.h
 
 #include asm/cpufeature.h
 #include asm/msr.h
@@ -69,7 +70,8 @@ __setup_param(vdso=, vdso32_setup, vdso_setup, 0);
 EXPORT_SYMBOL_GPL(vdso_enabled);
 #endif
 
-static struct page *vdso32_pages[1];
+static struct page **vdso32_pages;
+static unsigned int vdso32_size;
 
 #ifdef CONFIG_X86_64
 
@@ -115,11 +117,10 @@ void enable_sep_cpu(void)
 
 int __init sysenter_setup(void)
 {
-   void *vdso_page = (void *)get_zeroed_page(GFP_ATOMIC);
+   void *vdso_pages;
const void *vdso;
size_t vdso_len;
-
-   vdso32_pages[0] = virt_to_page(vdso_page);
+   unsigned int i;
 
if (vdso32_syscall()) {
vdso = vdso32_syscall_start;
@@ -132,8 +133,15 @@ int __init sysenter_setup(void)
vdso_len = vdso32_int80_end - vdso32_int80_start;
}
 
-   memcpy(vdso_page, vdso, vdso_len);
-   patch_vdso32(vdso_page, vdso_len);
+   vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
+   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC);
+   vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC);
+
+   for(i = 0; i != vdso32_size; ++i)
+   vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));
+
+   memcpy(vdso_pages, vdso, vdso_len);
+   patch_vdso32(vdso_pages, vdso_len);
 
return 0;
 }
@@ -169,7 +177,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
 */
ret = install_special_mapping(mm,
addr,
-   VDSO_OFFSET(VDSO_PAGES - VDSO_PREV_PAGES),
+   VDSO_OFFSET(vdso32_size),
VM_READ|VM_EXEC|
VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
vdso32_pages);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Add 32 bit VDSO time support for 32 bit kernel

[tip-bot for Stefani Seibold]

Commit-ID:  7a59ed415f5b57469e22e41fc4188d5399e0b194
Gitweb: http://git.kernel.org/tip/7a59ed415f5b57469e22e41fc4188d5399e0b194
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:09 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:52:37 -0700

x86, vdso: Add 32 bit VDSO time support for 32 bit kernel

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 l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-10-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/include/asm/vdso.h   |  5 +++
 arch/x86/include/asm/vdso32.h | 11 +
 arch/x86/vdso/Makefile|  8 
 arch/x86/vdso/vclock_gettime.c| 76 +++
 arch/x86/vdso/vdso-layout.lds.S   | 22 ++
 arch/x86/vdso/vdso32-setup.c  | 47 --
 arch/x86/vdso/vdso32/vclock_gettime.c |  9 +
 arch/x86/vdso/vdso32/vdso32.lds.S | 11 +
 8 files changed, 178 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index f8605e6..bde4359 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -2,6 +2,11 @@
 #define _ASM_X86_VDSO_H
 
 #if defined CONFIG_X86_32 || defined CONFIG_COMPAT
+
+#include asm/vdso32.h
+
+extern const char VDSO32_PRELINK[];
+
 /*
  * Given a pointer to the vDSO image, find the pointer to VDSO32_name
  * as that symbol is defined in the vDSO sources or linker script.
diff --git a/arch/x86/include/asm/vdso32.h b/arch/x86/include/asm/vdso32.h
new file mode 100644
index 000..7efb701
--- /dev/null
+++ b/arch/x86/include/asm/vdso32.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_X86_VDSO32_H
+#define _ASM_X86_VDSO32_H
+
+#define VDSO_BASE_PAGE 0
+#define VDSO_VVAR_PAGE 1
+#define VDSO_HPET_PAGE 2
+#define VDSO_PAGES 3
+#define VDSO_PREV_PAGES2
+#define VDSO_OFFSET(x) ((x) * PAGE_SIZE)
+
+#endif
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 7a3d13e..6cef7a1 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -146,8 +146,16 @@ KBUILD_AFLAGS_32 := $(filter-out -m64,$(KBUILD_AFLAGS))
 $(vdso32-images:%=$(obj)/%.dbg): KBUILD_AFLAGS = $(KBUILD_AFLAGS_32)
 $(vdso32-images:%=$(obj)/%.dbg): asflags-$(CONFIG_X86_64) += -m32
 
+KBUILD_CFLAGS_32 := $(filter-out -m64,$(KBUILD_CFLAGS))
+KBUILD_CFLAGS_32 := $(filter-out -mcmodel=kernel,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
+$(vdso32-images:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
+
 $(vdso32-images:%=$(obj)/%.dbg): $(obj)/vdso32-%.so.dbg: FORCE \
 $(obj)/vdso32/vdso32.lds \
+$(obj)/vdso32/vclock_gettime.o \
 $(obj)/vdso32/note.o \
 $(obj)/vdso32/%.o
$(call if_changed,vdso)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 09dae4a..90bb5e8 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -4,6 +4,9 @@
  *
  * Fast user context implementation of clock_gettime, gettimeofday, and time.
  *
+ * 32 Bit compat layer by Stefani Seibold stef...@seibold.net
+ *  sponsored by Rohde  Schwarz GmbH  Co. KG Munich/Germany
+ *
  * The code should have no internal unresolved relocations.
  * Check with readelf after changing.
  */
@@ -12,13 +15,11 @@
 #define DISABLE_BRANCH_PROFILING
 
 #include linux/kernel.h
-#include linux/posix-timers.h
-#include linux/time.h
+#include uapi/linux/time.h
 #include linux/string.h
 #include asm/vsyscall.h
 #include asm/fixmap.h
 #include asm/vgtod.h
-#include asm/timex.h
 #include asm/hpet.h
 #include asm/unistd.h
 #include asm/io.h
@@ -26,6 +27,12 @@
 
 #define gtod (VVAR(vsyscall_gtod_data))
 
+extern int __vdso_clock_gettime(clockid_t clock, struct timespec *ts);
+extern int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz);
+extern time_t __vdso_time(time_t *t);
+
+#ifndef BUILD_VDSO32
+
 static notrace cycle_t vread_hpet(void)
 {
return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
@@ -118,6 +125,59 @@ static notrace cycle_t vread_pvclock(int *mode)
 }
 #endif
 
+#else
+
+extern u8 hpet_page
+   __attribute__((visibility(hidden)));
+
+#ifdef CONFIG_HPET_TIMER
+static notrace cycle_t vread_hpet(void)
+{
+   return readl((const void __iomem *)(hpet_page + HPET_COUNTER));
+}
+#endif
+
+notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+{
+   long ret;
+
+   asm

[tip:x86/vdso] x86, vdso: __vdso_clock_gettime() cleanup

[tip-bot for Stefani Seibold]

Commit-ID:  ce39c64028a075d14af32bfb8336bfe1370c0443
Gitweb: http://git.kernel.org/tip/ce39c64028a075d14af32bfb8336bfe1370c0443
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:04 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:52:01 -0700

x86, vdso: __vdso_clock_gettime() cleanup

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 l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-5-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 arch/x86/vdso/vclock_gettime.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index bbc8065..fd074dd 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -209,7 +209,7 @@ notrace static int do_monotonic(struct timespec *ts)
return mode;
 }
 
-notrace static int do_realtime_coarse(struct timespec *ts)
+notrace static void do_realtime_coarse(struct timespec *ts)
 {
unsigned long seq;
do {
@@ -217,10 +217,9 @@ notrace static int do_realtime_coarse(struct timespec *ts)
ts-tv_sec = gtod-wall_time_coarse.tv_sec;
ts-tv_nsec = gtod-wall_time_coarse.tv_nsec;
} while (unlikely(read_seqcount_retry(gtod-seq, seq)));
-   return 0;
 }
 
-notrace static int do_monotonic_coarse(struct timespec *ts)
+notrace static void do_monotonic_coarse(struct timespec *ts)
 {
unsigned long seq;
do {
@@ -228,30 +227,32 @@ notrace static int do_monotonic_coarse(struct timespec 
*ts)
ts-tv_sec = gtod-monotonic_time_coarse.tv_sec;
ts-tv_nsec = gtod-monotonic_time_coarse.tv_nsec;
} while (unlikely(read_seqcount_retry(gtod-seq, seq)));
-
-   return 0;
 }
 
 notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
 {
-   int ret = VCLOCK_NONE;
-
switch (clock) {
case CLOCK_REALTIME:
-   ret = do_realtime(ts);
+   if (do_realtime(ts) == VCLOCK_NONE)
+   goto fallback;
break;
case CLOCK_MONOTONIC:
-   ret = do_monotonic(ts);
+   if (do_monotonic(ts) == VCLOCK_NONE)
+   goto fallback;
break;
case CLOCK_REALTIME_COARSE:
-   return do_realtime_coarse(ts);
+   do_realtime_coarse(ts);
+   break;
case CLOCK_MONOTONIC_COARSE:
-   return do_monotonic_coarse(ts);
+   do_monotonic_coarse(ts);
+   break;
+   default:
+   goto fallback;
}
 
-   if (ret == VCLOCK_NONE)
-   return vdso_fallback_gettime(clock, ts);
return 0;
+fallback:
+   return vdso_fallback_gettime(clock, ts);
 }
 int clock_gettime(clockid_t, struct timespec *)
__attribute__((weak, alias(__vdso_clock_gettime)));
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso: Introduce VVAR marco for vdso32

[tip-bot for Stefani Seibold]

Commit-ID:  ef721987aef0cc0abba08c88810f2155f76b0b1f
Gitweb: http://git.kernel.org/tip/ef721987aef0cc0abba08c88810f2155f76b0b1f
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon, 17 Mar 2014 23:22:07 +0100
Committer:  H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Mar 2014 12:52:29 -0700

x86, vdso: Introduce VVAR marco for vdso32

This patch revamps the vvar.h for introduce the VVAR macro for vdso32.

Reviewed-by: Andy Lutomirski l...@amacapital.net
Signed-off-by: Stefani Seibold stef...@seibold.net
Link: 
http://lkml.kernel.org/r/1395094933-14252-8-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
 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..52c79ff 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -26,6 +26,15 @@
 
 #else
 
+#ifdef BUILD_VDSO32
+
+#define DECLARE_VVAR(offset, type, name)   \
+   extern type vvar_ ## name __attribute__((visibility(hidden)));
+
+#define VVAR(name) (vvar_ ## name)
+
+#else
+
 extern char __vvar_page;
 
 /* Base address of vvars.  This is not ABI. */
@@ -39,12 +48,13 @@ extern char __vvar_page;
static type const * const vvaraddr_ ## name =   \
(void *)(VVAR_ADDRESS + (offset));
 
+#define VVAR(name) (*vvaraddr_ ## name)
+#endif
+
 #define DEFINE_VVAR(type, name)
\
type name   \
__attribute__((section(.vvar_ #name), aligned(16))) __visible
 
-#define VVAR(name) (*vvaraddr_ ## name)
-
 #endif
 
 /* DECLARE_VVAR(offset, type, name) */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v23 10/13] x86, vdso: Add 32 bit VDSO time support for 64 bit kernel

[Stefani Seibold]

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 for optimal performance.

The vsyscall_gtod_data struture must be a rearranged to serve 32- and
64-bit code access at the same time:

- The seqcount_t was replaced by an unsigned, this makes the
  vsyscall_gtod_data intedepend of kernel configuration and internal functions.
- All kernel internal structures are replaced by fix size elements
  which works for 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/asm/vvar.h   |  5 ++
 arch/x86/kernel/vsyscall_gtod.c   | 34 -
 arch/x86/vdso/vclock_gettime.c| 91 +++
 arch/x86/vdso/vdso32/vclock_gettime.c | 21 
 5 files changed, 155 insertions(+), 67 deletions(-)

diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index 46e24d3..3c3366c 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -1,30 +1,73 @@
 #ifndef _ASM_X86_VGTOD_H
 #define _ASM_X86_VGTOD_H
 
-#include 
+#include 
 #include 
 
+#ifdef BUILD_VDSO32_64
+typedef u64 gtod_long_t;
+#else
+typedef unsigned long gtod_long_t;
+#endif
+/*
+ * vsyscall_gtod_data will be accessed by 32 and 64 bit code at the same time
+ * so be carefull by modifying this structure.
+ */
 struct vsyscall_gtod_data {
-   seqcount_t  seq;
+   unsigned seq;
 
-   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;
u64 wall_time_snsec;
+   gtod_long_t wall_time_sec;
+   gtod_long_t monotonic_time_sec;
u64 monotonic_time_snsec;
-   time_t  monotonic_time_sec;
+   gtod_long_t wall_time_coarse_sec;
+   gtod_long_t wall_time_coarse_nsec;
+   gtod_long_t monotonic_time_coarse_sec;
+   gtod_long_t monotonic_time_coarse_nsec;
 
-   struct timezone sys_tz;
-   struct timespec wall_time_coarse;
-   struct timespec monotonic_time_coarse;
+   int tz_minuteswest;
+   int tz_dsttime;
 };
 extern struct vsyscall_gtod_data vsyscall_gtod_data;
 
+static inline unsigned gtod_read_begin(const struct vsyscall_gtod_data *s)
+{
+   unsigned ret;
+
+repeat:
+   ret = ACCESS_ONCE(s->seq);
+   if (unlikely(ret & 1)) {
+   cpu_relax();
+   goto repeat;
+   }
+   smp_rmb();
+   return ret;
+}
+
+static inline int gtod_read_retry(const struct vsyscall_gtod_data *s,
+   unsigned start)
+{
+   smp_rmb();
+   return unlikely(s->seq != start);
+}
+
+static inline void gtod_write_begin(struct vsyscall_gtod_data *s)
+{
+   ++s->seq;
+   smp_wmb();
+}
+
+static inline void gtod_write_end(struct vsyscall_gtod_data *s)
+{
+   smp_wmb();
+   ++s->seq;
+}
+
 #endif /* _ASM_X86_VGTOD_H */
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index 52c79ff..081d909 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -16,6 +16,9 @@
  * you mess up, the linker will catch it.)
  */
 
+#ifndef _ASM_X86_VVAR_H
+#define _ASM_X86_VVAR_H
+
 #if defined(__VVAR_KERNEL_LDS)
 
 /* The kernel linker script defines its own magic to put vvars in the
@@ -64,3 +67,5 @@ DECLARE_VVAR(16, int, vgetcpu_mode)
 DECLARE_VVAR(128, struct vsyscall_gtod_data, vsyscall_gtod_data)
 
 #undef DECLARE_VVAR
+
+#endif
diff --git a/arch/x86/kernel/vsyscall_gtod.c b/arch/x86/kernel/vsyscall_gtod.c
index b5a943d..f9c6e56 100644
--- a/arch/x86/kernel/vsyscall_gtod.c
+++ b/arch/x86/kernel/vsyscall_gtod.c
@@ -4,6 +4,7 @@
  *
  *  Modified for x86 32 bit architecture by
  *  Stefani Seibold 
+ *  sponsored by Rohde & Schwarz GmbH & Co. KG Munich/Germany
  *
  *  Thanks to h...@transmeta.com for some useful hint.
  *  Special thanks to Ingo Molnar for his early experience with
@@ -13,26 +14,28 @@
 
 #include 
 #include 
+#include 
 
 DEFINE_VVAR(struct vsyscall_gtod_data, vsyscall_gtod_data);
 
 void update_vsyscall_tz(void)
 {
-   vsyscall_gtod_data.sys_tz = sys_tz;
+   vsyscall_gtod_data.tz_minuteswest = sys_tz.tz_minuteswest;
+   vsyscall_gtod_data.tz_dsttime = sys_tz.tz_dsttime;
 }
 
 void upd

[PATCH v23 12/13] x86, vdso32: Disable stack protector, adjust optimizations

[Stefani Seibold]

From: "H. Peter Anvin" 

For the 32-bit VDSO, match the 64-bit VDSO in:

1. Disable the stack protector.
2. Use -fno-omit-frame-pointer for user space debugging sanity.
3. Use -foptimize-sibling-calls like the 64-bit VDSO does.

Reported-by: Ingo Molnar 
Signed-off-by: Stefani Seibold 
---
 arch/x86/vdso/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 6cef7a1..55e76eb 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -151,6 +151,9 @@ KBUILD_CFLAGS_32 := $(filter-out 
-mcmodel=kernel,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
+KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector) 
+KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
+KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
 $(vdso32-images:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
 
 $(vdso32-images:%=$(obj)/%.dbg): $(obj)/vdso32-%.so.dbg: FORCE \
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v23 11/13] x86, vdso: Zero-pad the VVAR page

[Stefani Seibold]

From: Andy Lutomirski 

By coincidence, the VVAR page is at the end of an ELF segment.  As a
result, if it ends up being a partial page, the kernel loader will
leave garbage behind at the end of the vvar page.  Zero-pad it to a
full page to fix this issue.

This has probably been broken since the VVAR page was introduced.
On QEMU, if you dump the run-time contents of the VVAR page, you can
find entertaining strings from seabios left behind.

It's remotely possible that this is a security bug -- conceivably
there's some BIOS out there that leaves something sensitive in the
few K 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
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -164,6 +164,11 @@ SECTIONS
 #undef __VVAR_KERNEL_LDS
 #undef EMIT_VVAR
 
+   /*
+* Pad the rest of the page with zeros.  Otherwise the loader
+* can leave garbage here.
+*/
+   . = __vvar_beginning_hack + PAGE_SIZE;
} :data
 
. = ALIGN(__vvar_page + PAGE_SIZE, PAGE_SIZE);
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v23 13/13] x86, vdso32: handle 32 bit vDSO larger one page

[Stefani Seibold]

This patch enables 32 bit vDSO which are larger than a page.

Signed-off-by: Stefani Seibold 
---
 arch/x86/vdso/vdso32-setup.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index e10abdf..0bc363a 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -69,7 +70,8 @@ __setup_param("vdso=", vdso32_setup, vdso_setup, 0);
 EXPORT_SYMBOL_GPL(vdso_enabled);
 #endif
 
-static struct page *vdso32_pages[1];
+static struct page **vdso32_pages;
+static unsigned int vdso32_size;
 
 #ifdef CONFIG_X86_64
 
@@ -115,11 +117,10 @@ void enable_sep_cpu(void)
 
 int __init sysenter_setup(void)
 {
-   void *vdso_page = (void *)get_zeroed_page(GFP_ATOMIC);
+   void *vdso_pages;
const void *vdso;
size_t vdso_len;
-
-   vdso32_pages[0] = virt_to_page(vdso_page);
+   unsigned int i;
 
if (vdso32_syscall()) {
vdso = _syscall_start;
@@ -132,8 +133,15 @@ int __init sysenter_setup(void)
vdso_len = _int80_end - _int80_start;
}
 
-   memcpy(vdso_page, vdso, vdso_len);
-   patch_vdso32(vdso_page, vdso_len);
+   vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
+   vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, 
GFP_ATOMIC); 
+   vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC);
+
+   for(i = 0; i != vdso32_size; ++i)
+   vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));
+
+   memcpy(vdso_pages, vdso, vdso_len);
+   patch_vdso32(vdso_pages, vdso_len);
 
return 0;
 }
@@ -169,7 +177,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
 */
ret = install_special_mapping(mm,
addr,
-   VDSO_OFFSET(VDSO_PAGES - VDSO_PREV_PAGES),
+   VDSO_OFFSET(vdso32_size),
VM_READ|VM_EXEC|
VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
vdso32_pages);
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v23 01/13] x86, vdso: Make vsyscall_gtod_data handling x86 generic

[Stefani Seibold]

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 
---
 arch/x86/Kconfig   |  4 +--
 arch/x86/include/asm/clocksource.h |  4 ---
 arch/x86/include/asm/vvar.h| 12 ++--
 arch/x86/kernel/Makefile   |  2 +-
 arch/x86/kernel/hpet.c |  2 --
 arch/x86/kernel/tsc.c  |  2 --
 arch/x86/kernel/vmlinux.lds.S  |  3 --
 arch/x86/kernel/vsyscall_64.c  | 45 -
 arch/x86/kernel/vsyscall_gtod.c| 59 ++
 arch/x86/tools/relocs.c|  2 +-
 10 files changed, 72 insertions(+), 63 deletions(-)
 create mode 100644 arch/x86/kernel/vsyscall_gtod.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9122f6b..ab3ebc8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -107,9 +107,9 @@ config X86
select HAVE_ARCH_SOFT_DIRTY
select CLOCKSOURCE_WATCHDOG
select GENERIC_CLOCKEVENTS
-   select ARCH_CLOCKSOURCE_DATA if X86_64
+   select ARCH_CLOCKSOURCE_DATA
select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && 
X86_LOCAL_APIC)
-   select GENERIC_TIME_VSYSCALL if X86_64
+   select GENERIC_TIME_VSYSCALL
select KTIME_SCALAR if X86_32
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/x86/include/asm/clocksource.h 
b/arch/x86/include/asm/clocksource.h
index 16a57f4..eda81dc 100644
--- a/arch/x86/include/asm/clocksource.h
+++ b/arch/x86/include/asm/clocksource.h
@@ -3,8 +3,6 @@
 #ifndef _ASM_X86_CLOCKSOURCE_H
 #define _ASM_X86_CLOCKSOURCE_H
 
-#ifdef CONFIG_X86_64
-
 #define VCLOCK_NONE 0  /* No vDSO clock available. */
 #define VCLOCK_TSC  1  /* vDSO should use vread_tsc.   */
 #define VCLOCK_HPET 2  /* vDSO should use vread_hpet.  */
@@ -14,6 +12,4 @@ struct arch_clocksource_data {
int vclock_mode;
 };
 
-#endif /* CONFIG_X86_64 */
-
 #endif /* _ASM_X86_CLOCKSOURCE_H */
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index d76ac40..0a534ea 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -16,9 +16,6 @@
  * you mess up, the linker will catch it.)
  */
 
-/* Base address of vvars.  This is not ABI. */
-#define VVAR_ADDRESS (-10*1024*1024 - 4096)
-
 #if defined(__VVAR_KERNEL_LDS)
 
 /* The kernel linker script defines its own magic to put vvars in the
@@ -29,6 +26,15 @@
 
 #else
 
+extern char __vvar_page;
+
+/* Base address of vvars.  This is not ABI. */
+#ifdef CONFIG_X86_64
+#define VVAR_ADDRESS (-10*1024*1024 - 4096)
+#else
+#define VVAR_ADDRESS (&__vvar_page)
+#endif
+
 #define DECLARE_VVAR(offset, type, name)   \
static type const * const vvaraddr_ ## name =   \
(void *)(VVAR_ADDRESS + (offset));
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index cb648c8..f4d9600 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y  += probe_roms.o
 obj-$(CONFIG_X86_32)   += i386_ksyms_32.o
 obj-$(CONFIG_X86_64)   += sys_x86_64.o x8664_ksyms_64.o
-obj-y  += syscall_$(BITS).o
+obj-y  += syscall_$(BITS).o vsyscall_gtod.o
 obj-$(CONFIG_X86_64)   += vsyscall_64.o
 obj-$(CONFIG_X86_64)   += vsyscall_emu_64.o
 obj-$(CONFIG_SYSFS)+= ksysfs.o
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index da85a8e..e4b86ab 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -752,9 +752,7 @@ static struct clocksource clocksource_hpet = {
.mask   = HPET_MASK,
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
.resume = hpet_resume_counter,
-#ifdef CONFIG_X86_64
.archdata   = { .vclock_mode = VCLOCK_HPET },
-#endif
 };
 
 static int hpet_clocksource_register(void)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfbe99f..227dcfc 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -985,9 +985,7 @@ static struct clocksource clocksource_tsc = {
.mask   = CLOCKSOURCE_MASK(64),
.flags  = CLOCK_SOURCE_IS_CONTINUOUS |
  CLOCK_SOURCE_MUST_VERIFY,
-#ifdef CONFIG_X86_64
.archdata   = { .vclock_mode = VCLOCK_TSC },
-#endif
 };
 
 void mark_tsc_unstable(char *reason)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index da6b35a..1d4897b 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -147,7 +147,6 @@ SECTIONS
_edata = .;
} :data
 
-#ifdef CONFIG_X86_64
 
. = ALIGN(PAGE_SIZE);
__vvar_page = .;
@@ -169,8 +168,6

[PATCH v23 03/13] x86, vdso: Revamp vclock_gettime.c

[Stefani Seibold]

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 file changed, 42 insertions(+), 43 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index eb5d7a5..bbc8065 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -26,41 +26,26 @@
 
 #define gtod ((vsyscall_gtod_data))
 
-notrace static cycle_t vread_tsc(void)
+static notrace cycle_t vread_hpet(void)
 {
-   cycle_t ret;
-   u64 last;
-
-   /*
-* Empirically, a fence (of type that depends on the CPU)
-* before rdtsc is enough to ensure that rdtsc is ordered
-* with respect to loads.  The various CPU manuals are unclear
-* as to whether rdtsc can be reordered with later loads,
-* but no one has ever seen it happen.
-*/
-   rdtsc_barrier();
-   ret = (cycle_t)vget_cycles();
-
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
-
-   if (likely(ret >= last))
-   return ret;
+   return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
+}
 
-   /*
-* GCC likes to generate cmov here, but this branch is extremely
-* predictable (it's just a funciton of time and the likely is
-* very likely) and there's a data dependence, so force GCC
-* to generate a branch instead.  I don't barrier() because
-* we don't actually need a barrier, and if this function
-* ever gets inlined it will generate worse code.
-*/
-   asm volatile ("");
-   return last;
+notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+{
+   long ret;
+   asm("syscall" : "=a" (ret) :
+   "0" (__NR_clock_gettime), "D" (clock), "S" (ts) : "memory");
+   return ret;
 }
 
-static notrace cycle_t vread_hpet(void)
+notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
 {
-   return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
+   long ret;
+
+   asm("syscall" : "=a" (ret) :
+   "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
+   return ret;
 }
 
 #ifdef CONFIG_PARAVIRT_CLOCK
@@ -133,23 +118,37 @@ static notrace cycle_t vread_pvclock(int *mode)
 }
 #endif
 
-notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+notrace static cycle_t vread_tsc(void)
 {
-   long ret;
-   asm("syscall" : "=a" (ret) :
-   "0" (__NR_clock_gettime),"D" (clock), "S" (ts) : "memory");
-   return ret;
-}
+   cycle_t ret;
+   u64 last;
 
-notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
-{
-   long ret;
+   /*
+* Empirically, a fence (of type that depends on the CPU)
+* before rdtsc is enough to ensure that rdtsc is ordered
+* with respect to loads.  The various CPU manuals are unclear
+* as to whether rdtsc can be reordered with later loads,
+* but no one has ever seen it happen.
+*/
+   rdtsc_barrier();
+   ret = (cycle_t)vget_cycles();
 
-   asm("syscall" : "=a" (ret) :
-   "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
-   return ret;
-}
+   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
 
+   if (likely(ret >= last))
+   return ret;
+
+   /*
+* GCC likes to generate cmov here, but this branch is extremely
+* predictable (it's just a funciton of time and the likely is
+* very likely) and there's a data dependence, so force GCC
+* to generate a branch instead.  I don't barrier() because
+* we don't actually need a barrier, and if this function
+* ever gets inlined it will generate worse code.
+*/
+   asm volatile ("");
+   return last;
+}
 
 notrace static inline u64 vgetsns(int *mode)
 {
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v23 04/13] x86, vdso: __vdso_clock_gettime() cleanup

[Stefani Seibold]

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 Seibold 
---
 arch/x86/vdso/vclock_gettime.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index bbc8065..fd074dd 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -209,7 +209,7 @@ notrace static int do_monotonic(struct timespec *ts)
return mode;
 }
 
-notrace static int do_realtime_coarse(struct timespec *ts)
+notrace static void do_realtime_coarse(struct timespec *ts)
 {
unsigned long seq;
do {
@@ -217,10 +217,9 @@ notrace static int do_realtime_coarse(struct timespec *ts)
ts->tv_sec = gtod->wall_time_coarse.tv_sec;
ts->tv_nsec = gtod->wall_time_coarse.tv_nsec;
} while (unlikely(read_seqcount_retry(>seq, seq)));
-   return 0;
 }
 
-notrace static int do_monotonic_coarse(struct timespec *ts)
+notrace static void do_monotonic_coarse(struct timespec *ts)
 {
unsigned long seq;
do {
@@ -228,30 +227,32 @@ notrace static int do_monotonic_coarse(struct timespec 
*ts)
ts->tv_sec = gtod->monotonic_time_coarse.tv_sec;
ts->tv_nsec = gtod->monotonic_time_coarse.tv_nsec;
} while (unlikely(read_seqcount_retry(>seq, seq)));
-
-   return 0;
 }
 
 notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
 {
-   int ret = VCLOCK_NONE;
-
switch (clock) {
case CLOCK_REALTIME:
-   ret = do_realtime(ts);
+   if (do_realtime(ts) == VCLOCK_NONE)
+   goto fallback;
break;
case CLOCK_MONOTONIC:
-   ret = do_monotonic(ts);
+   if (do_monotonic(ts) == VCLOCK_NONE)
+   goto fallback;
break;
case CLOCK_REALTIME_COARSE:
-   return do_realtime_coarse(ts);
+   do_realtime_coarse(ts);
+   break;
case CLOCK_MONOTONIC_COARSE:
-   return do_monotonic_coarse(ts);
+   do_monotonic_coarse(ts);
+   break;
+   default:
+   goto fallback;
}
 
-   if (ret == VCLOCK_NONE)
-   return vdso_fallback_gettime(clock, ts);
return 0;
+fallback:
+   return vdso_fallback_gettime(clock, ts);
 }
 int clock_gettime(clockid_t, struct timespec *)
__attribute__((weak, alias("__vdso_clock_gettime")));
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v23 09/13] x86, vdso: Add 32 bit VDSO time support for 32 bit kernel

[Stefani Seibold]

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   |  5 +++
 arch/x86/include/asm/vdso32.h | 11 +
 arch/x86/vdso/Makefile|  8 
 arch/x86/vdso/vclock_gettime.c| 76 +++
 arch/x86/vdso/vdso-layout.lds.S   | 22 ++
 arch/x86/vdso/vdso32-setup.c  | 47 --
 arch/x86/vdso/vdso32/vclock_gettime.c |  9 +
 arch/x86/vdso/vdso32/vdso32.lds.S | 11 +
 8 files changed, 178 insertions(+), 11 deletions(-)
 create mode 100644 arch/x86/include/asm/vdso32.h
 create mode 100644 arch/x86/vdso/vdso32/vclock_gettime.c

diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index f8605e6..bde4359 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -2,6 +2,11 @@
 #define _ASM_X86_VDSO_H
 
 #if defined CONFIG_X86_32 || defined CONFIG_COMPAT
+
+#include 
+
+extern const char VDSO32_PRELINK[];
+
 /*
  * Given a pointer to the vDSO image, find the pointer to VDSO32_name
  * as that symbol is defined in the vDSO sources or linker script.
diff --git a/arch/x86/include/asm/vdso32.h b/arch/x86/include/asm/vdso32.h
new file mode 100644
index 000..7efb701
--- /dev/null
+++ b/arch/x86/include/asm/vdso32.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_X86_VDSO32_H
+#define _ASM_X86_VDSO32_H
+
+#define VDSO_BASE_PAGE 0
+#define VDSO_VVAR_PAGE 1
+#define VDSO_HPET_PAGE 2
+#define VDSO_PAGES 3
+#define VDSO_PREV_PAGES2
+#define VDSO_OFFSET(x) ((x) * PAGE_SIZE)
+
+#endif
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 7a3d13e..6cef7a1 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -146,8 +146,16 @@ KBUILD_AFLAGS_32 := $(filter-out -m64,$(KBUILD_AFLAGS))
 $(vdso32-images:%=$(obj)/%.dbg): KBUILD_AFLAGS = $(KBUILD_AFLAGS_32)
 $(vdso32-images:%=$(obj)/%.dbg): asflags-$(CONFIG_X86_64) += -m32
 
+KBUILD_CFLAGS_32 := $(filter-out -m64,$(KBUILD_CFLAGS))
+KBUILD_CFLAGS_32 := $(filter-out -mcmodel=kernel,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
+$(vdso32-images:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
+
 $(vdso32-images:%=$(obj)/%.dbg): $(obj)/vdso32-%.so.dbg: FORCE \
 $(obj)/vdso32/vdso32.lds \
+$(obj)/vdso32/vclock_gettime.o \
 $(obj)/vdso32/note.o \
 $(obj)/vdso32/%.o
$(call if_changed,vdso)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 09dae4a..90bb5e8 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -4,6 +4,9 @@
  *
  * Fast user context implementation of clock_gettime, gettimeofday, and time.
  *
+ * 32 Bit compat layer by Stefani Seibold 
+ *  sponsored by Rohde & Schwarz GmbH & Co. KG Munich/Germany
+ *
  * The code should have no internal unresolved relocations.
  * Check with readelf after changing.
  */
@@ -12,13 +15,11 @@
 #define DISABLE_BRANCH_PROFILING
 
 #include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,12 @@
 
 #define gtod ((vsyscall_gtod_data))
 
+extern int __vdso_clock_gettime(clockid_t clock, struct timespec *ts);
+extern int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz);
+extern time_t __vdso_time(time_t *t);
+
+#ifndef BUILD_VDSO32
+
 static notrace cycle_t vread_hpet(void)
 {
return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 
HPET_COUNTER);
@@ -118,6 +125,59 @@ static notrace cycle_t vread_pvclock(int *mode)
 }
 #endif
 
+#else
+
+extern u8 hpet_page
+   __attribute__((visibility("hidden")));
+
+#ifdef CONFIG_HPET_TIMER
+static notrace cycle_t vread_hpet(void)
+{
+   return readl((const void __iomem *)(_page + HPET_COUNTER));
+}
+#endif
+
+notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
+{
+   long ret;
+
+   asm(
+   "mov %%ebx, %%edx \n"
+   "mov %2, %%ebx \n"
+   "call VDSO32_vsyscall \n"
+   "mov %%edx, %%ebx \n"
+   : "=a" (ret)
+   : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
+   : "memory", "edx");
+   return ret;
+}
+
+notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
+{
+   long ret;
+
+   asm(
+   "mov %%ebx, %%edx \n"
+   "mov %2, %%ebx 

[PATCH v23 08/13] x86, vdso: Patch alternatives in the 32-bit VDSO

[Stefani Seibold]

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 ++---
 4 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index 5594e84..f8605e6 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -28,4 +28,6 @@ extern const char vdso32_int80_start, vdso32_int80_end;
 extern const char vdso32_syscall_start, vdso32_syscall_end;
 extern const char vdso32_sysenter_start, vdso32_sysenter_end;
 
+void __init patch_vdso32(void *vdso, size_t len);
+
 #endif /* _ASM_X86_VDSO_H */
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index fd14be1..7a3d13e 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -21,7 +21,8 @@ vobjs-$(VDSOX32-y) += $(vobjx32s-compat)
 vobj64s := $(filter-out $(vobjx32s-compat),$(vobjs-y))
 
 # files to link into kernel
-obj-$(VDSO64-y)+= vma.o vdso.o
+obj-y  += vma.o
+obj-$(VDSO64-y)+= vdso.o
 obj-$(VDSOX32-y)   += vdsox32.o
 obj-$(VDSO32-y)+= vdso32.o vdso32-setup.o
 
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index ab20c04..e0fc767 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -112,24 +112,25 @@ void enable_sep_cpu(void)
 
 int __init sysenter_setup(void)
 {
-   void *syscall_page = (void *)get_zeroed_page(GFP_ATOMIC);
-   const void *vsyscall;
-   size_t vsyscall_len;
+   void *vdso_page = (void *)get_zeroed_page(GFP_ATOMIC);
+   const void *vdso;
+   size_t vdso_len;
 
-   vdso32_pages[0] = virt_to_page(syscall_page);
+   vdso32_pages[0] = virt_to_page(vdso_page);
 
if (vdso32_syscall()) {
-   vsyscall = _syscall_start;
-   vsyscall_len = _syscall_end - _syscall_start;
+   vdso = _syscall_start;
+   vdso_len = _syscall_end - _syscall_start;
} else if (vdso32_sysenter()){
-   vsyscall = _sysenter_start;
-   vsyscall_len = _sysenter_end - _sysenter_start;
+   vdso = _sysenter_start;
+   vdso_len = _sysenter_end - _sysenter_start;
} else {
-   vsyscall = _int80_start;
-   vsyscall_len = _int80_end - _int80_start;
+   vdso = _int80_start;
+   vdso_len = _int80_end - _int80_start;
}
 
-   memcpy(syscall_page, vsyscall, vsyscall_len);
+   memcpy(vdso_page, vdso, vdso_len);
+   patch_vdso32(vdso_page, vdso_len);
 
return 0;
 }
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 431e875..7345bc9 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 
+#if defined(CONFIG_X86_64)
 unsigned int __read_mostly vdso_enabled = 1;
 
 extern char vdso_start[], vdso_end[];
@@ -28,8 +29,12 @@ static unsigned vdso_size;
 extern char vdsox32_start[], vdsox32_end[];
 extern struct page *vdsox32_pages[];
 static unsigned vdsox32_size;
+#endif
+#endif
 
-static void __init patch_vdsox32(void *vdso, size_t len)
+#if defined(CONFIG_X86_32) || defined(CONFIG_X86_X32_ABI) || \
+   defined(CONFIG_COMPAT)
+void __init patch_vdso32(void *vdso, size_t len)
 {
Elf32_Ehdr *hdr = vdso;
Elf32_Shdr *sechdrs, *alt_sec = 0;
@@ -52,7 +57,7 @@ static void __init patch_vdsox32(void *vdso, size_t len)
}
 
/* If we get here, it's probably a bug. */
-   pr_warning("patch_vdsox32: .altinstructions not found\n");
+   pr_warning("patch_vdso32: .altinstructions not found\n");
return;  /* nothing to patch */
 
 found:
@@ -61,6 +66,7 @@ found:
 }
 #endif
 
+#if defined(CONFIG_X86_64)
 static void __init patch_vdso64(void *vdso, size_t len)
 {
Elf64_Ehdr *hdr = vdso;
@@ -104,7 +110,7 @@ static int __init init_vdso(void)
vdso_pages[i] = virt_to_page(vdso_start + i*PAGE_SIZE);
 
 #ifdef CONFIG_X86_X32_ABI
-   patch_vdsox32(vdsox32_start, vdsox32_end - vdsox32_start);
+   patch_vdso32(vdsox32_start, vdsox32_end - vdsox32_start);
npages = (vdsox32_end - vdsox32_start + PAGE_SIZE - 1) / PAGE_SIZE;
vdsox32_size = npages << PAGE_SHIFT;
for (i = 0; i < npages; i++)
@@ -204,3 +210,4 @@ static __init int vdso_setup(char *s)
return 0;
 }
 __setup("vdso=", vdso_setup);
+#endif
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v23 05/13] x86, vdso: Replace VVAR(vsyscall_gtod_data) by gtod macro

[Stefani Seibold]

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/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index fd074dd..743f277 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -109,7 +109,7 @@ static notrace cycle_t vread_pvclock(int *mode)
*mode = VCLOCK_NONE;
 
/* refer to tsc.c read_tsc() comment for rationale */
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
+   last = gtod->clock.cycle_last;
 
if (likely(ret >= last))
return ret;
@@ -133,7 +133,7 @@ notrace static cycle_t vread_tsc(void)
rdtsc_barrier();
ret = (cycle_t)vget_cycles();
 
-   last = VVAR(vsyscall_gtod_data).clock.cycle_last;
+   last = gtod->clock.cycle_last;
 
if (likely(ret >= last))
return ret;
@@ -288,7 +288,7 @@ int gettimeofday(struct timeval *, struct timezone *)
 notrace time_t __vdso_time(time_t *t)
 {
/* This is atomic on x86_64 so we don't need any locks. */
-   time_t result = ACCESS_ONCE(VVAR(vsyscall_gtod_data).wall_time_sec);
+   time_t result = ACCESS_ONCE(gtod->wall_time_sec);
 
if (t)
*t = result;
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/