Re: CVE-2016-10229 in 4.4.x series

Is there any particular reason that the CVE appears to be filed against 4.4.60? Or is this just a mistake? http://www.cvedetails.com/cve/CVE-2016-10229/ - Steven On Mon, May 15, 2017 at 10:20 PM, Willy Tarreau wrote: > On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote:

Re: CVE-2016-10229 in 4.4.x series

Is there any particular reason that the CVE appears to be filed against 4.4.60? Or is this just a mistake? http://www.cvedetails.com/cve/CVE-2016-10229/ - Steven On Mon, May 15, 2017 at 10:20 PM, Willy Tarreau wrote: > On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote: >> Hi, >> >>

[RESEND PATCH] iio: adc: bcm_iproc_adc: swap primary and secondary isr handler's

The third argument of devm_request_threaded_irq() is the primary handler. It is called in hardirq context and checks whether the interrupt is relevant to the device. If the primary handler returns IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is scheduled to run in process

[RESEND PATCH] iio: adc: bcm_iproc_adc: swap primary and secondary isr handler's

The third argument of devm_request_threaded_irq() is the primary handler. It is called in hardirq context and checks whether the interrupt is relevant to the device. If the primary handler returns IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is scheduled to run in process

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, > Lv > Subject: RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > Hi, Guys > > > From: Benjamin Tissoires

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi, > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng, > Lv > Subject: RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > Hi, Guys > > > From: Benjamin Tissoires

Re: [PATCH 1/3] ipc/sem.c: remove sem_base, embed struct sem

> + struct sem sems[0]; I can't contribute much to the code itself, but [0] is an old GCC extension, for modern code sems[] should do the same things but is standard C.

Re: [PATCH 1/3] ipc/sem.c: remove sem_base, embed struct sem

> + struct sem sems[0]; I can't contribute much to the code itself, but [0] is an old GCC extension, for modern code sems[] should do the same things but is standard C.

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

On (05/16/17 14:26), Minchan Kim wrote: [..] > > + /* > > +* Free memory associated with this sector > > +* before overwriting unused sectors. > > +*/ > > + zram_slot_lock(zram, index); > > + zram_free_page(zram, index); > > Hmm, zram_free should happen

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

On (05/16/17 14:26), Minchan Kim wrote: [..] > > + /* > > +* Free memory associated with this sector > > +* before overwriting unused sectors. > > +*/ > > + zram_slot_lock(zram, index); > > + zram_free_page(zram, index); > > Hmm, zram_free should happen

Re: [PATCH] usb: class: usblp: Fixed assignments inside if conditions

Hi Alberto, [auto build test ERROR on usb/usb-testing] [also build test ERROR on v4.12-rc1 next-20170515] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Alberto-Ladron/usb-class-usblp-Fixed

Re: [PATCH] usb: class: usblp: Fixed assignments inside if conditions

Hi Alberto, [auto build test ERROR on usb/usb-testing] [also build test ERROR on v4.12-rc1 next-20170515] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Alberto-Ladron/usb-class-usblp-Fixed

[GIT PULL] s390 patches for 4.12-rc2

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: * Convert the debug feature to refcount_t * Reduce the copy size for strncpy_from_user * 8 bug fixes Elena Reshetova (1):

[GIT PULL] s390 patches for 4.12-rc2

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: * Convert the debug feature to refcount_t * Reduce the copy size for strncpy_from_user * 8 bug fixes Elena Reshetova (1):

[PATCH] test: check a case when a mount is propagated between exiting mounts

This test checks two behaviour cases: When a mount is propagated to a place which is already busy, the new mount is inserted between parent and old mount. When a mount that is being unmounted due to propagation has another mount on top of it, it is replaced by the top mount. Cc: Shuah Khan

[PATCH] test: check a case when a mount is propagated between exiting mounts

This test checks two behaviour cases: When a mount is propagated to a place which is already busy, the new mount is inserted between parent and old mount. When a mount that is being unmounted due to propagation has another mount on top of it, it is replaced by the top mount. Cc: Shuah Khan

Re: [PATCH v3 00/11] soc/fsl/qbman: Enable QBMan on ARM Platforms

On Mon, 2017-05-01 at 17:30 -0400, Roy Pledge wrote: > This patch series enables DPAA1 QBMan devices for ARM and > ARM64 architectures. This allows the LS1043A and LS1046A to use > QBMan functionality. > > Changes since v2: > Fixed some misspellings > Added 'no-map' constraint to device tree

Re: [PATCH v3 00/11] soc/fsl/qbman: Enable QBMan on ARM Platforms

On Mon, 2017-05-01 at 17:30 -0400, Roy Pledge wrote: > This patch series enables DPAA1 QBMan devices for ARM and > ARM64 architectures. This allows the LS1043A and LS1046A to use > QBMan functionality. > > Changes since v2: > Fixed some misspellings > Added 'no-map' constraint to device tree

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi, Guys > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires > >

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi, Guys > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires > >

Re: [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33

Hi, On Wed, May 10, 2017 at 2:58 PM, Mylene Josserand wrote: > Hi Chen-Yu, > > Thank you for the review! > > > On 03/05/2017 19:13, Chen-Yu Tsai wrote: >> >> Hi, >> >> On Wed, May 3, 2017 at 9:56 PM, Mylène Josserand >>

Re: [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33

Hi, On Wed, May 10, 2017 at 2:58 PM, Mylene Josserand wrote: > Hi Chen-Yu, > > Thank you for the review! > > > On 03/05/2017 19:13, Chen-Yu Tsai wrote: >> >> Hi, >> >> On Wed, May 3, 2017 at 9:56 PM, Mylène Josserand >> wrote: >>> >>> Add ADC support for the sun8i-codec driver. >>> >>> This

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

On Tue, May 16, 2017 at 11:36:15AM +0900, Sergey Senozhatsky wrote: > > > > @@ -794,7 +801,15 @@ static int __zram_bvec_write(struct zram *zram, > > > > struct bio_vec *bvec, u32 index) > > > > entry = zram_dedup_find(zram, page, ); > > > > if (entry) { > > > >

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

On Tue, May 16, 2017 at 11:36:15AM +0900, Sergey Senozhatsky wrote: > > > > @@ -794,7 +801,15 @@ static int __zram_bvec_write(struct zram *zram, > > > > struct bio_vec *bvec, u32 index) > > > > entry = zram_dedup_find(zram, page, ); > > > > if (entry) { > > > >

[PATCH] iommu: of: Fix check for returning EPROBE_DEFER

While returning EPROBE_DEFER for iommu masters take in to account of iommu nodes that could be marked in DT as 'status=disabled', in which case simply return NULL and let the master's probe continue rather than deferring. Signed-off-by: Sricharan R Tested-by: Will

[PATCH] iommu: of: Fix check for returning EPROBE_DEFER

While returning EPROBE_DEFER for iommu masters take in to account of iommu nodes that could be marked in DT as 'status=disabled', in which case simply return NULL and let the master's probe continue rather than deferring. Signed-off-by: Sricharan R Tested-by: Will Deacon Acked-by: Will Deacon

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Sat, May 6, 2017 at 11:00 AM, Oza Oza wrote: > On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote: >> On 04/05/17 19:41, Oza Oza wrote: >> [...] > 5) leaves scope of adding PCI flag handling for inbound memory > by the new function.

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Sat, May 6, 2017 at 11:00 AM, Oza Oza wrote: > On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote: >> On 04/05/17 19:41, Oza Oza wrote: >> [...] > 5) leaves scope of adding PCI flag handling for inbound memory > by the new function. Which flags would ever actually matter?

[PATCH v6 2/3] iommu/pci: reserve IOVA for PCI masters

this patch reserves the IOVA for PCI masters. ARM64 based SOCs may have scattered memory banks. such as iproc based SOC has <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */ <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */ <0x0090 0x 0x4 0x>, /* 16G @ 576G */

[PATCH] PM / Domains: pdd->dev can't be NULL in genpd_dev_pm_qos_notifier()

The pm_domain_data (pdd) pointer is set from genpd_alloc_dev_data() and pdd->dev is guaranteed to be valid. There is no need to check pdd and pdd->dev in rest of the code as pdd->dev will always be valid for a non NULL pdd pointer. Signed-off-by: Viresh Kumar ---

[PATCH v6 2/3] iommu/pci: reserve IOVA for PCI masters

this patch reserves the IOVA for PCI masters. ARM64 based SOCs may have scattered memory banks. such as iproc based SOC has <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */ <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */ <0x0090 0x 0x4 0x>, /* 16G @ 576G */

[PATCH] PM / Domains: pdd->dev can't be NULL in genpd_dev_pm_qos_notifier()

The pm_domain_data (pdd) pointer is set from genpd_alloc_dev_data() and pdd->dev is guaranteed to be valid. There is no need to check pdd and pdd->dev in rest of the code as pdd->dev will always be valid for a non NULL pdd pointer. Signed-off-by: Viresh Kumar --- drivers/base/power/domain.c | 2

[PATCH v6 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v6 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v6 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v6 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

Re: CVE-2016-10229 in 4.4.x series

On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote: > Hi, > > This is my first post - not currently subscribed so please CC me. :) I > searched a bit for this question, but couldn't find an answer (Googled > '2016-10229 site:lkml.org'). > > Does CVE-2016-10229 affect the newest version

Re: CVE-2016-10229 in 4.4.x series

On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote: > Hi, > > This is my first post - not currently subscribed so please CC me. :) I > searched a bit for this question, but couldn't find an answer (Googled > '2016-10229 site:lkml.org'). > > Does CVE-2016-10229 affect the newest version

Re: [PATCH 1/4] power: supply: axp20x_battery: add support for DT battery

On Thu, May 11, 2017 at 9:42 PM, Quentin Schulz wrote: > This adds support in X-Powers AXP20X and AXP22X battery driver for a > fixed battery in DT. > > It will take the minimum supported voltage by the battery as defined in > the battery DT node and set the

Re: [PATCH 1/4] power: supply: axp20x_battery: add support for DT battery

On Thu, May 11, 2017 at 9:42 PM, Quentin Schulz wrote: > This adds support in X-Powers AXP20X and AXP22X battery driver for a > fixed battery in DT. > > It will take the minimum supported voltage by the battery as defined in > the battery DT node and set the V_OFF register to this value, telling

[PATCH v2] kbuild: skip install/check of headers right under uapi directories

Since commit 61562f981e92 ("uapi: export all arch specifics directories"), "make INSTALL_HDR_PATH=$root/usr headers_install" deletes standard glibc headers and others in $root/usr/include. The cause of the issue is that headers_install now starts descending from arch/$(hdr-arch)/include/uapi with

[PATCH v2] kbuild: skip install/check of headers right under uapi directories

Since commit 61562f981e92 ("uapi: export all arch specifics directories"), "make INSTALL_HDR_PATH=$root/usr headers_install" deletes standard glibc headers and others in $root/usr/include. The cause of the issue is that headers_install now starts descending from arch/$(hdr-arch)/include/uapi with

Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

Hi Laurent, On 15-05-2017 08:05, Laurent Pinchart wrote: > On Monday 15 May 2017 08:47:49 Daniel Vetter wrote: >> On Sun, May 14, 2017 at 02:04:24PM +0300, Laurent Pinchart wrote: >>> On Friday 12 May 2017 17:06:14 Jose Abreu wrote: On 12-05-2017 10:35, Laurent Pinchart wrote: > On

Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

Hi Laurent, On 15-05-2017 08:05, Laurent Pinchart wrote: > On Monday 15 May 2017 08:47:49 Daniel Vetter wrote: >> On Sun, May 14, 2017 at 02:04:24PM +0300, Laurent Pinchart wrote: >>> On Friday 12 May 2017 17:06:14 Jose Abreu wrote: On 12-05-2017 10:35, Laurent Pinchart wrote: > On

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

Hi, Benjamin I reordered the discussion to collect topics and delete things to make discussion shorter. 1. root caused issue: > > It seems we just need to determine the following first: > > 1. Who should be responsible for solving bugs triggered by the conflict > > between bios and linux user

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

Hi, Benjamin I reordered the discussion to collect topics and delete things to make discussion shorter. 1. root caused issue: > > It seems we just need to determine the following first: > > 1. Who should be responsible for solving bugs triggered by the conflict > > between bios and linux user

Re: [PATCH] kbuild: skip header install/check for right under uapi directories

On Mon, May 15, 2017 at 9:35 PM, Masahiro Yamada wrote: > Since commit 61562f981e92 ("uapi: export all arch specifics > directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install" > deletes standard glibc headers and others in ${root}/usr/include. > > The

Re: [PATCH] kbuild: skip header install/check for right under uapi directories

On Mon, May 15, 2017 at 9:35 PM, Masahiro Yamada wrote: > Since commit 61562f981e92 ("uapi: export all arch specifics > directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install" > deletes standard glibc headers and others in ${root}/usr/include. > > The cause of the issue is that

[Qustion] vmalloc area overlap with another allocated vmalloc area

Hi I hit the following issue by runing /proc/vmallocinfo. The kernel is 4.1 stable and 32 bit to be used. after I expand the vamlloc area, the issue is not occur again. it is related to the overflow. but I do not see any problem so far. cat /proc/vmallocinfo 0xf158-0xf160 524288

[Qustion] vmalloc area overlap with another allocated vmalloc area

Hi I hit the following issue by runing /proc/vmallocinfo. The kernel is 4.1 stable and 32 bit to be used. after I expand the vamlloc area, the issue is not occur again. it is related to the overflow. but I do not see any problem so far. cat /proc/vmallocinfo 0xf158-0xf160 524288

Re: [lkp-robot] [asm] c1aad8dcc4: BUG:kernel_hang_in_boot_stage

On 05/16, Al Viro wrote: >On Tue, May 16, 2017 at 09:19:57AM +0800, kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: c1aad8dcc49382399f48541dc47b6e30b0ef1b62 ("asm-generic: zero in >> __get_user(), not __get_user_fn()") >>

Re: [lkp-robot] [asm] c1aad8dcc4: BUG:kernel_hang_in_boot_stage

On 05/16, Al Viro wrote: >On Tue, May 16, 2017 at 09:19:57AM +0800, kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: c1aad8dcc49382399f48541dc47b6e30b0ef1b62 ("asm-generic: zero in >> __get_user(), not __get_user_fn()") >>

Re: [PATCH v11 11/12] uapi: export all arch specifics directories

Hi Dan, 2017-05-16 10:15 GMT+09:00 Dan Williams : > On Mon, May 15, 2017 at 6:02 PM, Dan Williams > wrote: >> On Mon, Mar 27, 2017 at 5:20 AM, Nicolas Dichtel >> wrote: >>> This patch removes the need of subdir-y.

Re: [PATCH v11 11/12] uapi: export all arch specifics directories

Hi Dan, 2017-05-16 10:15 GMT+09:00 Dan Williams : > On Mon, May 15, 2017 at 6:02 PM, Dan Williams > wrote: >> On Mon, Mar 27, 2017 at 5:20 AM, Nicolas Dichtel >> wrote: >>> This patch removes the need of subdir-y. Now all files/directories under >>> arch//include/uapi/ are exported. >>> >>>

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On Mon, May 15, 2017 at 9:34 PM, Dmitry Vyukov wrote: > On Mon, May 15, 2017 at 6:16 PM, wrote: >> From: Joonsoo Kim >> >> Hello, all. >> >> This is an attempt to recude memory consumption of KASAN. Please see >> following

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On Mon, May 15, 2017 at 9:34 PM, Dmitry Vyukov wrote: > On Mon, May 15, 2017 at 6:16 PM, wrote: >> From: Joonsoo Kim >> >> Hello, all. >> >> This is an attempt to recude memory consumption of KASAN. Please see >> following description to get the more information. >> >> 1. What is per-page

Re: frv build failure in mainline kernel

On 05/15/2017 12:13 PM, Matthias Kaehlcke wrote: El Mon, May 15, 2017 at 10:02:15AM -0700 Guenter Roeck ha dit: Hi all, frv fails to build in mainline with the following build errors. kernel/built-in.o: In function `__do_softirq': (.text+0x6460): relocation truncated to fit: R_FRV_GPREL12

Re: frv build failure in mainline kernel

On 05/15/2017 12:13 PM, Matthias Kaehlcke wrote: El Mon, May 15, 2017 at 10:02:15AM -0700 Guenter Roeck ha dit: Hi all, frv fails to build in mainline with the following build errors. kernel/built-in.o: In function `__do_softirq': (.text+0x6460): relocation truncated to fit: R_FRV_GPREL12

[PATCH] kbuild: skip header install/check for right under uapi directories

Since commit 61562f981e92 ("uapi: export all arch specifics directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install" deletes standard glibc headers and others in ${root}/usr/include. The cause of the issue is that headers_install now starts descending from arch/$(hdr-arch)/include/uapi

[PATCH] kbuild: skip header install/check for right under uapi directories

Since commit 61562f981e92 ("uapi: export all arch specifics directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install" deletes standard glibc headers and others in ${root}/usr/include. The cause of the issue is that headers_install now starts descending from arch/$(hdr-arch)/include/uapi

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On Mon, May 15, 2017 at 6:16 PM, wrote: > From: Joonsoo Kim > > Hello, all. > > This is an attempt to recude memory consumption of KASAN. Please see > following description to get the more information. > > 1. What is per-page shadow memory Hi Joonsoo,

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On Mon, May 15, 2017 at 6:16 PM, wrote: > From: Joonsoo Kim > > Hello, all. > > This is an attempt to recude memory consumption of KASAN. Please see > following description to get the more information. > > 1. What is per-page shadow memory Hi Joonsoo, First I need to say that this is great

Re: [PATCH v8 0/4] Broadcom SBA RAID support

On Mon, May 15, 2017 at 10:34:51AM +0530, Anup Patel wrote: > The Broadcom SBA RAID is a stream-based device which provides > RAID5/6 offload. > > It requires a SoC specific ring manager (such as Broadcom FlexRM > ring manager) to provide ring-based programming interface. Due to > this, the

Re: [PATCH v8 0/4] Broadcom SBA RAID support

On Mon, May 15, 2017 at 10:34:51AM +0530, Anup Patel wrote: > The Broadcom SBA RAID is a stream-based device which provides > RAID5/6 offload. > > It requires a SoC specific ring manager (such as Broadcom FlexRM > ring manager) to provide ring-based programming interface. Due to > this, the

Re: [alsa-devel] [PATCH v2 2/2] dmaengine: dw: Remove AVR32 bits from the driver

On Mon, May 15, 2017 at 05:09:13PM +0200, Takashi Iwai wrote: > On Mon, 15 May 2017 16:49:40 +0200, > Vinod Koul wrote: > > > > On Mon, May 15, 2017 at 11:43:11AM +0300, Andy Shevchenko wrote: > > > On Sun, 2017-05-14 at 18:34 +0530, Vinod Koul wrote: > > > > On Tue, May 09, 2017 at 07:18:37PM

Re: [alsa-devel] [PATCH v2 2/2] dmaengine: dw: Remove AVR32 bits from the driver

On Mon, May 15, 2017 at 05:09:13PM +0200, Takashi Iwai wrote: > On Mon, 15 May 2017 16:49:40 +0200, > Vinod Koul wrote: > > > > On Mon, May 15, 2017 at 11:43:11AM +0300, Andy Shevchenko wrote: > > > On Sun, 2017-05-14 at 18:34 +0530, Vinod Koul wrote: > > > > On Tue, May 09, 2017 at 07:18:37PM

[4.12 regression] "cpufreq: intel_pstate: Active mode P-state limits rework"

  Hi,   With 4.12-rc1 (Linus git), booting fails due to kernel panic, at intel_pstate_register_driver+0x56/0x110. I can't copy the whole trace from the graphic console, it looks like below.   Call Trace: intel_pstate_init intel_pstate_setup do_one_initcall set_debug_rodata

[4.12 regression] "cpufreq: intel_pstate: Active mode P-state limits rework"

  Hi,   With 4.12-rc1 (Linus git), booting fails due to kernel panic, at intel_pstate_register_driver+0x56/0x110. I can't copy the whole trace from the graphic console, it looks like below.   Call Trace: intel_pstate_init intel_pstate_setup do_one_initcall set_debug_rodata

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

Hi Al, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc1 next-20170515] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

Hi Al, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc1 next-20170515] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/15/2017 07:10 PM, Peter Dolding wrote: On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote: O> I'm not implying that my patch is supposed to provide safety for "hundreds of other" issues. I'm looking to provide a way to lock down a single TTY ioctl that has

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/15/2017 07:10 PM, Peter Dolding wrote: On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote: O> I'm not implying that my patch is supposed to provide safety for "hundreds of other" issues. I'm looking to provide a way to lock down a single TTY ioctl that has caused real security issues to

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

Hi Al, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc1 next-20170515] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

Hi Al, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc1 next-20170515] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next

[PATCH net v2] net: x25: fix one potential use-after-free issue

The function x25_init is not properly unregister related resources on error handler.It is will result in kernel oops if x25_init init failed, so add properly unregister call on error handler. Also, i adjust the coding style and make x25_register_sysctl properly return failure. Signed-off-by:

[PATCH net v2] net: x25: fix one potential use-after-free issue

The function x25_init is not properly unregister related resources on error handler.It is will result in kernel oops if x25_init init failed, so add properly unregister call on error handler. Also, i adjust the coding style and make x25_register_sysctl properly return failure. Signed-off-by:

Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to function

On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote: On 05/12/2017 08:37 AM, Quentin Schulz wrote: Hi all, On 05/05/2017 15:50, Quentin Schulz wrote: To avoid possible ECC/parity checksum errors when reading an uninitialized buffer, the entire Message RAM is initialized when probing the driver.

Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to function

On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote: On 05/12/2017 08:37 AM, Quentin Schulz wrote: Hi all, On 05/05/2017 15:50, Quentin Schulz wrote: To avoid possible ECC/parity checksum errors when reading an uninitialized buffer, the entire Message RAM is initialized when probing the driver.

Re: [RFC/RFT PATCH 3/3] PCI/ACPI: Add ACPI pci_bus_find_numa_node() implementation

On 2017/5/15 17:17, Lorenzo Pieralisi wrote: > On Mon, May 15, 2017 at 02:13:47PM +0800, Zhou Wang wrote: >> On 2017/4/26 18:06, Lorenzo Pieralisi wrote: >>> The introduction of pci_bus_find_numa_node(pci_bus) allows at PCI >>> host bridge registration to detect the NUMA node for a given >>>

Re: [RFC/RFT PATCH 3/3] PCI/ACPI: Add ACPI pci_bus_find_numa_node() implementation

On 2017/5/15 17:17, Lorenzo Pieralisi wrote: > On Mon, May 15, 2017 at 02:13:47PM +0800, Zhou Wang wrote: >> On 2017/4/26 18:06, Lorenzo Pieralisi wrote: >>> The introduction of pci_bus_find_numa_node(pci_bus) allows at PCI >>> host bridge registration to detect the NUMA node for a given >>>

RE: Good day

Good day I av' been trying to reach you, contact me --> jeanettewon...@outlook.com for details

RE: Good day

Good day I av' been trying to reach you, contact me --> jeanettewon...@outlook.com for details

Re: [PATCH 08/18] xen/pvcalls: implement connect command

On 05/15/2017 04:36 PM, Stefano Stabellini wrote: Allocate a socket. Keep track of socket <-> ring mappings with a new data structure, called sock_mapping. Implement the connect command by calling inet_stream_connect, and mapping the new indexes page and data ring. Associate the socket to an

Re: [PATCH 08/18] xen/pvcalls: implement connect command

On 05/15/2017 04:36 PM, Stefano Stabellini wrote: Allocate a socket. Keep track of socket <-> ring mappings with a new data structure, called sock_mapping. Implement the connect command by calling inet_stream_connect, and mapping the new indexes page and data ring. Associate the socket to an

Re: [PATCH v5 2/3] KASLR: Handle memory limit specified by memmap and mem option

On 05/16/17 at 09:43am, Dou Liyang wrote: > > > At 05/16/2017 09:12 AM, Baoquan He wrote: > > On 05/16/17 at 08:56am, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 05/13/2017 01:46 PM, Baoquan He wrote: > > > > Option mem= will limit the max address a system can use and any memory > > > >

Re: [PATCH v5 2/3] KASLR: Handle memory limit specified by memmap and mem option

On 05/16/17 at 09:43am, Dou Liyang wrote: > > > At 05/16/2017 09:12 AM, Baoquan He wrote: > > On 05/16/17 at 08:56am, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 05/13/2017 01:46 PM, Baoquan He wrote: > > > > Option mem= will limit the max address a system can use and any memory > > > >

[PATCH v3] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE

From: Wei-Ning Huang Some EC chip has larger flash sector size which requires longer erase time. During erase the CPU is usually stalled and can't even respond to interrupts. We sleep a while to block any EC command from executing during the flash erase period.

[PATCH v3] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE

From: Wei-Ning Huang Some EC chip has larger flash sector size which requires longer erase time. During erase the CPU is usually stalled and can't even respond to interrupts. We sleep a while to block any EC command from executing during the flash erase period. Signed-off-by: Wei-Ning Huang

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

Hello Minchan, On (05/16/17 10:59), Minchan Kim wrote: > Hi Sergey, > [..] > You mean this? > > static void zram_free_page(..) { > if (zram_test_flag(zram, index, ZRAM_SAME)) > ... > > if (!entry) > return; > > if

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

Hello Minchan, On (05/16/17 10:59), Minchan Kim wrote: > Hi Sergey, > [..] > You mean this? > > static void zram_free_page(..) { > if (zram_test_flag(zram, index, ZRAM_SAME)) > ... > > if (!entry) > return; > > if

Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

On Fri, May 12, 2017 at 07:00:29PM -0500, Rob Herring wrote: > On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote: > > This adds a binding for the Maxim/Dallas DS1374 MFD. > > > > Signed-off-by: Moritz Fischer > > --- > > > > Hi all, > > > > I'm not entirely sure

Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

On Fri, May 12, 2017 at 07:00:29PM -0500, Rob Herring wrote: > On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote: > > This adds a binding for the Maxim/Dallas DS1374 MFD. > > > > Signed-off-by: Moritz Fischer > > --- > > > > Hi all, > > > > I'm not entirely sure aobut the binding,

Re: [PATCH 07/18] xen/pvcalls: implement socket command

On 05/15/2017 04:35 PM, Stefano Stabellini wrote: Just reply with success to the other end for now. Delay the allocation of the actual socket to bind and/or connect. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com ---

Re: [PATCH 07/18] xen/pvcalls: implement socket command

On 05/15/2017 04:35 PM, Stefano Stabellini wrote: Just reply with success to the other end for now. Delay the allocation of the actual socket to bind and/or connect. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 31

Re: [PATCH 2/4] ftrace/instances: Clear function triggers when removing instances

On Sun, 14 May 2017 01:01:02 +0530 "Naveen N. Rao" wrote: > If instance directories are deleted while there are registered function > triggers: > > # cd /sys/kernel/debug/tracing/instances > # mkdir test > # echo "schedule:enable_event:sched:sched_switch"

Re: [PATCH 2/4] ftrace/instances: Clear function triggers when removing instances

On Sun, 14 May 2017 01:01:02 +0530 "Naveen N. Rao" wrote: > If instance directories are deleted while there are registered function > triggers: > > # cd /sys/kernel/debug/tracing/instances > # mkdir test > # echo "schedule:enable_event:sched:sched_switch" > test/set_ftrace_filter > #

Re: [PATCH 06/18] xen/pvcalls: handle commands from the frontend

On 05/15/2017 04:35 PM, Stefano Stabellini wrote: When the other end notifies us that there are commands to be read (pvcalls_back_event), wake up the backend thread to parse the command. The command ring works like most other Xen rings, so use the usual ring macros to read and write to it.

Re: [PATCH 06/18] xen/pvcalls: handle commands from the frontend

On 05/15/2017 04:35 PM, Stefano Stabellini wrote: When the other end notifies us that there are commands to be read (pvcalls_back_event), wake up the backend thread to parse the command. The command ring works like most other Xen rings, so use the usual ring macros to read and write to it.

  1   2   3   4   5   6   7   8   9   10   >