Re: Is read barrier missed in kfifo?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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)
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
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
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
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
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
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
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()
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()
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()
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!
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!
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()
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/