Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 13:52, wrote: > Connecting to the backend isn't working reliably in xen-fbfront: in > case XenbusStateInitWait of the backend has been missed the backend > transition to XenbusStateConnected will trigger the connected state > only without doing the actions

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 13:52, wrote: > Connecting to the backend isn't working reliably in xen-fbfront: in > case XenbusStateInitWait of the backend has been missed the backend > transition to XenbusStateConnected will trigger the connected state > only without doing the actions required when the

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

On 23/03/17 14:37, Jan Beulich wrote: On 23.03.17 at 13:52, wrote: >> Connecting to the backend isn't working reliably in xen-fbfront: in >> case XenbusStateInitWait of the backend has been missed the backend >> transition to XenbusStateConnected will trigger the connected

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

On 23/03/17 14:37, Jan Beulich wrote: On 23.03.17 at 13:52, wrote: >> Connecting to the backend isn't working reliably in xen-fbfront: in >> case XenbusStateInitWait of the backend has been missed the backend >> transition to XenbusStateConnected will trigger the connected state >> only

Re: [PATCH] power: supply: Add driver for TI BQ2416X battery charger

Hi, On Wed, Mar 22, 2017 at 01:53:19PM +, Wojciech Ziemba wrote: > [...] > > >> and a number of knobs for controlling the charging process > > missing sysfs ABI documentation. Most of them are probably either > > not needed, or should become standard POWER_SUPPLY_PROP_ properties. > > Well,

Re: [PATCH] power: supply: Add driver for TI BQ2416X battery charger

Hi, On Wed, Mar 22, 2017 at 01:53:19PM +, Wojciech Ziemba wrote: > [...] > > >> and a number of knobs for controlling the charging process > > missing sysfs ABI documentation. Most of them are probably either > > not needed, or should become standard POWER_SUPPLY_PROP_ properties. > > Well,

Re: [Outreachy kernel] [RESEND PATCH v2] staging:speakup: Fix alignment with parenthesis.

It should be staging: speakup:, not staging:speakup: On Thu, 23 Mar 2017, Arushi Singhal wrote: > Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". It would really be better to say what the patch does, not just say what error message you have fixed. julia >

Re: [Outreachy kernel] [RESEND PATCH v2] staging:speakup: Fix alignment with parenthesis.

It should be staging: speakup:, not staging:speakup: On Thu, 23 Mar 2017, Arushi Singhal wrote: > Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". It would really be better to say what the patch does, not just say what error message you have fixed. julia >

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

Dmitry Vyukov wrote: > On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov wrote: > > Hello, > > > > I've got the following report while running syzkaller fuzzer on > > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > > kmalloc failure in

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

Dmitry Vyukov wrote: > On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov wrote: > > Hello, > > > > I've got the following report while running syzkaller fuzzer on > > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > > kmalloc failure in inode_alloc_security, most likely it's

Re: [PATCH v2 5/9] mfd: t7l66xb: make use of raw_spinlock variants

On Tue, 21 Mar 2017, Julia Cartwright wrote: > The t7l66xb mfd driver currently implements an irq_chip for handling > interrupts; due to how irq_chip handling is done, it's necessary for the > irq_chip methods to be invoked from hardirq context, even on a a > real-time kernel. Because the

Re: [PATCH v2 6/9] mfd: tc6393xb: make use of raw_spinlock variants

On Tue, 21 Mar 2017, Julia Cartwright wrote: > The tc6393xb mfd driver currently implements an irq_chip for handling > interrupts; due to how irq_chip handling is done, it's necessary for the > irq_chip methods to be invoked from hardirq context, even on a a > real-time kernel. Because the

Re: [PATCH v2 5/9] mfd: t7l66xb: make use of raw_spinlock variants

On Tue, 21 Mar 2017, Julia Cartwright wrote: > The t7l66xb mfd driver currently implements an irq_chip for handling > interrupts; due to how irq_chip handling is done, it's necessary for the > irq_chip methods to be invoked from hardirq context, even on a a > real-time kernel. Because the

Re: [PATCH v2 6/9] mfd: tc6393xb: make use of raw_spinlock variants

On Tue, 21 Mar 2017, Julia Cartwright wrote: > The tc6393xb mfd driver currently implements an irq_chip for handling > interrupts; due to how irq_chip handling is done, it's necessary for the > irq_chip methods to be invoked from hardirq context, even on a a > real-time kernel. Because the

[PATCH v2] net: stmmac: add set_mac to the stmmac_ops

Two different set_mac functions exists but stmmac_dwmac4_set_mac() is only used for enabling and never for disabling. So on dwmac4, the MAC RX/TX is never disabled. This patch add a generic function pointer set_mac() to stmmac_ops and replace all call to stmmac_set_mac/stmmac_dwmac4_set_mac by a

[PATCH v2] net: stmmac: add set_mac to the stmmac_ops

Two different set_mac functions exists but stmmac_dwmac4_set_mac() is only used for enabling and never for disabling. So on dwmac4, the MAC RX/TX is never disabled. This patch add a generic function pointer set_mac() to stmmac_ops and replace all call to stmmac_set_mac/stmmac_dwmac4_set_mac by a

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > > Hello list, > > > > > > After approximately one day day of running 4.11.0-rc3 with

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote: > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote: > > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote: > > > Hello list, > > > > > > After approximately one day day of running 4.11.0-rc3 with

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > From: Colin Ian King > > info is being checked to see if it is a null pointer, however, vpgu is > dereferencing info before this check, leading to a potential null > pointer dereference. If

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > From: Colin Ian King > > info is being checked to see if it is a null pointer, however, vpgu is > dereferencing info before this check, leading to a potential null > pointer dereference. If info is null, then the error message being > printed

Re: [PATCH v2 4/9] mfd: asic3: make use of raw_spinlock variants

On Tue, 21 Mar 2017, Julia Cartwright wrote: > The asic3 mfd driver currently implements an irq_chip for handling > interrupts; due to how irq_chip handling is done, it's necessary for the > irq_chip methods to be invoked from hardirq context, even on a a > real-time kernel. Because the

Re: [PATCH v2 4/9] mfd: asic3: make use of raw_spinlock variants

On Tue, 21 Mar 2017, Julia Cartwright wrote: > The asic3 mfd driver currently implements an irq_chip for handling > interrupts; due to how irq_chip handling is done, it's necessary for the > irq_chip methods to be invoked from hardirq context, even on a a > real-time kernel. Because the

Re: [PATCH 3/4] zram: implement deduplication in zram

35.830111] Modules linked in: lzo zram(-) zsmalloc mousedev nls_iso8859_1 nls_cp437 vfat fat psmouse serio_raw atkbd libps2 coretemp hwmon iwlmvm crc32c_intel i2c_i801 r8169 iwlwifi lpc_ich mii mfd_core ie31200_edac edac_core thermal i8042 serio wmi evdev acpi_cpufreq sd_mod [ 2935.830127] CPU:

Re: [PATCH 3/4] zram: implement deduplication in zram

35.830111] Modules linked in: lzo zram(-) zsmalloc mousedev nls_iso8859_1 nls_cp437 vfat fat psmouse serio_raw atkbd libps2 coretemp hwmon iwlmvm crc32c_intel i2c_i801 r8169 iwlwifi lpc_ich mii mfd_core ie31200_edac edac_core thermal i8042 serio wmi evdev acpi_cpufreq sd_mod [ 2935.830127] CPU:

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König wrote: > Maybe we can make gpiod_get_optional look like this: > > if (!dev->of_node && isnt_a_acpi_device(dev) && !IS_ENABLED(GPIOLIB)) > return NULL; > else > return

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König wrote: > Maybe we can make gpiod_get_optional look like this: > > if (!dev->of_node && isnt_a_acpi_device(dev) && !IS_ENABLED(GPIOLIB)) > return NULL; > else > return -ENOSYS; > > I don't know how

[PATCH v2] staging:speakup: Fix alignment with parenthesis.

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". Signed-off-by: Arushi Singhal --- changes in v2 - change the commit message. drivers/staging/speakup/speakup_apollo.c | 2 +- drivers/staging/speakup/speakup_decext.c | 4 ++-- 2 files

[PATCH v2] staging:speakup: Fix alignment with parenthesis.

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". Signed-off-by: Arushi Singhal --- changes in v2 - change the commit message. drivers/staging/speakup/speakup_apollo.c | 2 +- drivers/staging/speakup/speakup_decext.c | 4 ++-- 2 files changed, 3 insertions(+), 3

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 11:10 AM, Uwe Kleine-König wrote: > So you exchanged many obvious and easy to fix problems with a few hard > ones. I don't agree that's a good idea, but you seem to be willing to > try it. Good luck. I think instead of going to sarcastic

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 11:10 AM, Uwe Kleine-König wrote: > So you exchanged many obvious and easy to fix problems with a few hard > ones. I don't agree that's a good idea, but you seem to be willing to > try it. Good luck. I think instead of going to sarcastic remarks you can say you NACK the

Re: [PATCH] staging: media: atomisp: use kvmalloc and kvfree

On Thu, Mar 23, 2017 at 09:12:39PM +0800, Geliang Tang wrote: > Use kvmalloc() and kvfree() instead of open-coding. These functions are not in Linus's tree, so I can't apply this patch without breaking things :( thanks, greg k-h

Re: [PATCH] staging: media: atomisp: use kvmalloc and kvfree

On Thu, Mar 23, 2017 at 09:12:39PM +0800, Geliang Tang wrote: > Use kvmalloc() and kvfree() instead of open-coding. These functions are not in Linus's tree, so I can't apply this patch without breaking things :( thanks, greg k-h

Re: [PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

On Wed, Mar 22, 2017 at 01:33:39PM +1100, Eddie Youseph wrote: > Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: Eddie Youseph > --- > Changes in v2: > - Added changelog Did you actually build this change? Please do

Re: [PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

On Wed, Mar 22, 2017 at 01:33:39PM +1100, Eddie Youseph wrote: > Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: Eddie Youseph > --- > Changes in v2: > - Added changelog Did you actually build this change? Please do so... thanks, greg k-h

Re: [PATCH] staging:fbtft/fbtft-io: Fix incorrect type in assignment

On Thu, Mar 23, 2017 at 03:08:38PM +0800, Zhengyi Shen wrote: > Fix endian sparse warnings of incorrect type in assignment. > This patch changes type to the appropriate endian specific versions. > > > Signed-off-by: Zhengyi Shen > --- > drivers/staging/fbtft/fbtft-io.c |

Re: [PATCH] staging:fbtft/fbtft-io: Fix incorrect type in assignment

On Thu, Mar 23, 2017 at 03:08:38PM +0800, Zhengyi Shen wrote: > Fix endian sparse warnings of incorrect type in assignment. > This patch changes type to the appropriate endian specific versions. > > > Signed-off-by: Zhengyi Shen > --- > drivers/staging/fbtft/fbtft-io.c | 2 +- > 1 file

Re: [PATCH] asm-generic: fix compilation failure in cmpxchg_double()

On Thu, Mar 23, 2017 at 9:49 AM, Dmitry Vyukov wrote: > On Wed, Mar 22, 2017 at 10:27 PM, Arnd Bergmann wrote: >> On Wed, Mar 22, 2017 at 12:27 PM, Arnd Bergmann wrote: >>> On Wed, Mar 22, 2017 at 12:10 PM, Dmitry Vyukov

Re: [PATCH] asm-generic: fix compilation failure in cmpxchg_double()

On Thu, Mar 23, 2017 at 9:49 AM, Dmitry Vyukov wrote: > On Wed, Mar 22, 2017 at 10:27 PM, Arnd Bergmann wrote: >> On Wed, Mar 22, 2017 at 12:27 PM, Arnd Bergmann wrote: >>> On Wed, Mar 22, 2017 at 12:10 PM, Dmitry Vyukov wrote: Arnd reported that the new code leads to compilation failures

Re: [PATCH v2] kasan: report only the first error by default

On Thu, Mar 23, 2017 at 04:06:59PM +0300, Andrey Ryabinin wrote: > On 03/23/2017 03:41 PM, Mark Rutland wrote: > > Rather than trying to pick an arbitrarily large number, how about we use > > separate flags to determine whether we're in multi-shot mode, and > > whether a (oneshot) report has been

Re: [PATCH v2] kasan: report only the first error by default

On Thu, Mar 23, 2017 at 04:06:59PM +0300, Andrey Ryabinin wrote: > On 03/23/2017 03:41 PM, Mark Rutland wrote: > > Rather than trying to pick an arbitrarily large number, how about we use > > separate flags to determine whether we're in multi-shot mode, and > > whether a (oneshot) report has been

RE: Query on DT overlay support.

Hi,     This mail is regarding the DT overlay support in the Linux kernel     I am able to make the device-tree overlay work out of box by using my own dtc complier (I mean I used the dtc compiler     Available here

RE: Query on DT overlay support.

Hi,     This mail is regarding the DT overlay support in the Linux kernel     I am able to make the device-tree overlay work out of box by using my own dtc complier (I mean I used the dtc compiler     Available here

[PATCH] auxdisplay: hd44780: Fix DT properties to include units of measurement

DT properties specifying physical properties should contain appropriate suffices indicating the units of measurement. Hence amend the HD44780 DT bindings to add "chars" suffixes to the "display-height" and "display-width" properties, and update the driver to parse them. Fixes: dd9502a9e9156dd8

[PATCH] auxdisplay: hd44780: Fix DT properties to include units of measurement

DT properties specifying physical properties should contain appropriate suffices indicating the units of measurement. Hence amend the HD44780 DT bindings to add "chars" suffixes to the "display-height" and "display-width" properties, and update the driver to parse them. Fixes: dd9502a9e9156dd8

ata: WARNING in ata_qc_issue

Hello, The following program triggers WARNING in ata_qc_issue: https://gist.githubusercontent.com/dvyukov/3503afce181b7d48dabb421e10e70b00/raw/d049bd2128a8b1089497beb6104ba48c5550b4a8/gistfile1.txt [ cut here ] WARNING: CPU: 3 PID: 2956 at drivers/ata/libata-core.c:5317

ata: WARNING in ata_qc_issue

Hello, The following program triggers WARNING in ata_qc_issue: https://gist.githubusercontent.com/dvyukov/3503afce181b7d48dabb421e10e70b00/raw/d049bd2128a8b1089497beb6104ba48c5550b4a8/gistfile1.txt [ cut here ] WARNING: CPU: 3 PID: 2956 at drivers/ata/libata-core.c:5317

Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

On Thu, Mar 23, 2017 at 08:38:20AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Mar 22, 2017 at 08:46:16AM +0100, Ingo Molnar wrote: > > > > > > * Jiri Slaby wrote: > > > > > > > On 03/22/2017, 08:25 AM, Ingo Molnar wrote: > > > > >

Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

On Thu, Mar 23, 2017 at 08:38:20AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Mar 22, 2017 at 08:46:16AM +0100, Ingo Molnar wrote: > > > > > > * Jiri Slaby wrote: > > > > > > > On 03/22/2017, 08:25 AM, Ingo Molnar wrote: > > > > > > > > > > * Pavel Machek wrote: >

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

On 23.03.2017 03:27, Kees Cook wrote: This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: Remove x86 hibernation restrictions"), since it appears that 32-bit hibernation still can't support KASLR. 64-bit is fine. Since people have been running with KASLR by default on 32-bit

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

On 23.03.2017 03:27, Kees Cook wrote: This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: Remove x86 hibernation restrictions"), since it appears that 32-bit hibernation still can't support KASLR. 64-bit is fine. Since people have been running with KASLR by default on 32-bit

Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

Hi! > > Plus I have played with v4l-utils, and managed to implement autofocus > > and autoexposure -- it was easier than expected. I believe you > > mentioned you had some patches to automatically initialize the > > pipeline. Do you and can I have them? > > It was an early prototype and it

Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

Hi! > > Plus I have played with v4l-utils, and managed to implement autofocus > > and autoexposure -- it was easier than expected. I believe you > > mentioned you had some patches to automatically initialize the > > pipeline. Do you and can I have them? > > It was an early prototype and it

Re: [PATCH] drivers/staging/dgnc: Removing manual function tracing using dev_dbg

On Thu, Mar 23, 2017 at 02:20:53PM +0530, Pushkar Jambhlekar wrote: > Current implementation manually traces function using 'dev_dbg'. This way is > not needed because of ftrace, making these calls redundant. Always wrap your changelog lines properly. Also, someone else sent this same patch in

Re: [PATCH] drivers/staging/dgnc: Removing manual function tracing using dev_dbg

On Thu, Mar 23, 2017 at 02:20:53PM +0530, Pushkar Jambhlekar wrote: > Current implementation manually traces function using 'dev_dbg'. This way is > not needed because of ftrace, making these calls redundant. Always wrap your changelog lines properly. Also, someone else sent this same patch in

[PATCH] nvmem: imx-ocotp: fix usage of "dev" pointers

Assign the correct dev pointer to struct ocotp_priv during probe. This is needed to display dev_* messages correctly. Furthermore harmonize the usage of dev (instead of >dev) in the probe function. Signed-off-by: Richard Leitner --- drivers/nvmem/imx-ocotp.c | 4

[PATCH] nvmem: imx-ocotp: fix usage of "dev" pointers

Assign the correct dev pointer to struct ocotp_priv during probe. This is needed to display dev_* messages correctly. Furthermore harmonize the usage of dev (instead of >dev) in the probe function. Signed-off-by: Richard Leitner --- drivers/nvmem/imx-ocotp.c | 4 +++- 1 file changed, 3

Re: [PATCH 11/11] staging: speakup: Fix alignment with parenthesis.

On Tue, Mar 21, 2017 at 05:12:35PM +0530, Arushi Singhal wrote: > This patch fixes the warnings reported by checkpatch.pl > for please use a blank line after function/struct/union/enum > declarations. That's not what this patch does at all! Please be more careful. greg k-h

Re: [PATCH 11/11] staging: speakup: Fix alignment with parenthesis.

On Tue, Mar 21, 2017 at 05:12:35PM +0530, Arushi Singhal wrote: > This patch fixes the warnings reported by checkpatch.pl > for please use a blank line after function/struct/union/enum > declarations. That's not what this patch does at all! Please be more careful. greg k-h

Re: [PATCH 09/11] staging: speakup: Simplify the NULL comparisons

On Tue, Mar 21, 2017 at 05:12:33PM +0530, Arushi Singhal wrote: > Fixed coding style for null comparisons in speakup driver to be more > consistant with the rest of the kernel coding style. > Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'. > > Signed-off-by: Arushi Singhal

Re: [PATCH 09/11] staging: speakup: Simplify the NULL comparisons

On Tue, Mar 21, 2017 at 05:12:33PM +0530, Arushi Singhal wrote: > Fixed coding style for null comparisons in speakup driver to be more > consistant with the rest of the kernel coding style. > Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'. > > Signed-off-by: Arushi Singhal > --- >

Re: [PATCH 05/11] staging: speakup: Remove multiple assignments

On Tue, Mar 21, 2017 at 05:12:29PM +0530, Arushi Singhal wrote: > This patch fixes the checkpatch.pl warning "multiple assignments > should be avoided." > > Signed-off-by: Arushi Singhal > --- > drivers/staging/speakup/main.c | 3 ++- > 1 file changed, 2

Re: [PATCH 05/11] staging: speakup: Remove multiple assignments

On Tue, Mar 21, 2017 at 05:12:29PM +0530, Arushi Singhal wrote: > This patch fixes the checkpatch.pl warning "multiple assignments > should be avoided." > > Signed-off-by: Arushi Singhal > --- > drivers/staging/speakup/main.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff

Re: [PATCH 02/11] staging: speakup: Remove multiple assignments

On Tue, Mar 21, 2017 at 05:12:26PM +0530, Arushi Singhal wrote: > This patch fixes the checkpatch.pl warning "multiple assignments > should be avoided." > > Signed-off-by: Arushi Singhal > --- > drivers/staging/speakup/main.c | 18 -- > 1 file

Re: [PATCH 02/11] staging: speakup: Remove multiple assignments

On Tue, Mar 21, 2017 at 05:12:26PM +0530, Arushi Singhal wrote: > This patch fixes the checkpatch.pl warning "multiple assignments > should be avoided." > > Signed-off-by: Arushi Singhal > --- > drivers/staging/speakup/main.c | 18 -- > 1 file changed, 12 insertions(+), 6

Re: kvm: use-after-free function call in kvm_io_bus_destroy

On 23.03.2017 13:33, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > kmalloc failure, most likely it's the root cause. > > > FAULT_INJECTION: forcing a failure. > name

Re: kvm: use-after-free function call in kvm_io_bus_destroy

On 23.03.2017 13:33, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > kmalloc failure, most likely it's the root cause. > > > FAULT_INJECTION: forcing a failure. > name

Re: [PATCH staging/speakup v3 3/3] use speakup_allocate as per required context

On Tue, Mar 21, 2017 at 12:40:24PM +0530, Pranay Kr. Srivastava wrote: > speakup_allocate used GFP_ATOMIC for allocations > even while during initialization due to it's use > in notifier call. > > Pass GFP_ flags as well to speakup_allocate depending > on the context it is called in. > >

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

On Wed, Mar 22, 2017 at 10:56:02AM -0700, Ankur Arora wrote: > >It is ok to do upload_pm_data() with delay i.e. after some other > >resume actions are done and possibly xen-acpi-processor is in > >running state ? > The state uploaded is ACPI P and C state from struct acpi_processor > which AFAICS

Re: [PATCH staging/speakup v3 3/3] use speakup_allocate as per required context

On Tue, Mar 21, 2017 at 12:40:24PM +0530, Pranay Kr. Srivastava wrote: > speakup_allocate used GFP_ATOMIC for allocations > even while during initialization due to it's use > in notifier call. > > Pass GFP_ flags as well to speakup_allocate depending > on the context it is called in. > >

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

On Wed, Mar 22, 2017 at 10:56:02AM -0700, Ankur Arora wrote: > >It is ok to do upload_pm_data() with delay i.e. after some other > >resume actions are done and possibly xen-acpi-processor is in > >running state ? > The state uploaded is ACPI P and C state from struct acpi_processor > which AFAICS

[PATCH] microblaze: use sg_phys()

Use sg_phys() instead of open-coding it. Signed-off-by: Geliang Tang --- arch/microblaze/kernel/dma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c index 12e093a..e45ada8 100644 ---

[PATCH] microblaze: use sg_phys()

Use sg_phys() instead of open-coding it. Signed-off-by: Geliang Tang --- arch/microblaze/kernel/dma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c index 12e093a..e45ada8 100644 ---

[PATCH] qla2xxx: use sg_virt()

Use sg_virt() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/scsi/qla2xxx/qla_isr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c index 3203367..9610d85 100644 ---

[PATCH] qla2xxx: use sg_virt()

Use sg_virt() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/scsi/qla2xxx/qla_isr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c index 3203367..9610d85 100644 ---

[PATCH] iommu: use sg_phys()

Use sg_phys() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/iommu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index

[PATCH] crypto: ixp4xx - Use sg_virt()

Use sg_virt() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/crypto/ixp4xx_crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c index 7868765..771dd26 100644 ---

[PATCH] iommu: use sg_phys()

Use sg_phys() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/iommu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index d412a31..9d09a9e 100644

[PATCH] crypto: ixp4xx - Use sg_virt()

Use sg_virt() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/crypto/ixp4xx_crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c index 7868765..771dd26 100644 ---

[PATCH] isdn: use setup_timer

Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- drivers/isdn/divert/isdn_divert.c | 9 +++-- drivers/isdn/hardware/eicon/divasi.c| 5 ++--- drivers/isdn/hardware/mISDN/hfcmulti.c | 10 --

[PATCH] isdn: use setup_timer

Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang --- drivers/isdn/divert/isdn_divert.c | 9 +++-- drivers/isdn/hardware/eicon/divasi.c| 5 ++--- drivers/isdn/hardware/mISDN/hfcmulti.c | 10 --

[PATCH] pstore: remove unused vmalloc.h in pmsg

Since the vmalloc code has been removed from write_pmsg() in the commit "5bf6d1b pstore/pmsg: drop bounce buffer", remove the unused header vmalloc.h. Signed-off-by: Geliang Tang --- fs/pstore/pmsg.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/pstore/pmsg.c

[PATCH] pstore: remove unused vmalloc.h in pmsg

Since the vmalloc code has been removed from write_pmsg() in the commit "5bf6d1b pstore/pmsg: drop bounce buffer", remove the unused header vmalloc.h. Signed-off-by: Geliang Tang --- fs/pstore/pmsg.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c index

Re: [PATCH v1] mfd: core: Preserve PLATFORM_DEVID_NONE

On Thu, 2017-03-23 at 11:21 +, Lee Jones wrote: > On Thu, 16 Mar 2017, Andy Shevchenko wrote: > > > There is a potential flaw if cell has id > 0 and is going to be > > registered with PLATFORM_DEVID_NONE. > > > > Ignore if PLATFORM_DEVID_NONE is supplied. > > This is a substantial change to

Re: [PATCH v1] mfd: core: Preserve PLATFORM_DEVID_NONE

On Thu, 2017-03-23 at 11:21 +, Lee Jones wrote: > On Thu, 16 Mar 2017, Andy Shevchenko wrote: > > > There is a potential flaw if cell has id > 0 and is going to be > > registered with PLATFORM_DEVID_NONE. > > > > Ignore if PLATFORM_DEVID_NONE is supplied. > > This is a substantial change to

[PATCH] staging: media: atomisp: use kvmalloc and kvfree

Use kvmalloc() and kvfree() instead of open-coding. Signed-off-by: Geliang Tang --- drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git

[PATCH] staging: media: atomisp: use kvmalloc and kvfree

Use kvmalloc() and kvfree() instead of open-coding. Signed-off-by: Geliang Tang --- drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c

[PATCH] staging: media: atomisp: fix build error

Fix the following build error: CC drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: error: excess elements in array initializer [-Werror] "i", /* ion */ ^~~ drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: note:

[PATCH] staging: media: atomisp: fix build error

Fix the following build error: CC drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: error: excess elements in array initializer [-Werror] "i", /* ion */ ^~~ drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2: note:

Re: [PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

On 03/23/2017 06:05 AM, Peter Hüwe wrote: This is of course v2 of the series Forgot to add it to git-send-email, sorry. Shall I resend with v2 in subject? No, it's ok. At least you have a change log :-). Thanks, Guenter

Re: [PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

On 03/23/2017 06:05 AM, Peter Hüwe wrote: This is of course v2 of the series Forgot to add it to git-send-email, sorry. Shall I resend with v2 in subject? No, it's ok. At least you have a change log :-). Thanks, Guenter

Re: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

On 23 March 2017 at 11:45, Bean Huo (beanhuo) wrote: > Hi, > >>On 19 March 2017 at 01:45, Bean Huo (beanhuo) wrote: >>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache >>> when eMMC cache has already been off through user space tool,

Re: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

On 23 March 2017 at 11:45, Bean Huo (beanhuo) wrote: > Hi, > >>On 19 March 2017 at 01:45, Bean Huo (beanhuo) wrote: >>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache >>> when eMMC cache has already been off through user space tool, such as >>> mmc-utils. >>> The reason is

Re: [PATCH v5 08/13] powerpc/perf: PMU functions for Core IMC and hotplugging

Hi Maddy, Hemant, Anju, On Thu, Mar 16, 2017 at 01:05:02PM +0530, Madhavan Srinivasan wrote: [..snip..] > + > +static void core_imc_change_cpu_context(int old_cpu, int new_cpu) > +{ > + if (!core_imc_pmu) > + return; > + perf_pmu_migrate_context(_imc_pmu->pmu, old_cpu,

Re: [PATCH v5 08/13] powerpc/perf: PMU functions for Core IMC and hotplugging

Hi Maddy, Hemant, Anju, On Thu, Mar 16, 2017 at 01:05:02PM +0530, Madhavan Srinivasan wrote: [..snip..] > + > +static void core_imc_change_cpu_context(int old_cpu, int new_cpu) > +{ > + if (!core_imc_pmu) > + return; > + perf_pmu_migrate_context(_imc_pmu->pmu, old_cpu,

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > kmalloc failure in inode_alloc_security, most likely it's the root >

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > kmalloc failure in inode_alloc_security, most likely it's the root > cause. > > >

security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

Hello, I've got the following report while running syzkaller fuzzer on 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure in inode_alloc_security, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0,

security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

Hello, I've got the following report while running syzkaller fuzzer on 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure in inode_alloc_security, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0,

[RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

I think this version is ready for review. It has all the required bits and pieces. I still have a few questions, embedded as comments in the code. (Missing are ancillary changes to Kconfig, Makefile) --- drivers/pci/host/pcie-tango.c | 350 ++ 1 file

[RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

I think this version is ready for review. It has all the required bits and pieces. I still have a few questions, embedded as comments in the code. (Missing are ancillary changes to Kconfig, Makefile) --- drivers/pci/host/pcie-tango.c | 350 ++ 1 file

<    9   10   11   12   13   14   15   16   17   18   >