Re: [PATCH 20/32] magic number for rscctrl file system

On 12 July 2016 at 20:02, Fenghua Yu wrote: > From: Fenghua Yu > > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck > --- > include/uapi/linux/magic.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff

Re: [PATCH 20/32] magic number for rscctrl file system

On 12 July 2016 at 20:02, Fenghua Yu wrote: > From: Fenghua Yu > > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck > --- > include/uapi/linux/magic.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h > index 546b388..655036a

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote: > On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > > it looks like your patch "random: make /dev/urandom scalable for silly > > userspace programs" within linux-next seems to be a bit broken: > > > > It causes this

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote: > On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > > it looks like your patch "random: make /dev/urandom scalable for silly > > userspace programs" within linux-next seems to be a bit broken: > > > > It causes this

Re: bcache super block corruption with non 4k pages

On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote: > So here is another attempt which does half the proposed changes. And before > you > point out that it looks still ugly, let me explain some reasons. The goal for > me > would be to have something as small as possible to be

Re: bcache super block corruption with non 4k pages

On Wed, Jul 27, 2016 at 05:16:36PM +0200, Stefan Bader wrote: > So here is another attempt which does half the proposed changes. And before > you > point out that it looks still ugly, let me explain some reasons. The goal for > me > would be to have something as small as possible to be

Re: [PATCH 19/32] sched.h: Add rg_list and rdtgroup in task_struct

On 12 July 2016 at 20:02, Fenghua Yu wrote: > From: Fenghua Yu > > rg_list is linked list to connect to other tasks in a rdtgroup. > > The point of rdtgroup allows the task to access its own rdtgroup directly. > > Signed-off-by: Fenghua Yu

Re: [PATCH 19/32] sched.h: Add rg_list and rdtgroup in task_struct

On 12 July 2016 at 20:02, Fenghua Yu wrote: > From: Fenghua Yu > > rg_list is linked list to connect to other tasks in a rdtgroup. > > The point of rdtgroup allows the task to access its own rdtgroup directly. > > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck > --- >

Re: staging: lustre: One function call less in class_register_type() after error detection

> This function is called several times during lustre module insert. > Namely it's called 5 times for 5 types: > osc, mdc, lov, lmv, mgc. Will any extra memory accesses matter for the successful execution in this use case? > It's not called any more than that, so it's not exactly a super

Re: staging: lustre: One function call less in class_register_type() after error detection

> This function is called several times during lustre module insert. > Namely it's called 5 times for 5 types: > osc, mdc, lov, lmv, mgc. Will any extra memory accesses matter for the successful execution in this use case? > It's not called any more than that, so it's not exactly a super

Re: [PATCH 1/3] Add a new field to struct shrinker

[line wrap text at 72 columns, please] On Tue, Jul 26, 2016 at 09:40:57AM -0700, Tony Jones wrote: > On 07/20/2016 07:54 AM, Michal Hocko wrote: > >On Wed 20-07-16 20:11:09, Janani Ravichandran wrote: > >>>On Jul 11, 2016, at 8:03 PM, Michal Hocko wrote: > >>>On Mon 11-07-16

Re: [PATCH 1/3] Add a new field to struct shrinker

[line wrap text at 72 columns, please] On Tue, Jul 26, 2016 at 09:40:57AM -0700, Tony Jones wrote: > On 07/20/2016 07:54 AM, Michal Hocko wrote: > >On Wed 20-07-16 20:11:09, Janani Ravichandran wrote: > >>>On Jul 11, 2016, at 8:03 PM, Michal Hocko wrote: > >>>On Mon 11-07-16 10:12:51, Rik van

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

On Wed, 2016-07-27 at 14:38 -0700, Jeff Kirsher wrote: > On Tue, 2016-07-26 at 11:14 +0200, Eric Dumazet wrote: > > Could you try this ? > > > > diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c > > b/drivers/net/ethernet/intel/e1000/e1000_main.c > > index > >

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

On Wed, 2016-07-27 at 14:38 -0700, Jeff Kirsher wrote: > On Tue, 2016-07-26 at 11:14 +0200, Eric Dumazet wrote: > > Could you try this ? > > > > diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c > > b/drivers/net/ethernet/intel/e1000/e1000_main.c > > index > >

Re: [PATCH 17/32] x86, intel_cacheinfo: Enable cache id in x86

On 12 July 2016 at 20:02, Fenghua Yu wrote: > From: Fenghua Yu > > Enable cache id in x86. Cache id comes from APIC ID and CPUID4. > I think one of these patches on cache ids should refer to some documentation from Intel on this subject, either in the

Re: [PATCH 17/32] x86, intel_cacheinfo: Enable cache id in x86

On 12 July 2016 at 20:02, Fenghua Yu wrote: > From: Fenghua Yu > > Enable cache id in x86. Cache id comes from APIC ID and CPUID4. > I think one of these patches on cache ids should refer to some documentation from Intel on this subject, either in the commit message or in the comments in some

Re: [PATCH 6/7] qemu: Implement virtio-pstore device

On Thu, Jul 28, 2016 at 03:02:54AM +0300, Michael S. Tsirkin wrote: > On Thu, Jul 28, 2016 at 12:08:30AM +0900, Namhyung Kim wrote: > > Add virtio pstore device to allow kernel log files saved on the host. > > It will save the log files on the directory given by pstore device > > option. > > > >

Re: [PATCH 6/7] qemu: Implement virtio-pstore device

On Thu, Jul 28, 2016 at 03:02:54AM +0300, Michael S. Tsirkin wrote: > On Thu, Jul 28, 2016 at 12:08:30AM +0900, Namhyung Kim wrote: > > Add virtio pstore device to allow kernel log files saved on the host. > > It will save the log files on the directory given by pstore device > > option. > > > >

[GIT PULL] libnvdimm for 4.8

Hi Linus, please pull from:   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-4.8 ...to receive the libnvdimm update for 4.8. This has been in -next with the following reported conflicts: 1/ The __pmem address space has been removed.  New usages of __pmem came

[GIT PULL] libnvdimm for 4.8

Hi Linus, please pull from:   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-4.8 ...to receive the libnvdimm update for 4.8. This has been in -next with the following reported conflicts: 1/ The __pmem address space has been removed.  New usages of __pmem came

RE: [virtio-dev] Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7da61ad..3ad8b10 > > 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void) } > > EXPORT_SYMBOL(get_max_pfn); > > > > +static void mark_free_pages_bitmap(struct zone *zone,

RE: [virtio-dev] Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7da61ad..3ad8b10 > > 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void) } > > EXPORT_SYMBOL(get_max_pfn); > > > > +static void mark_free_pages_bitmap(struct zone *zone,

[GIT PULL]: dmaengine update for 4.8-rc1

Hello Linus, Here is the PULL request for 4.8-rc1. Two new drivers, bunch of updates and cleanups to existing set. Nothing super exciting though. The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git

[GIT PULL]: dmaengine update for 4.8-rc1

Hello Linus, Here is the PULL request for 4.8-rc1. Two new drivers, bunch of updates and cleanups to existing set. Nothing super exciting though. The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git

Re: lib/mpi: BUG: sleeping function called from invalid context on next-20160726

On Wed, Jul 27, 2016 at 11:05:05PM +0200, Nicolai Stange wrote: > > with linux-next-20160726, I get this: > > BUG: sleeping function called from invalid context at > /mnt/scratch/nic/linux-next/mm/slab.h:388 Does this patch help? > I would have sent a patch, but there is another point which

Re: lib/mpi: BUG: sleeping function called from invalid context on next-20160726

On Wed, Jul 27, 2016 at 11:05:05PM +0200, Nicolai Stange wrote: > > with linux-next-20160726, I get this: > > BUG: sleeping function called from invalid context at > /mnt/scratch/nic/linux-next/mm/slab.h:388 Does this patch help? > I would have sent a patch, but there is another point which

Re: RFC: using worker threadpool to speed up clear_huge_page() by up to 5x

From: kpusukur Date: Sun, 17 Jul 2016 12:35:20 -0700 > We would welcome feedback and discussion of potential problems. > > We would also like to hear ideas for other areas in the kernel where a > similar technique could be employed. For example, we've also

Re: RFC: using worker threadpool to speed up clear_huge_page() by up to 5x

From: kpusukur Date: Sun, 17 Jul 2016 12:35:20 -0700 > We would welcome feedback and discussion of potential problems. > > We would also like to hear ideas for other areas in the kernel where a > similar technique could be employed. For example, we've also applied > this idea to copy on write

linux-next: Tree for Jul 28

Hi all, Please do not add material destined for v4.9 to your linux-next included branches until after v4.8-rc1 has been released. Changes since 20160727: The powerpc tree lost its build failure. The kbuild tree gained a conflict against Linus' tree and a build failure due to an interaction

linux-next: Tree for Jul 28

Hi all, Please do not add material destined for v4.9 to your linux-next included branches until after v4.8-rc1 has been released. Changes since 20160727: The powerpc tree lost its build failure. The kbuild tree gained a conflict against Linus' tree and a build failure due to an interaction

[PATCH 1/2] tracing: Add latency histograms

From: Carsten Emde This patch provides a recording mechanism to store data of potential sources of system latencies. The recordings separately determine the latency caused by a delayed timer expiration, by a delayed wakeup of the related user space program and by the sum of

[PATCH 2/2] trace: Add missing tracer macros

From: Yang Shi When building rt kernel with IRQSOFF_TRACER enabled but INTERRUPT_OFF_HIST or PREEMPT_OFF_HIST disabled, the below build failure will be triggered: | kernel/trace/trace_irqsoff.c: In function 'time_hardirqs_on': | kernel/trace/trace_irqsoff.c:453:2: error:

[PATCH 1/2] tracing: Add latency histograms

From: Carsten Emde This patch provides a recording mechanism to store data of potential sources of system latencies. The recordings separately determine the latency caused by a delayed timer expiration, by a delayed wakeup of the related user space program and by the sum of both. The histograms

[PATCH 2/2] trace: Add missing tracer macros

From: Yang Shi When building rt kernel with IRQSOFF_TRACER enabled but INTERRUPT_OFF_HIST or PREEMPT_OFF_HIST disabled, the below build failure will be triggered: | kernel/trace/trace_irqsoff.c: In function 'time_hardirqs_on': | kernel/trace/trace_irqsoff.c:453:2: error: implicit declaration of

[PATCH 0/2] *** Latency Histogram ***

Hi, I was looking at these RT kernel patches and was wondering why it has not been upstreamed yet. I have made a few changes to these patches to make it compliant with upstream submission process. Also did a minimal testing on my msm board. Can some one from rt kernel team shed some light on why

[PATCH 0/2] *** Latency Histogram ***

Hi, I was looking at these RT kernel patches and was wondering why it has not been upstreamed yet. I have made a few changes to these patches to make it compliant with upstream submission process. Also did a minimal testing on my msm board. Can some one from rt kernel team shed some light on why

Re: [PATCH] dmaengine: device must have at least one channel

On 28-07-16, 09:18, Vinod Koul wrote: > On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote: > > The DMA device can't be registered if it doesn't have any channels > > registered at all. Moreover, it leads to memory leak and is reported by > > kmemleak as (on 3.10 kernel, and same shall

Re: [PATCH] dmaengine: device must have at least one channel

On 28-07-16, 09:18, Vinod Koul wrote: > On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote: > > The DMA device can't be registered if it doesn't have any channels > > registered at all. Moreover, it leads to memory leak and is reported by > > kmemleak as (on 3.10 kernel, and same shall

[PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated

We blindly trust the hardware to give us NUL-terminated strings, which is a bad idea because it doesn't always do that. For example: [ 481.184784] mpt3sas_cm0: enclosure level(0x), connector name( \x3) In this case, connector_name is four spaces. We got lucky here because the 2nd

[PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated

We blindly trust the hardware to give us NUL-terminated strings, which is a bad idea because it doesn't always do that. For example: [ 481.184784] mpt3sas_cm0: enclosure level(0x), connector name( \x3) In this case, connector_name is four spaces. We got lucky here because the 2nd

Re: [RFC 4/4] Restartable sequences: Add self-tests for PPC

On Thu, Jul 28, 2016 at 02:59:45AM +, Mathieu Desnoyers wrote: > - On Jul 27, 2016, at 11:05 AM, Boqun Feng boqun.f...@gmail.com wrote: > > > As rseq syscall is enabled on PPC, implement the self-tests on PPC to > > verify the implementation of the syscall. > > > > Please note we only

Re: [RFC 4/4] Restartable sequences: Add self-tests for PPC

On Thu, Jul 28, 2016 at 02:59:45AM +, Mathieu Desnoyers wrote: > - On Jul 27, 2016, at 11:05 AM, Boqun Feng boqun.f...@gmail.com wrote: > > > As rseq syscall is enabled on PPC, implement the self-tests on PPC to > > verify the implementation of the syscall. > > > > Please note we only

RE: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote: > > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote: > >> On 07/26/2016 06:23 PM, Liang Li wrote: > >>> + for_each_migratetype_order(order, t) { > >>> + list_for_each(curr, >free_area[order].free_list[t]) { > >>> +

RE: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote: > > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote: > >> On 07/26/2016 06:23 PM, Liang Li wrote: > >>> + for_each_migratetype_order(order, t) { > >>> + list_for_each(curr, >free_area[order].free_list[t]) { > >>> +

[PATCH v3 1/2] tpm: devicetree: document properties for cr50

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 firmware. Signed-off-by: Andrey Pronin --- .../devicetree/bindings/security/tpm/cr50_spi.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644

[PATCH v3 1/2] tpm: devicetree: document properties for cr50

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 firmware. Signed-off-by: Andrey Pronin --- .../devicetree/bindings/security/tpm/cr50_spi.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644

[PATCH v3 2/2] tpm: add driver for cr50 on SPI

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 firmware. The firmware running on the currently supported H1 Secure Microcontroller requires a special driver to handle its specifics: - need to ensure a certain delay between spi transactions, or else the chip may miss some part

[PATCH v3 2/2] tpm: add driver for cr50 on SPI

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 firmware. The firmware running on the currently supported H1 Secure Microcontroller requires a special driver to handle its specifics: - need to ensure a certain delay between spi transactions, or else the chip may miss some part

[PATCH v3 0/2] tpm: add driver for cr50 on SPI

This patchset adds support for H1 Secure Microcontroller running Cr50 firmware. It implements several functions, including TPM-like functionality, and communicates over SPI using the FIFO protocol described in the PTP Spec, section 6. H1 is a proprietary chip that the Chrome OS team is

[PATCH v3 0/2] tpm: add driver for cr50 on SPI

This patchset adds support for H1 Secure Microcontroller running Cr50 firmware. It implements several functions, including TPM-like functionality, and communicates over SPI using the FIFO protocol described in the PTP Spec, section 6. H1 is a proprietary chip that the Chrome OS team is

Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

Hi Linus, about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"): Good! Finally! This thing was really getting on my nerves. Btw, I tried at the time to move it to W=1 insted of completely disabling it, see below. That got nowhere though. On Mon, Jul 07, 2014 at 12:53:39PM

Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

Hi Linus, about 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"): Good! Finally! This thing was really getting on my nerves. Btw, I tried at the time to move it to W=1 insted of completely disabling it, see below. That got nowhere though. On Mon, Jul 07, 2014 at 12:53:39PM

[PATCH v3] tpm: add sysfs attributes for tpm2

Add sysfs attributes in TPM2.0 case for: - TPM_PT_PERMANENT flags - TPM_PT_STARTUP_CLEAR flags - lockout-related properties v2: Dropped adding driver-specific attributes. No legacy links for TPM2 attributes. All attributes created in groups[0]. Added actual attributes for flags and

[PATCH v3] tpm: add sysfs attributes for tpm2

Add sysfs attributes in TPM2.0 case for: - TPM_PT_PERMANENT flags - TPM_PT_STARTUP_CLEAR flags - lockout-related properties v2: Dropped adding driver-specific attributes. No legacy links for TPM2 attributes. All attributes created in groups[0]. Added actual attributes for flags and

[patch-rt] scsi/fcoe: Fix get_cpu()/put_cpu_light() imbalance in fcoe_recv_frame()

During master->rt merge, I stumbled across the buglet below. Fix get_cpu()/put_cpu_light() imbalance. Signed-off-by: Mike Gabraith --- drivers/scsi/fcoe/fcoe.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/fcoe/fcoe.c +++

[patch-rt] scsi/fcoe: Fix get_cpu()/put_cpu_light() imbalance in fcoe_recv_frame()

During master->rt merge, I stumbled across the buglet below. Fix get_cpu()/put_cpu_light() imbalance. Signed-off-by: Mike Gabraith --- drivers/scsi/fcoe/fcoe.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/fcoe/fcoe.c +++ b/drivers/scsi/fcoe/fcoe.c @@ -1814,7

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:33 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds > wrote: > > I'd actually prefer to make "--git" the default, if you are inside a > > git repository. Because obviously the *actual* default is too hard to >

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:33 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds > wrote: > > I'd actually prefer to make "--git" the default, if you are inside a > > git repository. Because obviously the *actual* default is too hard to > > understand ;) Well, you are

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

On Wed, 27 Jul 2016 20:21:50 -0700 Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt wrote: > > On Wed, 27 Jul 2016 16:00:54 -0700 > > Linus Torvalds wrote: > >> > >> I can just add a >

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

On Wed, 27 Jul 2016 20:21:50 -0700 Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt wrote: > > On Wed, 27 Jul 2016 16:00:54 -0700 > > Linus Torvalds wrote: > >> > >> I can just add a > >> > >> KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,) > > > > I

[PATCH v3 1/2] tpm_tis_core: add optional max xfer size check

If tpm reports a bigger burstcnt than allowed by the physical protocol, set burstcnt to the max allowed value. In practice, seen in case of xfer issues (e.g. in spi interface case, lost header causing flow control issues and wrong values returned on read from TPM_STS). Without catching, causes

[PATCH v3 1/2] tpm_tis_core: add optional max xfer size check

If tpm reports a bigger burstcnt than allowed by the physical protocol, set burstcnt to the max allowed value. In practice, seen in case of xfer issues (e.g. in spi interface case, lost header causing flow control issues and wrong values returned on read from TPM_STS). Without catching, causes

[PATCH v3 2/2] tpm_tis_spi: add max xfer size

Reject burstcounts larger than 64 bytes reported by tpm. SPI Hardware Protocol defined in section 6.4 of TCG PTP Spec supports up to 64 bytes of data in a transaction. Signed-off-by: Andrey Pronin --- drivers/char/tpm/tpm_tis_spi.c | 1 + 1 file changed, 1 insertion(+)

[PATCH v3 2/2] tpm_tis_spi: add max xfer size

Reject burstcounts larger than 64 bytes reported by tpm. SPI Hardware Protocol defined in section 6.4 of TCG PTP Spec supports up to 64 bytes of data in a transaction. Signed-off-by: Andrey Pronin --- drivers/char/tpm/tpm_tis_spi.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v3 0/2] tpm: add optional max xfer size check

This patchset introduces an optional maximum transfer size that can be specified by a tpm driver. Setting the max_xfer_size helps to catch the cases when burstcnt is incorrectly reported by the device (e.g. >64 for spi - happened in practice) and gracefully handle such situations. v2: removed

[PATCH v3 0/2] tpm: add optional max xfer size check

This patchset introduces an optional maximum transfer size that can be specified by a tpm driver. Setting the max_xfer_size helps to catch the cases when burstcnt is incorrectly reported by the device (e.g. >64 for spi - happened in practice) and gracefully handle such situations. v2: removed

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > +/* > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap > > + * to prevent a very large page bitmap, there are two reasons for this: > > + * 1) to save memory. > > + * 2) allocate a large bitmap may fail. > > + * > > + * The actual limit of pfn is determined by: > > + *

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > +/* > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap > > + * to prevent a very large page bitmap, there are two reasons for this: > > + * 1) to save memory. > > + * 2) allocate a large bitmap may fail. > > + * > > + * The actual limit of pfn is determined by: > > + *

[REGRESSION] wlcore wlcore_op_get_expected_throughput null ptr dereference

So after rebasing my HiKey tree ontop of Linus' HEAD today, I started having trouble with the wlcore wifi. The first issue was that the firmware I was using was deemed too old, but after updating to .69, I then started hitting null pointer crashes when wifi was initialized. [7.326224]

[REGRESSION] wlcore wlcore_op_get_expected_throughput null ptr dereference

So after rebasing my HiKey tree ontop of Linus' HEAD today, I started having trouble with the wlcore wifi. The first issue was that the firmware I was using was deemed too old, but after updating to .69, I then started hitting null pointer crashes when wifi was initialized. [7.326224]

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > it looks like your patch "random: make /dev/urandom scalable for silly > userspace programs" within linux-next seems to be a bit broken: > > It causes this allocation failure and subsequent crash on s390 with fake > NUMA enabled

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > it looks like your patch "random: make /dev/urandom scalable for silly > userspace programs" within linux-next seems to be a bit broken: > > It causes this allocation failure and subsequent crash on s390 with fake > NUMA enabled

Re: [PATCH] dmaengine: device must have at least one channel

On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote: > The DMA device can't be registered if it doesn't have any channels > registered at all. Moreover, it leads to memory leak and is reported by > kmemleak as (on 3.10 kernel, and same shall happen on mainline): > > unreferenced object

Re: [PATCH] dmaengine: device must have at least one channel

On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote: > The DMA device can't be registered if it doesn't have any channels > registered at all. Moreover, it leads to memory leak and is reported by > kmemleak as (on 3.10 kernel, and same shall happen on mainline): > > unreferenced object

Re: [PATCH v2 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

Hi, Philipp, Thanks for your comments. On Wed, 2016-07-27 at 11:23 +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh: > > From: Junzhi Zhao > > > > Pixel clock should be 297MHz when resolution is 4K. > > This patch does two

Re: [PATCH v2 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

Hi, Philipp, Thanks for your comments. On Wed, 2016-07-27 at 11:23 +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh: > > From: Junzhi Zhao > > > > Pixel clock should be 297MHz when resolution is 4K. > > This patch does two different things, please

Re: [PATCH v11] acpi, apei, arm64: APEI initial support for aarch64.

Hi Rafael, On 28 July 2016 at 07:12, Rafael J. Wysocki wrote: > On Thursday, July 28, 2016 01:29:05 AM fu@linaro.org wrote: >> From: Tomasz Nowicki >> >> This commit provides APEI arch-specific bits for aarch64 >> >> Meanwhile, >> (1)add a new

Re: [PATCH v11] acpi, apei, arm64: APEI initial support for aarch64.

Hi Rafael, On 28 July 2016 at 07:12, Rafael J. Wysocki wrote: > On Thursday, July 28, 2016 01:29:05 AM fu@linaro.org wrote: >> From: Tomasz Nowicki >> >> This commit provides APEI arch-specific bits for aarch64 >> >> Meanwhile, >> (1)add a new subfunction "hest_ia32_init" for >>

Re: [PATCH v2 2/3] drm/mediatek: enhance the HDMI driving current

Hi, Philipp, Thanks for your review. On Wed, 2016-07-27 at 11:25 +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh: > > From: Junzhi Zhao > > > > In order to improve 4K resolution performance, > > we have to enhance the HDMI

Re: [PATCH v2 2/3] drm/mediatek: enhance the HDMI driving current

Hi, Philipp, Thanks for your review. On Wed, 2016-07-27 at 11:25 +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh: > > From: Junzhi Zhao > > > > In order to improve 4K resolution performance, > > we have to enhance the HDMI driving currend >

Re: [PATCH v2 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

Hi, Philipp, Thanks for your review. On Wed, 2016-07-27 at 11:27 +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh: > > From: Junzhi Zhao > > > > The mtk_hdmi_send_infoframe have to > > be run after PLL and PIXEL clock of HDMI

Re: [PATCH v2 1/3] drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable

Hi, Philipp, Thanks for your review. On Wed, 2016-07-27 at 11:27 +0200, Philipp Zabel wrote: > Am Mittwoch, den 27.07.2016, 16:31 +0800 schrieb Bibby Hsieh: > > From: Junzhi Zhao > > > > The mtk_hdmi_send_infoframe have to > > be run after PLL and PIXEL clock of HDMI enable. > > Make sure that

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds wrote: > > I'd actually prefer to make "--git" the default, if you are inside a > git repository. Because obviously the *actual* default is too hard to > understand ;) I'd also like to make the "-f" optional. I

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, Jul 27, 2016 at 8:31 PM, Linus Torvalds wrote: > > I'd actually prefer to make "--git" the default, if you are inside a > git repository. Because obviously the *actual* default is too hard to > understand ;) I'd also like to make the "-f" optional. I constantly forget it, and curse it.

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, Jul 27, 2016 at 8:26 PM, Linus Torvalds wrote: > > Hmm. Fishy. Hmm. The exact match logic is a bit odd, and clearly doesn't mean what I thought it meant. Reading that perl code just makes me more confused. I'd actually prefer to make "--git" the default,

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, Jul 27, 2016 at 8:26 PM, Linus Torvalds wrote: > > Hmm. Fishy. Hmm. The exact match logic is a bit odd, and clearly doesn't mean what I thought it meant. Reading that perl code just makes me more confused. I'd actually prefer to make "--git" the default, if you are inside a git

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:26 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches wrote: > > > > On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: > > > > > > Did you actually try it. > > yes. > Well, in that case the script is buggy. It

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:26 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches wrote: > > > > On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: > > > > > > Did you actually try it. > > yes. > Well, in that case the script is buggy. It self-documents as having >

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate > process > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT; > > > + vb->pfn_limit = min(vb->pfn_limit,

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate > process > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT; > > > + vb->pfn_limit = min(vb->pfn_limit,

Re: [PATCH v1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP need to disable

Sean, Oops, sorry about miss your suggest :( On 07/22/2016 11:03 PM, Sean Paul wrote: On Thu, Jul 21, 2016 at 9:00 PM, Yakir Yang wrote: Sean, Thanks for your fast respond :-) But this patch is not the latest one, I have upgraded this to "v1.1" version to fix the eDP

Re: [PATCH v1 2/2] drm/bridge: analogix_dp: turn off the panel when eDP need to disable

Sean, Oops, sorry about miss your suggest :( On 07/22/2016 11:03 PM, Sean Paul wrote: On Thu, Jul 21, 2016 at 9:00 PM, Yakir Yang wrote: Sean, Thanks for your fast respond :-) But this patch is not the latest one, I have upgraded this to "v1.1" version to fix the eDP can't be disabled

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches wrote: > On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: >> Did you actually try it. > > yes. Well, in that case the script is buggy. It self-documents as having "--git-fallback" on by default, and I'm not seeing anybody

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, Jul 27, 2016 at 8:21 PM, Joe Perches wrote: > On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: >> Did you actually try it. > > yes. Well, in that case the script is buggy. It self-documents as having "--git-fallback" on by default, and I'm not seeing anybody claiming explicit

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches wrote: > > It'll continue to list only Al Viro unless a --git cmdline option > > is specified and almost no one uses that. > Did you actually try it. Sorry about the last

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches wrote: > > It'll continue to list only Al Viro unless a --git cmdline option > > is specified and almost no one uses that. > Did you actually try it. Sorry about the last reply, typing with a

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt wrote: > On Wed, 27 Jul 2016 16:00:54 -0700 > Linus Torvalds wrote: >> >> I can just add a >> >> KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,) > > I like this solution. Ok. Pushed

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

On Wed, Jul 27, 2016 at 6:58 PM, Steven Rostedt wrote: > On Wed, 27 Jul 2016 16:00:54 -0700 > Linus Torvalds wrote: >> >> I can just add a >> >> KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,) > > I like this solution. Ok. Pushed out. As long as people are aware of this, and are

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches wrote: > > > > > > It'll continue to list only Al Viro unless a --git cmdline option > > is specified and almost no one uses that. > Did you actually try it. yes. $

Re: [GIT PULL] binfmt_misc updates for 4.7+ merge window

On Wed, 2016-07-27 at 20:12 -0700, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 7:57 PM, Joe Perches wrote: > > > > > > It'll continue to list only Al Viro unless a --git cmdline option > > is specified and almost no one uses that. > Did you actually try it. yes. $

  1   2   3   4   5   6   7   8   9   10   >