Re: [PATCH v3 2/4] x86/mmx: Use KFPU_387 for MMX string operations

ioned bit > is clear. > > Fix it by using kernel_fpu_begin_mask(KFPU_387) explicitly. > > Fixes: 7ad816762f9b ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()") > Cc: > Reported-by: Krzysztof Mazur > Signed-off-by: Andy Lutomirski > --- > arch/x86

Re: [PATCH] x86/lib: don't use MMX before FPU initialization

On Thu, Jan 14, 2021 at 08:31:30AM -0800, Andy Lutomirski wrote: > This is gross. I realize this is only used for old CPUs that we don't > care about perf-wise Performance might be still important for embedded systems (Geode LX seems to be supported "until at least 2021"). > , but this code is

Re: [PATCH] x86/lib: don't use MMX before FPU initialization

On Thu, Jan 14, 2021 at 03:07:37PM +0100, Borislav Petkov wrote: > On Thu, Jan 14, 2021 at 01:36:57PM +0100, Krzysztof Mazur wrote: > > The OSFXSR must be set only on CPUs with SSE. There > > are some CPUs with 3DNow!, but without SSE and FXSR (like AMD > > Geode LX, which

Re: [PATCH] x86/lib: don't use MMX before FPU initialization

MD K7, which supports both MMX 3DNow! and SSE). Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Signed-off-by: Krzysztof Mazur --- arch/x86/lib/mmx_32.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/x86/lib/mmx_32.c

Re: [PATCH] x86/lib: don't use MMX before FPU initialization

On Tue, Jan 12, 2021 at 01:09:23AM +0100, Borislav Petkov wrote: > On Mon, Dec 28, 2020 at 05:06:31PM +0100, Krzysztof Mazur wrote: > > When enabled, the MMX 3DNow! optimized memcpy() is used very early, > > even before FPU is initialized. It worked f

[PATCH] x86/lib: don't use MMX before FPU initialization

r "Booting the kernel." message. It affects all kernels with CONFIG_X86_USE_3DNOW=y (enabled when some AMD/Cyrix processors are selected). So, enable MMX 3DNow! optimized memcpy() later. Cc: # 5.8+ Signed-off-by: Krzysztof Mazur --- Hi, this patch fixes a kernel crash during boot obser

Re: [PATCH] ssb: Reenable PCI host on !MIPS

On Sat, Jan 27, 2018 at 06:29:18AM +0200, Kalle Valo wrote: > Krzysztof Mazur <krzys...@podlesie.net> writes: > > > The commit 58eae1416b804d900014d84feadda7195007cc30 > > ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled > > CONFIG_SSB_PCIH

Re: [PATCH] ssb: Reenable PCI host on !MIPS

On Sat, Jan 27, 2018 at 06:29:18AM +0200, Kalle Valo wrote: > Krzysztof Mazur writes: > > > The commit 58eae1416b804d900014d84feadda7195007cc30 > > ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled > > CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRID

[PATCH] ssb: Reenable PCI host on !MIPS

PS defines that config option). Reenable it. Signed-off-by: Krzysztof Mazur <krzys...@podlesie.net> --- drivers/ssb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig index 71c73766ee22..3dc57414e06b 100644 --- a/drivers/ssb/Kconf

[PATCH] ssb: Reenable PCI host on !MIPS

PS defines that config option). Reenable it. Signed-off-by: Krzysztof Mazur --- drivers/ssb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig index 71c73766ee22..3dc57414e06b 100644 --- a/drivers/ssb/Kconfig +++ b/drivers/ssb/Kconfi

Re: [RFC PATCH 00/16] PTI support for x86-32

On Thu, Jan 25, 2018 at 02:09:40PM -0800, Nadav Amit wrote: > The PoC apparently does not work with 3GB of memory or more on 32-bit. Does > you setup has more? Can you try the attack while setting max_addr=1G ? No, I tested on: Pentium M (Dothan): 1.5 GB RAM, PAE for NX, 2GB/2GB split

Re: [RFC PATCH 00/16] PTI support for x86-32

On Thu, Jan 25, 2018 at 02:09:40PM -0800, Nadav Amit wrote: > The PoC apparently does not work with 3GB of memory or more on 32-bit. Does > you setup has more? Can you try the attack while setting max_addr=1G ? No, I tested on: Pentium M (Dothan): 1.5 GB RAM, PAE for NX, 2GB/2GB split

Re: [RFC PATCH 00/16] PTI support for x86-32

On Tue, Jan 16, 2018 at 05:36:43PM +0100, Joerg Roedel wrote: > From: Joerg Roedel > > Hi, > > here is my current WIP code to enable PTI on x86-32. It is > still in a pretty early state, but it successfully boots my > KVM guest with PAE and with legacy paging. The existing PTI

Re: [RFC PATCH 00/16] PTI support for x86-32

On Tue, Jan 16, 2018 at 05:36:43PM +0100, Joerg Roedel wrote: > From: Joerg Roedel > > Hi, > > here is my current WIP code to enable PTI on x86-32. It is > still in a pretty early state, but it successfully boots my > KVM guest with PAE and with legacy paging. The existing PTI > code for x86-64

Re: [PATCH] um: use POSIX ucontext_t instead of struct ucontext

On Wed, Nov 15, 2017 at 12:15:00PM +0100, Richard Weinberger wrote: > Am Mittwoch, 15. November 2017, 12:04:16 CET schrieb Krzysztof Mazur: > > On Wed, Nov 15, 2017 at 11:19:41AM +0100, Richard Weinberger wrote: > > > Am Mittwoch, 15. November 2017, 11:12:39 CET schri

Re: [PATCH] um: use POSIX ucontext_t instead of struct ucontext

On Wed, Nov 15, 2017 at 12:15:00PM +0100, Richard Weinberger wrote: > Am Mittwoch, 15. November 2017, 12:04:16 CET schrieb Krzysztof Mazur: > > On Wed, Nov 15, 2017 at 11:19:41AM +0100, Richard Weinberger wrote: > > > Am Mittwoch, 15. November 2017, 11:12:39 CET schri

Re: [PATCH] um: use POSIX ucontext_t instead of struct ucontext

On Wed, Nov 15, 2017 at 11:19:41AM +0100, Richard Weinberger wrote: > Am Mittwoch, 15. November 2017, 11:12:39 CET schrieb Krzysztof Mazur: > > glibc 2.26 removed the 'struct ucontext' to "improve" POSIX compliance > > and break programs, including User Mode Linux. Fix Use

Re: [PATCH] um: use POSIX ucontext_t instead of struct ucontext

On Wed, Nov 15, 2017 at 11:19:41AM +0100, Richard Weinberger wrote: > Am Mittwoch, 15. November 2017, 11:12:39 CET schrieb Krzysztof Mazur: > > glibc 2.26 removed the 'struct ucontext' to "improve" POSIX compliance > > and break programs, including User Mode Linux. Fix Use

[PATCH] um: use POSIX ucontext_t instead of struct ucontext

ng pointer to incomplete type 'struct ucontext' mcontext_t *mc = >uc_mcontext; arch/x86/um/stub_segv.c: In function 'stub_segv_handler': arch/x86/um/stub_segv.c:16:13: error: dereferencing pointer to incomplete type 'struct ucontext' >uc_mcontext); Signed-off-by: Krzysz

[PATCH] um: use POSIX ucontext_t instead of struct ucontext

ng pointer to incomplete type 'struct ucontext' mcontext_t *mc = >uc_mcontext; arch/x86/um/stub_segv.c: In function 'stub_segv_handler': arch/x86/um/stub_segv.c:16:13: error: dereferencing pointer to incomplete type 'struct ucontext' >uc_mcontext); Signed-off-by: Krzysztof Mazur

[tip:x86/urgent] x86/setup: Fix low identity map for >= 2GB kernel range

Commit-ID: 68accac392d859d24adcf1be3a90e41f978bd54c Gitweb: http://git.kernel.org/tip/68accac392d859d24adcf1be3a90e41f978bd54c Author: Krzysztof Mazur AuthorDate: Fri, 6 Nov 2015 14:18:36 +0100 Committer: Thomas Gleixner CommitDate: Sat, 7 Nov 2015 10:39:40 +0100 x86/setup: Fix low

[tip:x86/urgent] x86/setup: Fix low identity map for >= 2GB kernel range

Commit-ID: 68accac392d859d24adcf1be3a90e41f978bd54c Gitweb: http://git.kernel.org/tip/68accac392d859d24adcf1be3a90e41f978bd54c Author: Krzysztof Mazur <krzys...@podlesie.net> AuthorDate: Fri, 6 Nov 2015 14:18:36 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate

Re: [PATCH] x86/setup: fix low identity map for >= 2GB kernel range

On Fri, Nov 06, 2015 at 02:27:33PM +0100, Borislav Petkov wrote: > On Fri, Nov 06, 2015 at 02:18:36PM +0100, Krzysztof Mazur wrote: > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index a3cccbf..37c8ea8 100644 > > --- a/arch/x86/kernel/setup.c >

[PATCH] x86/setup: fix low identity map for >= 2GB kernel range

identity mapping causing crash. To avoid overwritting, limit the low identity map to cover only memory before kernel range (PAGE_OFFSET). Signed-off-by: Krzysztof Mazur --- The bug can be also fixed by copying identity mapping before copying kernel address range, but this fix is smaller. It might

[PATCH] x86/setup: fix low identity map for >= 2GB kernel range

identity mapping causing crash. To avoid overwritting, limit the low identity map to cover only memory before kernel range (PAGE_OFFSET). Signed-off-by: Krzysztof Mazur <krzys...@podlesie.net> --- The bug can be also fixed by copying identity mapping before copying kernel address range, but th

Re: [PATCH] x86/setup: fix low identity map for >= 2GB kernel range

On Fri, Nov 06, 2015 at 02:27:33PM +0100, Borislav Petkov wrote: > On Fri, Nov 06, 2015 at 02:18:36PM +0100, Krzysztof Mazur wrote: > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index a3cccbf..37c8ea8 100644 > > --- a/arch/x86/kernel/setup.c >

i915: black screen after boot on 915GM (Linux >= 3.4-rc1)

Hi, The commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581 (drm/i915: Fix 915GM self-refresh enable/disable) causes strange regression on the HP Compaq nc6120. During and after boot to framebuffer console with just LVDS the screen is black (backlight on, but black). Starting a X server fixes the

i915: black screen after boot on 915GM (Linux = 3.4-rc1)

Hi, The commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581 (drm/i915: Fix 915GM self-refresh enable/disable) causes strange regression on the HP Compaq nc6120. During and after boot to framebuffer console with just LVDS the screen is black (backlight on, but black). Starting a X server fixes the

Re: [PATCH] DYNAMIC_DEBUG: use select DEBUG_FS instead of depends on

On Sun, Oct 27, 2013 at 07:38:08AM -0700, Randy Dunlap wrote: > On 10/27/13 01:01, Krzysztof Mazur wrote: > > On Sat, Oct 26, 2013 at 08:30:00PM -0700, Greg Kroah-Hartman wrote: > >> On Sat, Oct 26, 2013 at 10:58:13PM +0200, Krzysztof Mazur wrote: > >>> Depending

Re: [PATCH V2] printk: pr_debug_ratelimited: check state first to reduce "callbacks suppressed" messages

On Sat, Oct 26, 2013 at 08:41:53PM -0700, Joe Perches wrote: > pr_debug_ratelimited should be coded similarly to dev_dbg_ratelimited > to reduce the "callbacks suppressed" messages. > > Add #include to printk.h. Unfortunately, this > new #include must be after the prototype/declaration of

Re: [PATCH] DYNAMIC_DEBUG: use select DEBUG_FS instead of depends on

On Sat, Oct 26, 2013 at 08:30:00PM -0700, Greg Kroah-Hartman wrote: > On Sat, Oct 26, 2013 at 10:58:13PM +0200, Krzysztof Mazur wrote: > > Depending on options that are configured later makes them hard > > to enable unless the user knows that he must go backwards. > &g

Re: [PATCH] DYNAMIC_DEBUG: use select DEBUG_FS instead of depends on

On Sat, Oct 26, 2013 at 08:30:00PM -0700, Greg Kroah-Hartman wrote: On Sat, Oct 26, 2013 at 10:58:13PM +0200, Krzysztof Mazur wrote: Depending on options that are configured later makes them hard to enable unless the user knows that he must go backwards. Really? We've had this for well

Re: [PATCH V2] printk: pr_debug_ratelimited: check state first to reduce callbacks suppressed messages

On Sat, Oct 26, 2013 at 08:41:53PM -0700, Joe Perches wrote: pr_debug_ratelimited should be coded similarly to dev_dbg_ratelimited to reduce the callbacks suppressed messages. Add #include linux/dynamic_debug.h to printk.h. Unfortunately, this new #include must be after the

Re: [PATCH] DYNAMIC_DEBUG: use select DEBUG_FS instead of depends on

On Sun, Oct 27, 2013 at 07:38:08AM -0700, Randy Dunlap wrote: On 10/27/13 01:01, Krzysztof Mazur wrote: On Sat, Oct 26, 2013 at 08:30:00PM -0700, Greg Kroah-Hartman wrote: On Sat, Oct 26, 2013 at 10:58:13PM +0200, Krzysztof Mazur wrote: Depending on options that are configured later makes

[PATCH] DYNAMIC_DEBUG: use select DEBUG_FS instead of depends on

Depending on options that are configured later makes them hard to enable unless the user knows that he must go backwards. Signed-off-by: Krzysztof Mazur --- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 06344d9

Re: [PATCH] atmusb: Fix dynamic_debug macros

RGS" to "## arg", but without with "arg..." -> "..." it also compiles and runs correctly. I tested that only in my configuration - without DEBUG and DYNAMIC_DEBUG - and compile tested that it with DYNAMIC_DEBUG. If you like you can add: Tested-by: Krzysztof Mazur

usbatm: printk_ratelimit() always called in the atm_rldbg()

Hi, commit 2d6401cf4ca3861692a4779745e0049cac769d10 ("USB: usbatm: move the atm_dbg() call to use dynamic debug") changed the atm_rldbg() to: #define atm_rldbg(instance, format, arg...) \ if (printk_ratelimit()) \ atm_dbg(instance ,

usbatm: printk_ratelimit() always called in the atm_rldbg()

Hi, commit 2d6401cf4ca3861692a4779745e0049cac769d10 (USB: usbatm: move the atm_dbg() call to use dynamic debug) changed the atm_rldbg() to: #define atm_rldbg(instance, format, arg...) \ if (printk_ratelimit()) \ atm_dbg(instance ,

Re: [PATCH] atmusb: Fix dynamic_debug macros

and DYNAMIC_DEBUG - and compile tested that it with DYNAMIC_DEBUG. If you like you can add: Tested-by: Krzysztof Mazur krzys...@podlesie.net BTW: the driver is named usbatm, not atmusb. Thanks, Krzysiek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

[PATCH] DYNAMIC_DEBUG: use select DEBUG_FS instead of depends on

Depending on options that are configured later makes them hard to enable unless the user knows that he must go backwards. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- lib/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib

Re: [PATCH] init: fix in-place parameter modification regression

at least parsing "ubd" parameter in the ubd driver when the COW file is used. Now the separate buffer is used for per-initcall parameter parsing. Signed-off-by: Krzysztof Mazur --- init/main.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/init/main.c b/init/main

Re: [PATCH] init: fix in-place parameter modification regression

for per-initcall parameter parsing. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- init/main.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/init/main.c b/init/main.c index 63d3e8f..c093b5c 100644 --- a/init/main.c +++ b/init/main.c @@ -132,6 +132,8 @@ char

Re: [PATCH] init: fix in-place parameter modification regression

On Mon, Oct 14, 2013 at 12:34:02PM +0100, Pawel Moll wrote: > On Sat, 2013-10-12 at 19:05 +0100, Krzysztof Mazur wrote: > > Before commit 026cee0086fe1df4cf74691cf273062cc769617d > > ("params: _initcall-like kernel parameters") the __setup > > parameter pars

Re: [PATCH] init: fix in-place parameter modification regression

On Mon, Oct 14, 2013 at 06:06:23PM +1030, Rusty Russell wrote: > Krzysztof Mazur writes: > > Before commit 026cee0086fe1df4cf74691cf273062cc769617d > > ("params: _initcall-like kernel parameters") the __setup > > parameter parsing code could modify parameter in the

Re: [PATCH] init: fix in-place parameter modification regression

On Mon, Oct 14, 2013 at 06:06:23PM +1030, Rusty Russell wrote: Krzysztof Mazur krzys...@podlesie.net writes: Before commit 026cee0086fe1df4cf74691cf273062cc769617d (params: level_initcall-like kernel parameters) the __setup parameter parsing code could modify parameter

Re: [PATCH] init: fix in-place parameter modification regression

On Mon, Oct 14, 2013 at 12:34:02PM +0100, Pawel Moll wrote: On Sat, 2013-10-12 at 19:05 +0100, Krzysztof Mazur wrote: Before commit 026cee0086fe1df4cf74691cf273062cc769617d (params: level_initcall-like kernel parameters) the __setup parameter parsing code could modify parameter

[PATCH] ACPI: remove /proc/acpi/event from ACPI_BUTTON help

The commit 1696d9dc57e062ce5200f6a42a6aaada15b434bb ("ACPI: Remove the old /proc/acpi/event interface") removed the old /proc/acpi/event interface but did not remove /proc/acpi/event from ACPI_BUTTON help. Signed-off-by: Krzysztof Mazur --- drivers/acpi/Kconfig | 6 +++--- 1 file

[PATCH] init: fix in-place parameter modification regression

r-initcall parameter parsing, like in parsing early params. Signed-off-by: Krzysztof Mazur --- Hi, this patch fixes an old Linux 3.4 regression in ubd parameter parsing. It was previously reported by the David Fernández in the "ubd option parsing problem when using cow filesystems in kernel 3.4&q

[PATCH] init: fix in-place parameter modification regression

parsing, like in parsing early params. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- Hi, this patch fixes an old Linux 3.4 regression in ubd parameter parsing. It was previously reported by the David Fernández in the ubd option parsing problem when using cow filesystems in kernel 3.4 thread

[PATCH] ACPI: remove /proc/acpi/event from ACPI_BUTTON help

The commit 1696d9dc57e062ce5200f6a42a6aaada15b434bb (ACPI: Remove the old /proc/acpi/event interface) removed the old /proc/acpi/event interface but did not remove /proc/acpi/event from ACPI_BUTTON help. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- drivers/acpi/Kconfig | 6 +++--- 1

[PATCH v3 2/3] usb: fail on usb_hub_create_port_device() errors

Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub->ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur Acked-by: Alan Stern --- drivers/usb/core/hub.c | 10 -- 1 file changed

[PATCH v3 0/3] usb: fix hub_configure() error handling

quot;usb: don't use bNbrPorts after initialization" has been added. The first version has been posted here: https://lkml.org/lkml/2013/8/20/469 Krzysiek Krzysztof Mazur (3): usb: fix cleanup after failure in hub_configure() usb: fail on usb_hub_create_port_device() errors u

[PATCH v3 3/3] usb: don't use bNbrPorts after initialization

After successful initialization hub->descriptor->bNbrPorts and hub->hdev->maxchild are equal, but using hub->hdev->maxchild is preferred because that value is explicitly used for initialization of hub->ports[]. Signed-off-by: Krzysztof Mazur Acked-by: Alan Stern --- driver

[PATCH v3 1/3] usb: fix cleanup after failure in hub_configure()

zed ports. Signed-off-by: Krzysztof Mazur Acked-by: Alan Stern --- drivers/usb/core/hub.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 558313d..affed11 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1568,6 +1568,7

[PATCH v3 1/3] usb: fix cleanup after failure in hub_configure()

. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/core/hub.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 558313d..affed11 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb

[PATCH v3 3/3] usb: don't use bNbrPorts after initialization

After successful initialization hub-descriptor-bNbrPorts and hub-hdev-maxchild are equal, but using hub-hdev-maxchild is preferred because that value is explicitly used for initialization of hub-ports[]. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net Acked-by: Alan Stern st

[PATCH v3 0/3] usb: fix hub_configure() error handling

: don't use bNbrPorts after initialization has been added. The first version has been posted here: https://lkml.org/lkml/2013/8/20/469 Krzysiek Krzysztof Mazur (3): usb: fix cleanup after failure in hub_configure() usb: fail on usb_hub_create_port_device() errors usb: don't use bNbrPorts

[PATCH v3 2/3] usb: fail on usb_hub_create_port_device() errors

Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub-ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/core

Re: [PATCH 2/2] usb: fail on usb_hub_create_port_device() errors

On Tue, Aug 20, 2013 at 03:50:37PM -0400, Alan Stern wrote: > On Tue, 20 Aug 2013, Krzysztof Mazur wrote: > > > On Tue, Aug 20, 2013 at 02:18:57PM -0400, Alan Stern wrote: > > > On Tue, 20 Aug 2013, Krzysztof Mazur wrote: > > > > > > > Ignoring usb_h

Re: [PATCH 2/2] usb: fail on usb_hub_create_port_device() errors

On Tue, Aug 20, 2013 at 03:50:37PM -0400, Alan Stern wrote: On Tue, 20 Aug 2013, Krzysztof Mazur wrote: On Tue, Aug 20, 2013 at 02:18:57PM -0400, Alan Stern wrote: On Tue, 20 Aug 2013, Krzysztof Mazur wrote: Ignoring usb_hub_create_port_device() errors cause later NULL pointer

Re: [PATCH 1/2] usb: fix cleanup after failure in hub_configure()

On Tue, Aug 20, 2013 at 02:59:18PM -0400, Alan Stern wrote: > On Tue, 20 Aug 2013, Krzysztof Mazur wrote: > > > > Why bother with a separate jump label? Just set maxchild to 0 whenever > > > a failure occurs. > > > > > > > Initially I had just st

Re: [PATCH 2/2] usb: fail on usb_hub_create_port_device() errors

On Tue, Aug 20, 2013 at 02:18:57PM -0400, Alan Stern wrote: > On Tue, 20 Aug 2013, Krzysztof Mazur wrote: > > > Ignoring usb_hub_create_port_device() errors cause later NULL pointer > > deference when uninitialized hub->ports[i] entries are dereferenced > > after p

Re: [PATCH 1/2] usb: fix cleanup after failure in hub_configure()

On Tue, Aug 20, 2013 at 02:14:42PM -0400, Alan Stern wrote: > On Tue, 20 Aug 2013, Krzysztof Mazur wrote: > > > If the hub_configure() fails after setting the hdev->maxchild > > the hub->ports might be NULL or point to uninitialized kzallocated > > memory ca

[PATCH 1/2] usb: fix cleanup after failure in hub_configure()

zed ports. Suggested-by: Alan Stern Signed-off-by: Krzysztof Mazur --- drivers/usb/core/hub.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 558313d..588c3a3 100644 --- a/drivers/usb/core/hub.c +++ b/drivers

[PATCH 2/2] usb: fail on usb_hub_create_port_device() errors

Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub->ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur --- I'm not sure if failing in that case is a good idea, but other solutions are m

[PATCH 0/2] usb: fix hub_configure() error handling

gure by setting hub->maxchild to the total number of allocated ports (or 0 if hub_ports can't be allocated)." http://marc.info/?l=linux-usb=136189486922963=4 The second patch uses slightly different approach because some users ignore hub->maxchild and use hub->descriptor->bNbrP

[PATCH 0/2] usb: fix hub_configure() error handling

to the total number of allocated ports (or 0 if hub_ports can't be allocated). http://marc.info/?l=linux-usbm=136189486922963w=4 The second patch uses slightly different approach because some users ignore hub-maxchild and use hub-descriptor-bNbrPorts. Krzysiek Krzysztof Mazur (2): usb: fix cleanup

[PATCH 2/2] usb: fail on usb_hub_create_port_device() errors

Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub-ports[i] entries are dereferenced after port memory allocation error. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- I'm not sure if failing in that case is a good idea, but other

[PATCH 1/2] usb: fix cleanup after failure in hub_configure()

. Suggested-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- drivers/usb/core/hub.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 558313d..588c3a3 100644 --- a/drivers

Re: [PATCH 1/2] usb: fix cleanup after failure in hub_configure()

On Tue, Aug 20, 2013 at 02:14:42PM -0400, Alan Stern wrote: On Tue, 20 Aug 2013, Krzysztof Mazur wrote: If the hub_configure() fails after setting the hdev-maxchild the hub-ports might be NULL or point to uninitialized kzallocated memory causing NULL pointer dereference in hub_quiesce

Re: [PATCH 2/2] usb: fail on usb_hub_create_port_device() errors

On Tue, Aug 20, 2013 at 02:18:57PM -0400, Alan Stern wrote: On Tue, 20 Aug 2013, Krzysztof Mazur wrote: Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub-ports[i] entries are dereferenced after port memory allocation error. Signed

Re: [PATCH 1/2] usb: fix cleanup after failure in hub_configure()

On Tue, Aug 20, 2013 at 02:59:18PM -0400, Alan Stern wrote: On Tue, 20 Aug 2013, Krzysztof Mazur wrote: Why bother with a separate jump label? Just set maxchild to 0 whenever a failure occurs. Initially I had just straightforward dev-maxchild = 0; after fail, but I changed

Re: drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]

On Sat, Apr 13, 2013 at 06:10:40PM +0100, Chris Wilson wrote: > On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote: > > Hi, > > > > the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling > > drm_mode

Re: drm: i915+fb: crtc-lock recursive locking deadlock on VT switch [= 3.9-rc1 regresion]

On Sat, Apr 13, 2013 at 06:10:40PM +0100, Chris Wilson wrote: On Sat, Apr 13, 2013 at 05:41:46PM +0200, Krzysztof Mazur wrote: Hi, the drm_fb_helper_hotplug_event() locks all crtc-mutex locks by calling drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes

drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]

Hi, the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(), which in case of i915 DRM driver effectively calls intel_get_load_detect_pipe() that tries to lock crtc->mutex again. This causes a deadlock,

drm: i915+fb: crtc-lock recursive locking deadlock on VT switch [= 3.9-rc1 regresion]

Hi, the drm_fb_helper_hotplug_event() locks all crtc-mutex locks by calling drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(), which in case of i915 DRM driver effectively calls intel_get_load_detect_pipe() that tries to lock crtc-mutex again. This causes a deadlock,

Re: [PATCH v2] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check

HDIO_DRIVE_CMD returns 0 > instead of EIO. > > Signed-off-by: Gwendal Grignou Works for me. If you like you can add: Reported-and-tested-by: Krzysztof Mazur Krzysiek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@v

Re: [PATCH] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check

On Fri, Mar 29, 2013 at 08:26:41AM -0700, Gwendal Grignou wrote: > commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63 changed the sense key > used for returning task registers, but HDIO_DRIVE_CMD ioctl was > not changed accordingly. > > Tested: check that SMART ENABLE sent using HDIO_DRIVE_CMD

Re: [PATCH] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check

On Fri, Mar 29, 2013 at 08:26:41AM -0700, Gwendal Grignou wrote: commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63 changed the sense key used for returning task registers, but HDIO_DRIVE_CMD ioctl was not changed accordingly. Tested: check that SMART ENABLE sent using HDIO_DRIVE_CMD returns 0

Re: [PATCH v2] [libata] Fix HDIO_DRIVE_CMD ioctl sense data check

instead of EIO. Signed-off-by: Gwendal Grignou gwen...@google.com Works for me. If you like you can add: Reported-and-tested-by: Krzysztof Mazur krzys...@podlesie.net Krzysiek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: ata: HDIO_DRIVE_* ioctl() Linux 3.9 regression

On Mon, Mar 25, 2013 at 06:26:50PM +0100, Ronald wrote: > In reply to [1]: I have the same issue. Git bisect took 50+ rebuilds xD > > Smartd does not work anymore since 84a9a8cd9 ([libata] Set proper SK > when CK_COND is set.). > > I hope I'm not stepping on anyone's toe's by chosing the same

Re: ata: HDIO_DRIVE_* ioctl() Linux 3.9 regression

On Mon, Mar 25, 2013 at 06:26:50PM +0100, Ronald wrote: In reply to [1]: I have the same issue. Git bisect took 50+ rebuilds xD Smartd does not work anymore since 84a9a8cd9 ([libata] Set proper SK when CK_COND is set.). I hope I'm not stepping on anyone's toe's by chosing the same title.

ata: HDIO_DRIVE_* ioctl() Linux 3.9 regression

Hi, commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63 ("[libata] Set proper SK when CK_COND is set") breaks "SMART Status command" ATA command issued by smartctl -d ata -a /dev/sda at least on FUJITSU MHV2060AH on ICH6 IDE Controller. The kernel returns -EIO on HDIO_DRIVE_TASK (0x31e) or

ata: HDIO_DRIVE_* ioctl() Linux 3.9 regression

Hi, commit 84a9a8cd9d0aa93c17e5815ab8a9cc4c0a765c63 ([libata] Set proper SK when CK_COND is set) breaks SMART Status command ATA command issued by smartctl -d ata -a /dev/sda at least on FUJITSU MHV2060AH on ICH6 IDE Controller. The kernel returns -EIO on HDIO_DRIVE_TASK (0x31e) or HDIO_DRIVE_CMD

[PATCH] x86: fix 32-bit *_cpu_data initializers

f fdiv_bug. If CONFIG_X86_F00F_BUG is not set the f00f_bug flag is never cleared. To avoid such problems in future C99-style initialization is now used. Signed-off-by: Krzysztof Mazur --- $ cat < /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model :

[PATCH] x86: fix 32-bit *_cpu_data initializers

. If CONFIG_X86_F00F_BUG is not set the f00f_bug flag is never cleared. To avoid such problems in future C99-style initialization is now used. Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model

[PATCH] cpuidle: fix number of initialized/destroyed states

ues might have different values, causing for instance NULL pointer dereference in cpuidle_remove_state_sysfs(). Signed-off-by: Krzysztof Mazur --- Hi, commit bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92 (cpuidle: support multiple drivers, merged in v3.8-rc1) causes NULL pointer de

[PATCH] cpuidle: fix number of initialized/destroyed states

different values, causing for instance NULL pointer dereference in cpuidle_remove_state_sysfs(). Signed-off-by: Krzysztof Mazur krzys...@podlesie.net --- Hi, commit bf4d1b5ddb78f86078ac6ae0415802d5f0c68f92 (cpuidle: support multiple drivers, merged in v3.8-rc1) causes NULL pointer dereference

Re: Linux 3.7 does not boot on OMAP L137 with CONFIG_TI_EDMA=y

On Tue, Dec 11, 2012 at 12:31:29AM +0100, Krzysztof Mazur wrote: > Hi, > > commit c2dde5f8f2095d7c623ff3565c1462e190272273 > (dmaengine: add TI EDMA DMA engine driver) > with new option CONFIG_TI_EDMA=y causes system hang after > "Uncompressing Linux... done, booting the

Linux 3.7 does not boot on OMAP L137 with CONFIG_TI_EDMA=y

Hi, commit c2dde5f8f2095d7c623ff3565c1462e190272273 (dmaengine: add TI EDMA DMA engine driver) with new option CONFIG_TI_EDMA=y causes system hang after "Uncompressing Linux... done, booting the kernel." on OMAP L137. The same problem still exists in current v3.7-rc8-41-gcaf4919. This causes

Linux 3.7 does not boot on OMAP L137 with CONFIG_TI_EDMA=y

Hi, commit c2dde5f8f2095d7c623ff3565c1462e190272273 (dmaengine: add TI EDMA DMA engine driver) with new option CONFIG_TI_EDMA=y causes system hang after Uncompressing Linux... done, booting the kernel. on OMAP L137. The same problem still exists in current v3.7-rc8-41-gcaf4919. This causes some

Re: Linux 3.7 does not boot on OMAP L137 with CONFIG_TI_EDMA=y

On Tue, Dec 11, 2012 at 12:31:29AM +0100, Krzysztof Mazur wrote: Hi, commit c2dde5f8f2095d7c623ff3565c1462e190272273 (dmaengine: add TI EDMA DMA engine driver) with new option CONFIG_TI_EDMA=y causes system hang after Uncompressing Linux... done, booting the kernel. on OMAP L137

Re: [PATCH] atm: introduce vcc_pop_skb()

On Mon, Dec 03, 2012 at 01:22:41PM +, David Woodhouse wrote: > On Wed, 2012-11-28 at 23:33 +0100, Krzysztof Mazur wrote: > > > > Many ATM drivers store vcc in ATM_SKB(skb)->vcc and use it for > > freeing skbs. Now they can just use atm_pop_skb() to free such > >

Re: [PATCH] atm: introduce vcc_pop_skb()

On Mon, Dec 03, 2012 at 01:22:41PM +, David Woodhouse wrote: On Wed, 2012-11-28 at 23:33 +0100, Krzysztof Mazur wrote: Many ATM drivers store vcc in ATM_SKB(skb)-vcc and use it for freeing skbs. Now they can just use atm_pop_skb() to free such buffers. Signed-off-by: Krzysztof

Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

On Fri, Nov 30, 2012 at 12:12:56PM -0500, chas williams - CONTRACTOR wrote: > >Really, what we're saying is that *one* of the driver or protocol close > >functions needs to be split, and we need to do DPD or PDP. Since the > >device driver *can* abort/flush the TX queue and also any pending RX >

Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

k.slock. > + if (atomic_read(>qspace) > 0) > + netif_wake_queue(brvcc->device); > + > + if (brvcc->old_release_cb) > + brvcc->old_release_cb(atmvcc); > +} Except that comment, the patch looks good: Acked-by: Krzysztof Mazur Krz

Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

On Fri, Nov 30, 2012 at 08:25:22AM +, David Woodhouse wrote: > On Fri, 2012-11-30 at 01:57 +, David Woodhouse wrote: > > I think it's actually fixed for pppoatm by the bh_lock_sock() and the > > sock_owned_by_user() check. As soon as vcc_release() calls lock_sock(), > > pppoatm stops

Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

On Fri, Nov 30, 2012 at 08:25:22AM +, David Woodhouse wrote: On Fri, 2012-11-30 at 01:57 +, David Woodhouse wrote: I think it's actually fixed for pppoatm by the bh_lock_sock() and the sock_owned_by_user() check. As soon as vcc_release() calls lock_sock(), pppoatm stops accepting

Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

) 0) + netif_wake_queue(brvcc-device); + + if (brvcc-old_release_cb) + brvcc-old_release_cb(atmvcc); +} Except that comment, the patch looks good: Acked-by: Krzysztof Mazur krzys...@podlesie.net Krzysiek -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

On Fri, Nov 30, 2012 at 12:12:56PM -0500, chas williams - CONTRACTOR wrote: Really, what we're saying is that *one* of the driver or protocol close functions needs to be split, and we need to do DPD or PDP. Since the device driver *can* abort/flush the TX queue and also any pending RX being

  1   2   3   >