date:20171117

On Fri, Nov 17, 2017 at 12:35 PM, Kees Cook  wrote:
>
> This is why I introduced the fallback mode: with both kvm and sctp
> (ipv6) not noticed until late in the development cycle, I became much
> less satisfied it had gotten sufficient testing.

So honestly, this is the kind of completely unacceptable "security
person" behavior that we had with the original user access hardening
too, and made that much more painful than it ever should have been.

IT IS NOT ACCEPTABLE when security people set magical new rules, and
then make the kernel panic when those new rules are violated.

That is pure and utter bullshit. We've had more than a quarter century
_without_ those rules, you don't then suddenly walz in and say "oh,
everbody must do this, and if you haven't, we will kill the kernel".

The fact that you "introduced the fallback mode" late in that series
just shows HOW INCREDIBLY BROKEN the series started out.

Seriously.

As a security person, you need to repeat this mantra:

  "security problems are just bugs"

and you need to _internalize_ it, instead of scoff at it.

The important part about "just bugs" is that you need to understand
that the patches you then introduce for things like hardening are
primarly for DEBUGGING.

I'm not at all interested in killing processes. The only process I'm
interested in is the _development_ process, where we find bugs and fix
them.

As long as you see your hardening efforts primarily as a "let me kill
the machine/process on bad behavior", I will stop taking those shit
patches.

I'm deadly serious about this.

Some security people have scoffed at me when I say that security
problems are primarily "just bugs".

Those security people are f*cking morons.

Because honestly, the kind of security person who doesn't accept that
security problems are primarily just bugs, I don't want to work with.
If you don't see your job as "debugging first", I'm simply not
interested.

So I think the hardening project needs to really take a good look at
itself in the mirror.

Because the primary focus should be "debugging". The primary focus
should be "let's make sure the kernel released in a year is better
than the one released today".

And the primary focus right now seems to be "let's kill things for
bugs". That's wrong.

And I'm _so_ not interested in that. It makes me go "no, I will not
pull that shit, it's not safe for me, and it's not safe for our
users".

So the hardening efforts should instead _start_ from the standpoint of
"let's warn about what looks dangerous, and maybe in a _year_ when
we've warned for a long time, and we are confident that we've actually
caught all the normal cases, _then_ we can start taking more drastic
measures".

See the difference?

Stop this idiotic "kill on sight, ask questions later".

Because it's wrong.

> I would agree it would be nice to get at least a subset of this in,
> though. Linus, what would make you most comfortable?

Right now, the biggest problem for me is that the whole thing makes me
uncomfortable, because I think the people involved are coming from a
completely unacceptable model to begin with.

And we had this exact issue with the _previous_ user mode access
hardening. People apparently didn't learn a goddamn thing.

 Linus

[PATCH 2/2] iommu/amd: Add support for fast IOTLB flushing

2017-11-17 Thread Suravee Suthikulpanit

From: Suravee Suthikulpanit 

Implement the newly added IOTLB flushing interface by introducing
per-protection-domain IOTLB flush list, which maintains a list of
IOVAs to be invalidated (by INVALIDATE_IOTLB_PAGES command) during
IOTLB sync.

Cc: Joerg Roedel 
Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu.c   | 77 -
 drivers/iommu/amd_iommu_init.c  |  2 --
 drivers/iommu/amd_iommu_types.h |  2 ++
 3 files changed, 78 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 8e8874d..bf92809 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -130,6 +130,12 @@ struct dma_ops_domain {
 static struct iova_domain reserved_iova_ranges;
 static struct lock_class_key reserved_rbtree_key;
 
+struct iotlb_flush_entry {
+   struct list_head list;
+   unsigned long iova;
+   size_t size;
+};
+
 /
  *
  * Helper functions
@@ -2838,11 +2844,13 @@ static void protection_domain_free(struct 
protection_domain *domain)
 static int protection_domain_init(struct protection_domain *domain)
 {
spin_lock_init(>lock);
+   spin_lock_init(>iotlb_flush_list_lock);
mutex_init(>api_lock);
domain->id = domain_id_alloc();
if (!domain->id)
return -ENOMEM;
INIT_LIST_HEAD(>dev_list);
+   INIT_LIST_HEAD(>iotlb_flush_list);
 
return 0;
 }
@@ -3047,7 +3055,6 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom, 
unsigned long iova,
unmap_size = iommu_unmap_page(domain, iova, page_size);
mutex_unlock(>api_lock);
 
-   domain_flush_tlb_pde(domain);
domain_flush_complete(domain);
 
return unmap_size;
@@ -3167,6 +3174,71 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
return dev_data->defer_attach;
 }
 
+static void amd_iommu_flush_iotlb_all(struct iommu_domain *domain)
+{
+   struct protection_domain *dom = to_pdomain(domain);
+
+   domain_flush_tlb_pde(dom);
+}
+
+static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+   struct protection_domain *pdom = to_pdomain(domain);
+   struct iotlb_flush_entry *entry, *p;
+   unsigned long flags;
+   bool found = false;
+
+   spin_lock_irqsave(>iotlb_flush_list_lock, flags);
+   list_for_each_entry(p, >iotlb_flush_list, list) {
+   if (iova != p->iova)
+   continue;
+
+   if (size > p->size) {
+   p->size = size;
+   pr_debug("%s: update range: iova=%#lx, size = %#lx\n",
+__func__, p->iova, p->size);
+   }
+   found = true;
+   break;
+   }
+
+   if (!found) {
+   entry = kzalloc(sizeof(struct iotlb_flush_entry),
+   GFP_ATOMIC);
+   if (!entry)
+   return;
+
+   pr_debug("%s: new range: iova=%lx, size=%#lx\n",
+__func__, iova, size);
+
+   entry->iova = iova;
+   entry->size = size;
+   list_add(>list, >iotlb_flush_list);
+   }
+   spin_unlock_irqrestore(>iotlb_flush_list_lock, flags);
+}
+
+static void amd_iommu_iotlb_sync(struct iommu_domain *domain)
+{
+   struct protection_domain *pdom = to_pdomain(domain);
+   struct iotlb_flush_entry *entry, *next;
+   unsigned long flags;
+
+   /* Note:
+* Currently, IOMMU driver just flushes the whole IO/TLB for
+* a given domain. So, just remove entries from the list here.
+*/
+   spin_lock_irqsave(>iotlb_flush_list_lock, flags);
+   list_for_each_entry_safe(entry, next, >iotlb_flush_list, list) {
+   list_del(>list);
+   kfree(entry);
+   }
+   spin_unlock_irqrestore(>iotlb_flush_list_lock, flags);
+
+   domain_flush_tlb_pde(pdom);
+}
+
 const struct iommu_ops amd_iommu_ops = {
.capable = amd_iommu_capable,
.domain_alloc = amd_iommu_domain_alloc,
@@ -3185,6 +3257,9 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
.apply_resv_region = amd_iommu_apply_resv_region,
.is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap  = AMD_IOMMU_PGSIZES,
+   .flush_iotlb_all = amd_iommu_flush_iotlb_all,
+   .iotlb_range_add = amd_iommu_iotlb_range_add,
+   .iotlb_sync = amd_iommu_iotlb_sync,
 };
 
 /*
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 6fe2d03..1659377 100644
--- a/drivers/iommu/amd_iommu_init.c
+++

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

2017-11-17 Thread Tony Krowiak


On 11/16/2017 11:47 AM, Cornelia Huck wrote:

On Thu, 16 Nov 2017 09:25:27 -0500
Tony Krowiak  wrote:


On 11/16/2017 07:35 AM, Cornelia Huck wrote:

On Thu, 16 Nov 2017 13:02:26 +0100
Pierre Morel  wrote:
  

On 14/11/2017 17:37, Tony Krowiak wrote:

On 11/14/2017 07:40 AM, Cornelia Huck wrote:

On Fri, 13 Oct 2017 13:38:50 -0400
Tony Krowiak  wrote:

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 48af970..411c19a 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -722,6 +722,19 @@ config VFIO_CCW
  To compile this driver as a module, choose M here: the
  module will be called vfio_ccw.
+config VFIO_AP_MATRIX
+def_tristate m
+prompt "Support for Adjunct Processor Matrix device interface"
+depends on ZCRYPT
+select VFIO
+select MDEV
+select VFIO_MDEV
+select VFIO_MDEV_DEVICE
+select IOMMU_API

I think the more common pattern is to depend on the VFIO configs
instead of selecting them.

It's ironic because I originally changed from using 'depends on' and
changed it based on review comments made
on our internal mailing list. I'll go with 'depends on'.

Is doing like the others a sufficient good reason?
What if the first who did this did not really think about it?

When an administrator configure the kernel what does he think?

- I want to have AP through AP_VFIO in my guests
and he get implicitly VFIO
or
- I want to have VFIO
and he has to explicitly add AP_VFIO too

It seems to me that the first is much more user friendly.

Please tell me if I missed something. dependencies? collateral damages?
my logic is wrong?

Using select for anything that's not a simple infrastructure dependency
may lead into trouble (we've had issues in the past where options tried
to enable other options but missed dependencies).

If a user wants to use vfio-ap, I think it is reasonable to expect them
to figure out that they need both ap and vfio for that.

[And config help has gotten much better than it was years ago; it's not
that hard to figure out what is actually needed.]

Is it sufficient to specify 'depends on ZCRYPT && VFIO_MDEV_DEVICE'
since 'VFIO_MDEV_DEVICE depends on VFIO && VFIO_MDEV' and 'VFIO_MDEV
depends on VFIO' and 'VFIO depends on IOMMU_API'?

Perhaps ZCRYPT && VFIO_MDEV && VFIO_MDEV_DEVICE, to make it a bit more
obvious?

Sure, why not.


[Also, is IOMMU_API only needed to satisfy dependencies?]

Yes, VFIO is dependent upon it.

[PATCH 2/3] ALSA: rme32: Use common error handling code in snd_rme32_probe()

2017-11-17 Thread SF Markus Elfring

From: Markus Elfring 
Date: Fri, 17 Nov 2017 21:14:48 +0100

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 sound/pci/rme32.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/sound/pci/rme32.c b/sound/pci/rme32.c
index e58e9873c514..9e6e0fe3a285 100644
--- a/sound/pci/rme32.c
+++ b/sound/pci/rme32.c
@@ -1972,10 +1972,8 @@ snd_rme32_probe(struct pci_dev *pci, const struct 
pci_device_id *pci_id)
rme32->fullduplex_mode = 1;
 
err = snd_rme32_create(rme32);
-   if (err < 0) {
-   snd_card_free(card);
-   return err;
-   }
+   if (err < 0)
+   goto free_card;
 
strcpy(card->driver, "Digi32");
switch (rme32->pci->device) {
@@ -1993,13 +1991,16 @@ snd_rme32_probe(struct pci_dev *pci, const struct 
pci_device_id *pci_id)
card->shortname, rme32->rev, rme32->port, rme32->irq);
 
err = snd_card_register(card);
-   if (err < 0) {
-   snd_card_free(card);
-   return err;
-   }
+   if (err < 0)
+   goto free_card;
+
pci_set_drvdata(pci, card);
dev++;
return 0;
+
+free_card:
+   snd_card_free(card);
+   return err;
 }
 
 static void snd_rme32_remove(struct pci_dev *pci)
-- 
2.15.0

Re: [PATCH] zswap: Same-filled pages handling

2017-11-17 Thread Dan Streetman

On Wed, Oct 18, 2017 at 6:48 AM, Srividya Desireddy
 wrote:
>
> From: Srividya Desireddy 
> Date: Wed, 18 Oct 2017 15:39:02 +0530
> Subject: [PATCH] zswap: Same-filled pages handling
>
> Zswap is a cache which compresses the pages that are being swapped out
> and stores them into a dynamically allocated RAM-based memory pool.
> Experiments have shown that around 10-20% of pages stored in zswap
> are same-filled pages (i.e. contents of the page are all same), but
> these pages are handled as normal pages by compressing and allocating
> memory in the pool.
>
> This patch adds a check in zswap_frontswap_store() to identify same-filled
> page before compression of the page. If the page is a same-filled page, set
> zswap_entry.length to zero, save the same-filled value and skip the
> compression of the page and alloction of memory in zpool.
> In zswap_frontswap_load(), check if value of zswap_entry.length is zero
> corresponding to the page to be loaded. If zswap_entry.length is zero,
> fill the page with same-filled value. This saves the decompression time
> during load.
>
> On a ARM Quad Core 32-bit device with 1.5GB RAM by launching and
> relaunching different applications, out of ~64000 pages stored in
> zswap, ~11000 pages were same-value filled pages (including zero-filled
> pages) and ~9000 pages were zero-filled pages.
>
> An average of 17% of pages(including zero-filled pages) in zswap are
> same-value filled pages and 14% pages are zero-filled pages.
> An average of 3% of pages are same-filled non-zero pages.
>
> The below table shows the execution time profiling with the patch.
>
>   BaselineWith patch  % Improvement
> -
> *Zswap Store Time   26.5ms   18ms  32%
>  (of same value pages)
> *Zswap Load Time
>  (of same value pages)  25.5ms   13ms  49%
> -
>
> On Ubuntu PC with 2GB RAM, while executing kernel build and other test
> scripts and running multimedia applications, out of 36 pages
> stored in zswap 78000(~22%) of pages were found to be same-value filled
> pages (including zero-filled pages) and 64000(~17%) are zero-filled
> pages. So an average of %5 of pages are same-filled non-zero pages.
>
> The below table shows the execution time profiling with the patch.
>
>   BaselineWith patch  % Improvement
> -
> *Zswap Store Time   91ms74ms   19%
>  (of same value pages)
> *Zswap Load Time50ms7.5ms  85%
>  (of same value pages)
> -
>
> *The execution times may vary with test device used.

First, I'm really sorry for such a long delay in looking at this.

I did test this patch out this week, and I added some instrumentation
to check the performance impact, and tested with a small program to
try to check the best and worst cases.

When doing a lot of swap where all (or almost all) pages are
same-value, I found this patch does save both time and space,
significantly.  The exact improvement in time and space depends on
which compressor is being used, but roughly agrees with the numbers
you listed.

In the worst case situation, where all (or almost all) pages have the
same-value *except* the final long (meaning, zswap will check each
long on the entire page but then still have to pass the page to the
compressor), the same-value check is around 10-15% of the total time
spent in zswap_frontswap_store().  That's a not-insignificant amount
of time, but it's not huge.  Considering that most systems will
probably be swapping pages that aren't similar to the worst case
(although I don't have any data to know that), I'd say the improvement
is worth the possible worst-case performance impact.

>
> Signed-off-by: Srividya Desireddy 

Acked-by: Dan Streetman 

> ---
>  mm/zswap.c | 77 
> ++
>  1 file changed, 72 insertions(+), 5 deletions(-)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index d39581a..4dd8b89 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -49,6 +49,8 @@
>  static u64 zswap_pool_total_size;
>  /* The number of compressed pages currently stored in zswap */
>  static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
> +/* The number of same-value filled pages currently stored in zswap */
> +static atomic_t zswap_same_filled_pages = ATOMIC_INIT(0);
>
>  /*
>   * The statistics below are not protected from concurrent access for
> @@ -116,6 +118,11 @@ static int zswap_compressor_param_set(const char *,
>  static unsigned int zswap_max_pool_percent = 20;
>  module_param_named(max_pool_percent, zswap_max_pool_percent, uint, 0644);
>
> +/* Enable/disable handling

[PATCH] dmaengine: ioat: Fix error handling path

2017-11-17 Thread Christophe JAILLET

If the last test in 'ioat_dma_self_test()' fails, we must release all
the allocated resources and not just part of them.

Signed-off-by: Christophe JAILLET 
---
 drivers/dma/ioat/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
index 2f31d3d0caa6..7792a9186f9c 100644
--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -390,7 +390,7 @@ static int ioat_dma_self_test(struct ioatdma_device 
*ioat_dma)
if (memcmp(src, dest, IOAT_TEST_SIZE)) {
dev_err(dev, "Self-test copy failed compare, disabling\n");
err = -ENODEV;
-   goto free_resources;
+   goto unmap_dma;
}
 
 unmap_dma:
-- 
2.14.1

Re: [PATCH v5 11/11] intel_sgx: driver documentation

2017-11-17 Thread Darren Hart

On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:

Please do not submit patches to LKML without a commit message. There is
*always* something you can provide to give the review additional context
to aid in their review of your code.

As Thomas has noted, the various maintainers have been omitted from this
series. Always review the output of get_maintainers.pl and update the To
and Cc list accordingly for every patch. See
Documentation/process/submitting-patches.rst for details, e.g.

5) Select the recipients for your patch
12) When to use Acked-by: and Cc:

For example, for this patch:
$ scripts/get_maintainer.pl -f Documentation/x86
Thomas Gleixner  (maintainer:X86 ARCHITECTURE (32-BIT AND 
64-BIT))
Ingo Molnar  (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
"H. Peter Anvin"  (maintainer:X86 ARCHITECTURE (32-BIT AND 
64-BIT))
x...@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
Jonathan Corbet  (maintainer:DOCUMENTATION)
linux-kernel@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND 64-BIT))
linux-...@vger.kernel.org (open list:DOCUMENTATION)

This series will need to be updated per the comments received so far, as
well as with commit messages and a complete Cc list *per patch* giving
all required parties an opportunity to review.

With respect to the obvious security nature of this series, who from the
kernel security folks are going to be reviewing this?
secur...@kernel.org?

Cc updated for this thread, and specifically the question regarding
location below:

> Signed-off-by: Jarkko Sakkinen 
> ---
>  Documentation/index.rst |   1 +
>  Documentation/x86/intel_sgx.rst | 131 
> 
>  2 files changed, 132 insertions(+)
>  create mode 100644 Documentation/x86/intel_sgx.rst
> 

...

> diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst
> new file mode 100644
> index ..34bcf6a2a495
> --- /dev/null
> +++ b/Documentation/x86/intel_sgx.rst
> @@ -0,0 +1,131 @@
> +===
> +Intel(R) SGX driver
> +===
> +
> +Introduction
> +
> +
> +Intel(R) SGX is a set of CPU instructions that can be used by applications to
> +set aside private regions of code and data. The code outside the enclave is
> +disallowed to access the memory inside the enclave by the CPU access control.
> +In a way you can think that SGX provides inverted sandbox. It protects the
> +application from a malicious host.
> +
> +There is a new hardware unit in the processor called Memory Encryption Engine
> +(MEE) starting from the Skylake microarchitecture. BIOS can define one or 
> many
> +MEE regions that can hold enclave data by configuring them with PRMRR 
> registers.
> +
> +The MEE automatically encrypts the data leaving the processor package to the 
> MEE
> +regions. The data is encrypted using a random key whose life-time is exactly 
> one
> +power cycle.
> +
> +You can tell if your CPU supports SGX by looking into ``/proc/cpuinfo``:
> +
> + ``cat /proc/cpuinfo  | grep sgx``

Is SGX considered architectural or not? A quick search of the SDM
includes it in Volume 3:

Volume 3: Includes the full system programming guide, parts 1, 2, 3, and
4.  Describes the operating-system support environment of Intel® 64 and
IA-32 architectures, including: memory management, protection, task
management, interrupt and exception handling, multi-processor support,
thermal and power management features, debugging, performance
monitoring, system management mode, virtual machine extensions (VMX)
instructions, Intel® Virtualization Technology (Intel® VT), and Intel®
Software Guard Extensions (Intel® SGX).

https://software.intel.com/en-us/articles/intel-sdm

Depending on the answer, this impacts whether this belongs in
drivers/platform/x86 or arch/x86/platform per our recent agreement with
Thomas.

Thomas, Mingo, HPA, do you wish to see this organized/located
differently than it is here in v5?

> +Launch control
> +==
> +
> +For launching an enclave, two structures must be provided for ENCLS(EINIT):
> +
> +1. **SIGSTRUCT:** a signed measurement of the enclave binary.
> +2. **EINITTOKEN:** the measurement, the public key of the signer and various
> +   enclave attributes. This structure contains a MAC of its contents using
> +   hardware derived symmetric key called *launch key*.
> +
> +The hardware platform contains a root key pair for signing the SIGTRUCT
> +for a *launch enclave* that is able to acquire the *launch key* for
> +creating EINITTOKEN's for other enclaves.  For the launch enclave
> +EINITTOKEN is not needed because it is signed with the private root key.
> +
> +There are two feature control bits associate with launch control

Nit: missing colon at the end of the line above ^

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 01/10] x86/apic: Install an empty physflat_init_apic_ldr

2017-11-17 Thread Thomas Gleixner

On Thu, 16 Nov 2017, Jan Kiszka wrote:

> From: Jan Kiszka 
> 
> As the comment already stated, there is no need for setting up LDR in

I prefer to have a proper reference to documentation why this is not
needed than to a comment which is technically dubious.

> physflat mode as it remains unused. flat_init_apic_ldr only served as a
> placeholder for a nop operation so far, causing no harm.
> 
> That will change when running over the Jailhouse hypervisor. Here we
> must not touch LDR in a way that destroys the mapping originally set up
> by the Linux root cell. Jailhouse enforces this setting in order to
> efficiently validate any IPI requests sent by a cell.
> 
> Avoid a needless clash caused by flat_init_apic_ldr by installing a true
> nop handler.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  arch/x86/kernel/apic/apic_flat_64.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/apic/apic_flat_64.c 
> b/arch/x86/kernel/apic/apic_flat_64.c
> index aa85690e9b64..34bfdfe29a04 100644
> --- a/arch/x86/kernel/apic/apic_flat_64.c
> +++ b/arch/x86/kernel/apic/apic_flat_64.c
> @@ -218,6 +218,11 @@ static int physflat_acpi_madt_oem_check(char *oem_id, 
> char *oem_table_id)
>   return 0;
>  }
>  
> +void physflat_init_apic_ldr(void)

static ?

> +{
> + /* LDR is not used in physflat mode. */

flat_init_apic_ldr() also fiddles with DFR ...

> +}
> +
>  static void physflat_send_IPI_allbutself(int vector)
>  {
>   default_send_IPI_mask_allbutself_phys(cpu_online_mask, vector);
> @@ -251,8 +256,7 @@ static struct apic apic_physflat __ro_after_init = {
>   .dest_logical   = 0,
>   .check_apicid_used  = NULL,
>  
> - /* not needed, but shouldn't hurt: */
> - .init_apic_ldr  = flat_init_apic_ldr,
> + .init_apic_ldr  = physflat_init_apic_ldr,
>  
>   .ioapic_phys_id_map = NULL,
>   .setup_apic_routing = NULL,
> -- 
> 2.12.3
> 
>

[PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script

2017-11-17 Thread Andi Kleen

From: Andi Kleen 

Add support for computing perf stat style metrics in perf script.

When using leader sampling we can get metrics for each sampling
period by computing formulas over the values of the different
group members.

This allows things like fine grained IPC tracking through sampling,
much more fine grained than with perf stat.

The metric is still averaged over the sampling period,
it is not just for the sampling point.

This patch adds a new metric output field for perf script
that uses the existing perf stat metrics infrastructure to compute
any metrics supported by perf stat.

For example to sample IPC:

$ perf record -e '{ref-cycles,cycles,instructions}:S' -a sleep 1
$ perf script -F metric,ip,sym,time,cpu,comm
...
 alsa-sink-ALC32 [000] 42815.856074:  7fd65937d6cc [unknown]
 alsa-sink-ALC32 [000] 42815.856074:  7fd65937d6cc [unknown]
 alsa-sink-ALC32 [000] 42815.856074:  7fd65937d6cc [unknown]
 alsa-sink-ALC32 [000] 42815.856074:metric:0.13  insn per cycle
 swapper [000] 42815.857961:  81655df0 __schedule
 swapper [000] 42815.857961:  81655df0 __schedule
 swapper [000] 42815.857961:  81655df0 __schedule
 swapper [000] 42815.857961:metric:0.23  insn per cycle
 qemu-system-x86 [000] 42815.858130:  8165ad0e
_raw_spin_unlock_irqrestore
 qemu-system-x86 [000] 42815.858130:  8165ad0e
_raw_spin_unlock_irqrestore
 qemu-system-x86 [000] 42815.858130:  8165ad0e
_raw_spin_unlock_irqrestore
 qemu-system-x86 [000] 42815.858130:metric:0.46  insn per cycle
   :4972 [000] 42815.858312:  a080e5f2 vmx_vcpu_run
   :4972 [000] 42815.858312:  a080e5f2 vmx_vcpu_run
   :4972 [000] 42815.858312:  a080e5f2 vmx_vcpu_run
   :4972 [000] 42815.858312:metric:0.45  insn per cycle

TopDown:

This requires disabling SMT if you have it enabled, because
SMT would require sampling per core, which is not supported.

$ perf record -e '{ref-cycles,topdown-fetch-bubbles,topdown-recovery-bubbles,\
topdown-slots-retired,topdown-total-slots,topdown-slots-issued}:S' -a sleep 1
$ perf script --header -I -F cpu,ip,sym,event,metric,period
...
[000] 121108   ref-cycles:  8165222e 
copy_user_enhanced_fast_string
[000] 190350topdown-fetch-bubbles:  8165222e 
copy_user_enhanced_fast_string
[000]   2055 topdown-recovery-bubbles:  8165222e 
copy_user_enhanced_fast_string
[000] 148729topdown-slots-retired:  8165222e 
copy_user_enhanced_fast_string
[000] 144324  topdown-total-slots:  8165222e 
copy_user_enhanced_fast_string
[000] 160852 topdown-slots-issued:  8165222e 
copy_user_enhanced_fast_string
[000]   metric: 33.0% frontend bound
[000]   metric:  3.5% bad speculation
[000]   metric: 25.8% retiring
[000]   metric: 37.7% backend bound
[000] 112112   ref-cycles:  8165aec8 
_raw_spin_lock_irqsave
[000] 357222topdown-fetch-bubbles:  8165aec8 
_raw_spin_lock_irqsave
[000]   3325 topdown-recovery-bubbles:  8165aec8 
_raw_spin_lock_irqsave
[000] 323553topdown-slots-retired:  8165aec8 
_raw_spin_lock_irqsave
[000] 270507  topdown-total-slots:  8165aec8 
_raw_spin_lock_irqsave
[000] 341226 topdown-slots-issued:  8165aec8 
_raw_spin_lock_irqsave
[000]   metric: 33.0% frontend bound
[000]   metric:  2.9% bad speculation
[000]   metric: 29.9% retiring
[000]   metric: 34.2% backend bound
...

v2:
Use evsel->priv for new fields
Port to new base line, support fp output.
Handle stats in ->stats, not ->priv
Minor cleanups
Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-script.txt | 10 +++-
 tools/perf/builtin-script.c  | 97 +++-
 tools/perf/util/metricgroup.c|  4 ++
 3 files changed, 108 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 2811fcf684cb..974ceb12c7f3 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -117,7 +117,7 @@ OPTIONS
 Comma separated list of fields to print. Options are:
 comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
 srcline, period, iregs, uregs, brstack, brstacksym, flags, bpf-output, 
brstackinsn,
-brstackoff, callindent, insn, insnlen, synth, phys_addr.
+   brstackoff, callindent, insn, insnlen, synth, phys_addr, metric.
 Field list can be prepended with the type, trace, sw or hw,
 to indicate to which event type the field list applies.
 e.g., -F sw:comm,tid,time,ip,sym  and -F trace:time,cpu,trace
@@ -217,6 +217,14 @@ OPTIONS
 
The brstackoff field will print an offset into a specific

Re: [PATCH] dmaengine: ioat: Fix error handling path

2017-11-17 Thread Dave Jiang



On 11/17/2017 02:37 PM, Christophe JAILLET wrote:
> If the last test in 'ioat_dma_self_test()' fails, we must release all
> the allocated resources and not just part of them.
> 
> Signed-off-by: Christophe JAILLET 

Good catch! Thanks! Acked-by: Dave Jiang 

> ---
>  drivers/dma/ioat/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
> index 2f31d3d0caa6..7792a9186f9c 100644
> --- a/drivers/dma/ioat/init.c
> +++ b/drivers/dma/ioat/init.c
> @@ -390,7 +390,7 @@ static int ioat_dma_self_test(struct ioatdma_device 
> *ioat_dma)
>   if (memcmp(src, dest, IOAT_TEST_SIZE)) {
>   dev_err(dev, "Self-test copy failed compare, disabling\n");
>   err = -ENODEV;
> - goto free_resources;
> + goto unmap_dma;
>   }
>  
>  unmap_dma:
>

Add fine grained sampled metrics for perf script

2017-11-17 Thread Andi Kleen

This patch kit adds perf script support for computing metrics for
sampled groups. This allows much more fine grained metrics
measurement than perf stat allows, because the metrics
can be at PMI granularity instead of a slow timer.

Also the kernel does the sampling in this case which has
much less overhead than perf stat regularly querying
counters.

This allows things like fine grained IPC or TopDown tracking.

Note that the metric is still averaged over the sampling period,
it is not just for the sampling point.

For example to sample IPC:

$ perf record -e '{ref-cycles,cycles,instructions}:S' -a sleep 1
$ perf script -F metric,ip,sym,time,cpu,comm
...
 alsa-sink-ALC32 [000] 42815.856074:  7fd65937d6cc [unknown]
 alsa-sink-ALC32 [000] 42815.856074:  7fd65937d6cc [unknown]
 alsa-sink-ALC32 [000] 42815.856074:  7fd65937d6cc [unknown]
 alsa-sink-ALC32 [000] 42815.856074:metric:0.13  insn per cycle
 swapper [000] 42815.857961:  81655df0 __schedule
 swapper [000] 42815.857961:  81655df0 __schedule
 :1
swapper [000] 42815.857961:  81655df0 __schedule
 swapper [000] 42815.857961:metric:0.23  insn per cycle
 qemu-system-x86 [000] 42815.858130:  8165ad0e
_raw_spin_unlock_irqrestore
 qemu-system-x86 [000] 42815.858130:  8165ad0e
_raw_spin_unlock_irqrestore
 qemu-system-x86 [000] 42815.858130:  8165ad0e
_raw_spin_unlock_irqrestore
 qemu-system-x86 [000] 42815.858130:metric:0.46  insn per cycle
   :4972 [000] 42815.858312:  a080e5f2 vmx_vcpu_run
   :4972 [000] 42815.858312:  a080e5f2 vmx_vcpu_run
   :4972 [000] 42815.858312:  a080e5f2 vmx_vcpu_run
   :4972 [000] 42815.858312:metric:0.45  insn per cycle

TopDown:

Note TopDown requires disabling SMT if you have it enabled (e.g. by offlining
the extra CPUs), because SMT would require sampling per core, which is not 
supported.

$ perf record -e '{ref-cycles,topdown-fetch-bubbles,topdown-recovery-bubbles,\
topdown-slots-retired,topdown-total-slots,topdown-slots-issued}:S' -a sleep 1
$ perf script --header -I -F cpu,ip,sym,event,metric,period
...
[000] 121108   ref-cycles:  8165222e 
copy_user_enhanced_fast_string
[000] 190350topdown-fetch-bubbles:  8165222e 
copy_user_enhanced_fast_string
[000]   2055 topdown-recovery-bubbles:  8165222e 
copy_user_enhanced_fast_string
[000] 148729topdown-slots-retired:  8165222e 
copy_user_enhanced_fast_string
[000] 144324  topdown-total-slots:  8165222e 
copy_user_enhanced_fast_string
[000] 160852 topdown-slots-issued:  8165222e 
copy_user_enhanced_fast_string
[000]   metric: 33.0% frontend bound
[000]   metric:  3.5% bad speculation
[000]   metric: 25.8% retiring
[000]   metric: 37.7% backend bound
[000] 112112   ref-cycles:  8165aec8 
_raw_spin_lock_irqsave
[000] 357222topdown-fetch-bubbles:  8165aec8 
_raw_spin_lock_irqsave
[000]   3325 topdown-recovery-bubbles:  8165aec8 
_raw_spin_lock_irqsave
[000] 323553topdown-slots-retired:  8165aec8 
_raw_spin_lock_irqsave
[000] 270507  topdown-total-slots:  8165aec8 
_raw_spin_lock_irqsave
[000] 341226 topdown-slots-issued:  8165aec8 
_raw_spin_lock_irqsave
[000]   metric: 33.0% frontend bound
[000]   metric:  2.9% bad speculation
[000]   metric: 29.9% retiring
[000]   metric: 34.2% backend bound


Git tree:
git://git.kernel.org/pub/scm/limux/kernel/git/ak/linux-misc.git 
perf/script-metric-3


v1: Initial post
v2: 
Remove already merged patches.
Use evsel->priv for new fields
Port to new base line, support fp output.
Handle stats in ->stats, not ->priv
Minor cleanups
v3:
Enable EVENT_UPDATE in perf record, and record unit/scale/cpu map/thread map
Drop the previous zero cpu map hack.

RE: [PATCH v2] typec: tcpm: fusb302: Resolve out of order messaging events

2017-11-17 Thread Adam Thomson

On 17 November 2017 17:20, Guenter Roeck wrote:

> On Thu, Nov 16, 2017 at 04:28:11PM +, Adam Thomson wrote:
> > The expectation in the FUSB302 driver is that a TX_SUCCESS event
> > should occur after a message has been sent, but before a GCRCSENT
> > event is raised to indicate successful receipt of a message from
> > the partner. However in some circumstances it is possible to see
> > the hardware raise a GCRCSENT event before a TX_SUCCESS event
> > is raised. The upshot of this is that the GCRCSENT handling portion
> > of code ends up reporting the GoodCRC message to TCPM because the
> > TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
> > When TX_SUCCESS is then raised by the chip it ends up consuming the
> > actual message that was meant for TCPM, and this incorrect sequence
> > results in a hard reset from TCPM.
> >
> > To avoid this problem, this commit moves all FIFO reading to be
> > done based on a GCRCSENT event, and when reading from the FIFO
> > any GoodCRC messages read in are discarded so only valid messages
> > are reported to TCPM.
> >
> > Changes in v2:
> >  - Remove erroneous extended header check
> >
> > Patch is based on Linux next-20171114 to include move out of staging.
> >
> > Signed-off-by: Adam Thomson 
> > ---
> >  drivers/usb/typec/fusb302/fusb302.c | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/usb/typec/fusb302/fusb302.c
> b/drivers/usb/typec/fusb302/fusb302.c
> > index 72cb060..ddf88f0 100644
> > --- a/drivers/usb/typec/fusb302/fusb302.c
> > +++ b/drivers/usb/typec/fusb302/fusb302.c
> > @@ -1650,12 +1650,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void
> *dev_id)
> >
> > if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
> > fusb302_log(chip, "IRQ: PD tx success");
> > -   /* read out the received good CRC */
> > -   ret = fusb302_pd_read_message(chip, _msg);
> > -   if (ret < 0) {
> > -   fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
> > -   goto done;
> > -   }
> 
> If multiple "Good CRC" messages are received in a row, they won't be read from
> the chip, which might result in a buffer overflow.

Thanks for your comments. I had considered this since sending the patch. In 
reality I think we'd need to send 11 consecutive messages to which we receive
11 GoodCRCs without receiving a real response message from the partner to clear
the FIFO. Having looked again at the PD spec that seemed really unlikely, but...

> It might be better to always read all pending messages and handle it depending
> on the message type. Something along the line of
>
>   while (interrupts & (FUSB_REG_INTERRUPTA_TX_SUCCESS |
>FUSB_REG_INTERRUPTB_GCRCSENT)) {
>   ret = fusb302_pd_read_message(chip, _msg);
>   if (ret < 0)
>   goto done;
>   if (msg_type == good CRC) {
>   tcpm_pd_transmit_complete(chip->tcpm_port,
> TCPC_TX_SUCCESS);
>   interrupts &= ~FUSB_REG_INTERRUPTA_TX_SUCCESS;
>   } else {
>   tcpm_pd_receive(chip->tcpm_port, _msg);
>   interrupts &= ~FUSB_REG_INTERRUPTB_GCRCSENT;
>   }
>   }
> 
> Guenter

...I do prefer your approach as it doesn't leave anything to chance. I'll
respin accordingly.

> 
> > tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
> > }
> >
> > @@ -1671,12 +1665,22 @@ static irqreturn_t fusb302_irq_intn(int irq, void
> *dev_id)
> >
> > if (interruptb & FUSB_REG_INTERRUPTB_GCRCSENT) {
> > fusb302_log(chip, "IRQ: PD sent good CRC");
> > +retry:
> > ret = fusb302_pd_read_message(chip, _msg);
> > if (ret < 0) {
> > fusb302_log(chip,
> > "cannot read in PD message, ret=%d", ret);
> > goto done;
> > }
> > +
> > +   /*
> > +* Check to make sure we've not read off a GoodCRC message.
> > +* If so then read again to retrieve expected message
> > +*/
> > +   if ((!pd_header_cnt_le(pd_msg.header)) &&
> > +   (pd_header_type_le(pd_msg.header) == PD_CTRL_GOOD_CRC))
> > +   goto retry;
> > +
> > tcpm_pd_receive(chip->tcpm_port, _msg);
> > }
> >  done:
> > --
> > 1.9.1
> >

Re: [PATCH] zswap: Same-filled pages handling

2017-11-17 Thread Dan Streetman

On Wed, Oct 18, 2017 at 5:31 PM, Timofey Titovets  wrote:
>> +static int zswap_is_page_same_filled(void *ptr, unsigned long *value)
>> +{
>> +   unsigned int pos;
>> +   unsigned long *page;
>> +
>> +   page = (unsigned long *)ptr;
>> +   for (pos = 1; pos < PAGE_SIZE / sizeof(*page); pos++) {
>> +   if (page[pos] != page[0])
>> +   return 0;
>> +   }
>> +   *value = page[0];
>> +   return 1;
>> +}
>> +
>
> In theory you can speedup that check by memcmp(),
> And do something like first:
> memcmp(ptr, ptr + PAGE_SIZE/sizeof(*page)/2, PAGE_SIZE/2);
> After compare 1/4 with 2/4
> Then 1/8 with 2/8.
> And after do you check with pattern, only on first 512 bytes.
>
> Just because memcmp() on fresh CPU are crazy fast.
> That can easy make you check less expensive.

I did check this, and it is actually significantly worse; keep in mind
that doing it ^ way may is a smaller loop, but is actually doing more
memory comparisons.

>
>> +static void zswap_fill_page(void *ptr, unsigned long value)
>> +{
>> +   unsigned int pos;
>> +   unsigned long *page;
>> +
>> +   page = (unsigned long *)ptr;
>> +   if (value == 0)
>> +   memset(page, 0, PAGE_SIZE);
>> +   else {
>> +   for (pos = 0; pos < PAGE_SIZE / sizeof(*page); pos++)
>> +   page[pos] = value;
>> +   }
>> +}
>
> Same here, but with memcpy().
>
> P.S.
> I'm just too busy to make fast performance test in user space,
> but my recent experience with that CPU commands, show what that make a sense:
> KSM patch: https://patchwork.kernel.org/patch/9980803/
> User space tests: https://github.com/Nefelim4ag/memcmpe
> PAGE_SIZE: 65536, loop count: 1966080
> memcmp:  -28time: 3216 ms,  th: 40064.644611 MiB/s
> memcmpe: -28, offset: 62232 time: 3588 ms,  th: 35902.462390 MiB/s
> memcmpe: -28, offset: 62232 time: 71 ms,th: 1792233.164286 MiB/s
>
> IIRC, with code like our, you must see ~2.5GiB/s
>
> Thanks.
> --
> Have a nice day,
> Timofey.

Re: [PATCH] checkpatch: allow URL >80 chars

2017-11-17 Thread Joe Perches

On Fri, 2017-11-17 at 16:56 +0100, Andreas Brauchli wrote:
> Allow URL to exceed the 80 char limit for improved interaction in
> adaption to ongoing but undocumented practice.
> 
> $ git grep -E '://\S{77}.*' -- '*.[ch]'
> 
> The patch checks that the URL is indeed on its own line in that it
> allows a maximal prefix of 4 characters to account for a URL after a
> comment (e.g. ' // https://...')
> 
> The URL format allows for up to 5 protocol characters before the
> separator :// (e.g. https, git, ...). Additionally, an URL starting
> with a "domain.tld" or "subdomain.domain" pattern (e.g.
> 'www.kernel.org') is also accepted.
> 
> $rawline is used in the check as comments are removed from $line.
> 
> Signed-off-by: Andreas Brauchli 
> ---
>  scripts/checkpatch.pl | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 8b80bac055e4..aed447923354 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2904,6 +2904,11 @@ sub process {
>   } elsif ($line =~ /^\+.*\bEFI_GUID\s*\(/) {
>   $msg_type = "";
>  
> + # URL (w/ minimal padding e.g. "+ // ")
> + } elsif ($rawline =~ 
> /^\+.*?\b((?:\w{1,5}:\/\/|\w+\.\w+)\S+).*$/ &&

nack.

this matches member dereference lines like

foo.bar = baz;

and include lines like

#include

[PATCH 0/3] mfd: Handle platform_get_irq's error checking and return

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct and we must check its return value.

Arvind Yadav (3):
  [PATCH 1/3] mfd: ipaq-micro: Fix platform_get_irq's error checking
  [PATCH 2/3] mfd: intel-lpss: Handle return value of platform_get_*
  [PATCH 3/3] mfd: sun4i-gpadc: Handle return value of platform_get_irq

 drivers/mfd/intel-lpss-acpi.c | 2 ++
 drivers/mfd/ipaq-micro.c  | 4 ++--
 drivers/mfd/sun4i-gpadc.c | 7 +--
 3 files changed, 9 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 2/3] mfd: intel-lpss: Handle return value of platform_get_*

platform_get_irq() and platform_get_resource() can fail here and
we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/mfd/intel-lpss-acpi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
index 7911b0a..cb84de5 100644
--- a/drivers/mfd/intel-lpss-acpi.c
+++ b/drivers/mfd/intel-lpss-acpi.c
@@ -92,6 +92,8 @@ static int intel_lpss_acpi_probe(struct platform_device *pdev)
 
info->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
info->irq = platform_get_irq(pdev, 0);
+   if (!info->mem || info->irq < 0)
+   return -ENOMEM;
 
pm_runtime_set_active(>dev);
pm_runtime_enable(>dev);
-- 
2.7.4

[PATCH 3/3] mfd: sun4i-gpadc: Handle return value of platform_get_irq

platform_get_irq() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/mfd/sun4i-gpadc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/sun4i-gpadc.c b/drivers/mfd/sun4i-gpadc.c
index 9cfc881..1c89235 100644
--- a/drivers/mfd/sun4i-gpadc.c
+++ b/drivers/mfd/sun4i-gpadc.c
@@ -100,8 +100,8 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
struct resource *mem;
const struct of_device_id *of_id;
const struct mfd_cell *cells;
-   unsigned int irq, size;
-   int ret;
+   unsigned int size;
+   int ret, irq;
 
of_id = of_match_node(sun4i_gpadc_of_match, pdev->dev.of_node);
if (!of_id)
@@ -148,6 +148,9 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
regmap_write(dev->regmap, SUN4I_GPADC_INT_FIFOC, 0);
 
irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   return irq;
+
ret = devm_regmap_add_irq_chip(>dev, dev->regmap, irq,
   IRQF_ONESHOT, 0,
   _gpadc_regmap_irq_chip,
-- 
2.7.4

[PATCH 1/3] mfd: ipaq-micro: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct.

Signed-off-by: Arvind Yadav 
---
 drivers/mfd/ipaq-micro.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/ipaq-micro.c b/drivers/mfd/ipaq-micro.c
index cd762d0..ea729db 100644
--- a/drivers/mfd/ipaq-micro.c
+++ b/drivers/mfd/ipaq-micro.c
@@ -410,8 +410,8 @@ static int __init micro_probe(struct platform_device *pdev)
micro_reset_comm(micro);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq)
-   return -EINVAL;
+   if (irq < 0)
+   return irq;
ret = devm_request_irq(>dev, irq, micro_serial_isr,
   IRQF_SHARED, "ipaq-micro",
   micro);
-- 
2.7.4

Re: [PATCH 2/4] btrfs: make open_ctree error injectable

2017-11-17 Thread Ingo Molnar


* Josef Bacik  wrote:

> From: Josef Bacik 
> 
> This allows us to do error injection with BPF for open_ctree.
> 
> Signed-off-by: Josef Bacik 
> ---
>  fs/btrfs/disk-io.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index dfdab849037b..c6b4e1f07072 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "ctree.h"
>  #include "disk-io.h"
>  #include "hash.h"
> @@ -3283,6 +3284,7 @@ int open_ctree(struct super_block *sb,
>   goto fail_block_groups;
>   goto retry_root_backup;
>  }
> +BPF_ALLOW_ERROR_INJECTION(open_ctree);

Ok, this looks a lot better - except the random header inclusion dependency: if 
a 
facility is in the BPF_*() namespace then it should include  and 
not 
a random asm/* header...

With that detail fixed:

  Acked-by: Ingo Molnar 

for the whole series.

Thanks,

Ingo

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

2017-11-17 Thread Meelis Roos

> > > How early does it hang ? Any oops or trace ?
> > 
> > Very early - instead oif kernel emssages, I see some repeated gibberish
> > of some characteers, and the background turns white.
> > I am booting from yaboot, background is normally black.
> 
> Ok, could you try by replacing #ifdef CONFIG_STRICT_KERNEL_RWX by #if 0
> in arch/powerpc/lib/code-patching.c

With this change and CONFIG_STRICT_KERNEL_RWX=y, it still boots.

BTW, I get these warnings (sorry for the word wrap from screen paste) - 
may they be related or rather not?

  WRAParch/powerpc/boot/zImage.pmac
  WRAParch/powerpc/boot/zImage.coff
  WRAParch/powerpc/boot/zImage.miboot
INFO: Uncompressed kernel (size 0x5d4c3c) overlaps the address of the 
wrapper(0x40)
INFO: Fixing the link_address of wrapper to (0x60)


And before that:

  HOSTCC  arch/powerpc/boot/addnote
arch/powerpc/boot/addnote.c: In function ‘main’:
arch/powerpc/boot/addnote.c:75:47: warning: right shift count >= width 
of type [-Wshift-count-overflow]
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^
arch/powerpc/boot/addnote.c:72:39: note: in definition of macro 
‘PUT_16BE’
 #define PUT_16BE(off, v)(buf[off] = ((v) >> 8) & 0xff, \
   ^
arch/powerpc/boot/addnote.c:75:27: note: in expansion of macro 
‘PUT_32BE’
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^~~~
arch/powerpc/boot/addnote.c:94:50: note: in expansion of macro 
‘PUT_64BE’
 #define PUT_64(off, v)  (e_data == ELFDATA2MSB ? PUT_64BE(off, v) : \
  ^~~~
arch/powerpc/boot/addnote.c:183:3: note: in expansion of macro ‘PUT_64’
   PUT_64(ph + PH_OFFSET, ns);
   ^~
arch/powerpc/boot/addnote.c:75:47: warning: right shift count >= width 
of type [-Wshift-count-overflow]
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^
arch/powerpc/boot/addnote.c:73:23: note: in definition of macro 
‘PUT_16BE’
 buf[(off) + 1] = (v) & 0xff)
   ^
arch/powerpc/boot/addnote.c:75:27: note: in expansion of macro 
‘PUT_32BE’
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^~~~
arch/powerpc/boot/addnote.c:94:50: note: in expansion of macro 
‘PUT_64BE’
 #define PUT_64(off, v)  (e_data == ELFDATA2MSB ? PUT_64BE(off, v) : \
  ^~~~
arch/powerpc/boot/addnote.c:183:3: note: in expansion of macro ‘PUT_64’
   PUT_64(ph + PH_OFFSET, ns);
   ^~
arch/powerpc/boot/addnote.c:75:47: warning: right shift count >= width 
of type [-Wshift-count-overflow]
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^
arch/powerpc/boot/addnote.c:72:39: note: in definition of macro 
‘PUT_16BE’
 #define PUT_16BE(off, v)(buf[off] = ((v) >> 8) & 0xff, \
   ^
arch/powerpc/boot/addnote.c:75:27: note: in expansion of macro 
‘PUT_32BE’
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^~~~
arch/powerpc/boot/addnote.c:94:50: note: in expansion of macro 
‘PUT_64BE’
 #define PUT_64(off, v)  (e_data == ELFDATA2MSB ? PUT_64BE(off, v) : \
  ^~~~
arch/powerpc/boot/addnote.c:183:3: note: in expansion of macro ‘PUT_64’
   PUT_64(ph + PH_OFFSET, ns);
   ^~
arch/powerpc/boot/addnote.c:75:47: warning: right shift count >= width 
of type [-Wshift-count-overflow]
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^
arch/powerpc/boot/addnote.c:73:23: note: in definition of macro 
‘PUT_16BE’
 buf[(off) + 1] = (v) & 0xff)
   ^
arch/powerpc/boot/addnote.c:75:27: note: in expansion of macro 
‘PUT_32BE’
 #define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
   ^~~~
arch/powerpc/boot/addnote.c:94:50: note: in expansion of macro 
‘PUT_64BE’
 #define PUT_64(off, v)  (e_data == ELFDATA2MSB ? PUT_64BE(off, v) : \
  ^~~~
arch/powerpc/boot/addnote.c:183:3: note: in expansion of macro ‘PUT_64’
   PUT_64(ph + PH_OFFSET, ns);
   ^~
arch/powerpc/boot/addnote.c:85:73: warning: right shift count >= width 
of type [-Wshift-count-overflow]
 #define PUT_64LE(off, v) (PUT_32LE((off), (v)), PUT_32LE((off) + 4, (v) 
>> 32L))
 
^
arch/powerpc/boot/addnote.c:82:39: note: in definition of macro 
‘PUT_16LE’
 #define PUT_16LE(off, v) (buf[off] = (v) & 0xff, \
   ^
arch/powerpc/boot/addnote.c:85:49: note: in expansion of macro 
‘PUT_32LE’
 #define PUT_64LE(off, v) (PUT_32LE((off), (v)), PUT_32LE((off) + 4, (v) 
>> 32L))
 ^~~~

[PATCH 2/5 v2] ASoC: mt8173: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct.

Signed-off-by: Arvind Yadav 
---
chnages in v2 :
  irq_id was unsigned. so changed it to signed.

 sound/soc/mediatek/mt8173/mt8173-afe-pcm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c 
b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
index 8a643a3..11f5f2a 100644
--- a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
+++ b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
@@ -1083,7 +1083,7 @@ static int mt8173_afe_init_audio_clk(struct mtk_base_afe 
*afe)
 static int mt8173_afe_pcm_dev_probe(struct platform_device *pdev)
 {
int ret, i;
-   unsigned int irq_id;
+   int irq_id;
struct mtk_base_afe *afe;
struct mt8173_afe_private *afe_priv;
struct resource *res;
@@ -1105,9 +1105,9 @@ static int mt8173_afe_pcm_dev_probe(struct 
platform_device *pdev)
afe->dev = >dev;
 
irq_id = platform_get_irq(pdev, 0);
-   if (!irq_id) {
+   if (irq_id < 0) {
dev_err(afe->dev, "np %s no irq\n", afe->dev->of_node->name);
-   return -ENXIO;
+   return irq_id;
}
ret = devm_request_irq(afe->dev, irq_id, mt8173_afe_irq_handler,
   0, "Afe_ISR_Handle", (void *)afe);
-- 
2.7.4

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook  wrote:
>
> FWIW, myself doing a build at d9e12200852d with and without
> GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output
> where I did spot-checks.

That would probably be a good thing to check anyway - check the
difference between GCC_PLUGIN_RANDSTRUCT on and off at that commit.

Just do

   objdump --disassemble vmlinux > file

and compare the two files for where the differences start occurring.

 Linus

[PATCH 1/5 v2] ASoC: ep93xx-ac97: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct.

Signed-off-by: Arvind Yadav 
---
changes in v2 :
   irq was unsigned. so changed it to signed.

 sound/soc/cirrus/ep93xx-ac97.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/cirrus/ep93xx-ac97.c b/sound/soc/cirrus/ep93xx-ac97.c
index bbf7a92..b86b83b 100644
--- a/sound/soc/cirrus/ep93xx-ac97.c
+++ b/sound/soc/cirrus/ep93xx-ac97.c
@@ -365,7 +365,7 @@ static int ep93xx_ac97_probe(struct platform_device *pdev)
 {
struct ep93xx_ac97_info *info;
struct resource *res;
-   unsigned int irq;
+   int irq;
int ret;
 
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
@@ -378,8 +378,8 @@ static int ep93xx_ac97_probe(struct platform_device *pdev)
return PTR_ERR(info->regs);
 
irq = platform_get_irq(pdev, 0);
-   if (!irq)
-   return -ENODEV;
+   if (irq < 0)
+   return irq;
 
ret = devm_request_irq(>dev, irq, ep93xx_ac97_interrupt,
   IRQF_TRIGGER_HIGH, pdev->name, info);
-- 
2.7.4

[PATCH 3/5 v2] ASoC: nuc900: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct.

Signed-off-by: Arvind Yadav 
---
changes in v2 :
 nuc900_audio->irq_num is unsigned. so handle through signed 
variable.

 sound/soc/nuc900/nuc900-ac97.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c
index b6615af..71fce7c 100644
--- a/sound/soc/nuc900/nuc900-ac97.c
+++ b/sound/soc/nuc900/nuc900-ac97.c
@@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device 
*pdev)
goto out;
}
 
-   nuc900_audio->irq_num = platform_get_irq(pdev, 0);
-   if (!nuc900_audio->irq_num) {
-   ret = -EBUSY;
+   ret = platform_get_irq(pdev, 0);
+   if (ret < 0)
goto out;
-   }
+   nuc900_audio->irq_num = ret;
 
nuc900_ac97_data = nuc900_audio;
 
-- 
2.7.4

[PATCH 1/2] misc: aspeed-lpc-snoop: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/aspeed-lpc-snoop.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/aspeed-lpc-snoop.c b/drivers/misc/aspeed-lpc-snoop.c
index cb78c98..14c3c90 100644
--- a/drivers/misc/aspeed-lpc-snoop.c
+++ b/drivers/misc/aspeed-lpc-snoop.c
@@ -115,8 +115,8 @@ static int aspeed_lpc_snoop_config_irq(struct 
aspeed_lpc_snoop *lpc_snoop,
int rc;
 
lpc_snoop->irq = platform_get_irq(pdev, 0);
-   if (!lpc_snoop->irq)
-   return -ENODEV;
+   if (lpc_snoop->irq < 0)
+   return lpc_snoop->irq;
 
rc = devm_request_irq(dev, lpc_snoop->irq,
  aspeed_lpc_snoop_irq, IRQF_SHARED,
-- 
2.7.4

[PATCH 2/2] misc: atmel-ssc: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/atmel-ssc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index b2a0340..9d9eeae 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -235,9 +235,9 @@ static int ssc_probe(struct platform_device *pdev)
clk_disable_unprepare(ssc->clk);
 
ssc->irq = platform_get_irq(pdev, 0);
-   if (!ssc->irq) {
+   if (ssc->irq < 0) {
dev_dbg(>dev, "could not get irq\n");
-   return -ENXIO;
+   return ssc->irq;
}
 
spin_lock(_lock);
-- 
2.7.4

[PATCH 0/2] misc: Fix platform_get_irq's error checking

The platform_get_irq() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq() error checking
for zero is not correct.

Arvind Yadav (2):
  [PATCH 1/2] misc: aspeed-lpc-snoop: Fix platform_get_irq's error checking
  [PATCH 2/2] misc: atmel-ssc: Fix platform_get_irq's error checking

 drivers/misc/aspeed-lpc-snoop.c | 4 ++--
 drivers/misc/atmel-ssc.c| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.7.4

Re: [RFC PATCH 00/20] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling

2017-11-17 Thread Reinette Chatre

Hi Thomas,

On 11/17/2017 4:48 PM, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Reinette Chatre wrote:
> 
> thanks for that interesting work. Before I start looking into the details
> in the next days let me ask a few general questions first.

Thank you very much for taking a look. I look forward to your feedback.

> 
>> Cache Allocation Technology (CAT), part of Intel(R) Resource Director
>> Technology (Intel(R) RDT), enables a user to specify the amount of cache
>> space into which an application can fill. Cache pseudo-locking builds on
>> the fact that a CPU can still read and write data pre-allocated outside
>> its current allocated area on cache hit. With cache pseudo-locking data
>> can be preloaded into a reserved portion of cache that no application can
>> fill, and from that point on will only serve cache hits. The cache
>> pseudo-locked memory is made accessible to user space where an application
>> can map it into its virtual address space and thus have a region of
>> memory with reduced average read latency.
> 
> Did you compare that against the good old cache coloring mechanism,
> e.g. palloc ?

I understand where your question originates. I have not compared against PALLOC 
for two reasons:
1) PALLOC is not upstream and while inquiring about the status of this work 
(please see https://github.com/heechul/palloc/issues/4 for details) we learned 
that one reason for this is that recent Intel processors are not well supported.
2) The most recent kernel supported by PALLOC is v4.4 and also mentioned in the 
above link there is currently no plan to upstream this work for a less 
divergent comparison of PALLOC and the more recent RDT/CAT enabling on which 
Cache Pseudo-Locking is built.

>> The cache pseudo-locking approach relies on generation-specific behavior
>> of processors. It may provide benefits on certain processor generations,
>> but is not guaranteed to be supported in the future.
> 
> Hmm, are you saying that the CAT mechanism might change radically in the
> future so that access to cached data in an allocated area which does not
> belong to the current executing context wont work anymore?

Most devices that publicly support CAT in the Linux mainline can take advantage 
of Cache Pseudo-Locking.  However, Cache Pseudo-Locking is a model-specific 
feature so there may be some variation in if, or to what extent, current and 
future devices can support Cache Pseudo-Locking. CAT remains architectural.

>> It is not a guarantee that data will remain in the cache. It is not a
>> guarantee that data will remain in certain levels or certain regions of
>> the cache. Rather, cache pseudo-locking increases the probability that
>> data will remain in a certain level of the cache via carefully
>> configuring the CAT feature and carefully controlling application
>> behavior.
> 
> Which kind of applications are you targeting with that?
>
> Are there real world use cases which actually can benefit from this and

To ensure I answer your question I will consider two views. First, the 
"carefully controlling application behavior" referred to above refers to 
applications/OS/VMs running after the pseudo-locked regions have been set up. 
These applications should take care to not do anything, for example call 
wbinvd, that would affect the Cache Pseudo-Locked regions. Second, what you are 
also asking about is the applications using these Cache Pseudo-Locked regions. 
We do see a clear performance benefit to applications using these pseudo-locked 
regions. Latency sensitive applications could relocate their code as well as 
data to pseudo-locked regions for improved performance.

> what are those applications supposed to do once the feature breaks with
> future generations of processors?

This feature is model specific with a few platforms supporting it at this time. 
Only platforms known to support Cache Pseudo-Locking will expose its resctrl 
interface.

Reinette

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

2017-11-17 Thread Kees Cook

On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean  wrote:
> On 2017-11-17 04:55 PM, Linus Torvalds wrote:
>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean  wrote:
>>>
>>> I am still getting the crash at d9e12200852d, I figured I would
>>> double-check the "good" and "bad" kernels before starting a full bisect.
>>
>> .. but without GCC_PLUGIN_RANDSTRUCT it's solid?
>
> Yes, without GCC_PLUGIN_RANDSTRUCT it's solid.

That's strange. With d9e12200852d the shuffle_seed variables won't
ever actually get used. (i.e. I wouldn't expect the seed to change any
behavior.)

Can you confirm with something like this:


diff --git a/scripts/gcc-plugins/randomize_layout_plugin.c
b/scripts/gcc-plugins/randomize_layout_plugin.c
index cdaac8c66734..aac570a57d7d 100644
--- a/scripts/gcc-plugins/randomize_layout_plugin.c
+++ b/scripts/gcc-plugins/randomize_layout_plugin.c
@@ -267,12 +267,10 @@ static void shuffle(const_tree type, tree
*newtree, unsigned long length)

structname = ORIG_TYPE_NAME(type);

-#ifdef __DEBUG_PLUGIN
fprintf(stderr, "Shuffling struct %s %p\n", (const char
*)structname, type);
 #ifdef __DEBUG_VERBOSE
debug_tree((tree)type);
 #endif
-#endif

for (i = 0; i < 4; i++) {
seed[i] = shuffle_seed[i];


You should see no reports of "Shuffling struct ..."

And if it reports nothing, and you're on d9e12200852d, can you confirm
that switching to a "good" seed fixes it? (If it _does_, then I
suspect a build artifact being left behind or something odd like
that.)

>> Kees removed even the baseline "randomize pure function pointer
>> structures", so at that commit, nothing should be randomized.
>>
>> But maybe the plugin code itself ends up confusing gcc somehow?
>>
>> Even when it doesn't actually do that "relayout_struct()" on the
>> structure, it always does those TYPE_ATTRIBUTES() games.

FWIW, myself doing a build at d9e12200852d with and without
GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output
where I did spot-checks.

Also, do you have any other plugins enabled? (Can you send your .config?)

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] rdma: Add Jason as a co-maintainer

2017-11-17 Thread Leon Romanovsky

On Fri, Nov 17, 2017 at 08:44:27PM -0500, Doug Ledford wrote:
>
> If you split step 5 above into 5a) Push from local work repo to local
> prep repo and 5b) Do full kernel build in prep repo to test that all
> code needed to compile is tracked by git, it would catch that mistake
> before it makes it outside the firewall.  That's a change I may make
> just to be on the safe side in the future.

I'm using git worktree command [1] for that.

If it helps, this is snippet from my scripts:

-
REPORT_FILE=$(mktemp)

function do_one {
SHA1=$1
REPORT_FILE=$2
PDIR=$(mktemp -d)

git worktree add $PDIR $SHA1
echo "Redirecting the output to $REPORT_FILE"
pushd $PDIR &>> $REPORT_FILE
x checkpatch HEAD $PDIR &>> $REPORT_FILE
cp $KCONFIG . &>> $REPORT_FILE
make olddefconfig &>> $REPORT_FILE
echo "= FULL COMPILE =" &>> $REPORT_FILE
make -s -j 4 &>> $REPORT_FILE
echo "= SUB COMPILE =" &>> $REPORT_FILE
make -s -j 4 W=1 drivers/infiniband/ drivers/net/ethernet/mellanox/ &>> 
$REPORT_FILE
echo "= SMATCH =" &>> $REPORT_FILE
make CHECK="$SMATCH -p=kernel" C=1 drivers/infiniband/ 
drivers/net/ethernet/mellanox/ -s -j 4 &>> $REPORT_FILE
echo "= SPARSE =" &>> $REPORT_FILE
make CHECK="$SPARSE" C=2 drivers/infiniband/ 
drivers/net/ethernet/mellanox/ -s -j 4  &>> $REPORT_FILE
popd &>> $REPORT_FILE
rm -rf $PDIR
git worktree prune
# TODO: separate checkpatch errors, sparse, smatch
NUMB_OF_ERRORS=$(awk -F": " '{print $1}' $REPORT_FILE | grep ":" | sort 
| uniq |wc -l)
echo "There are $NUMB_OF_ERRORS errors/warnings"
}

do_one $SHA1 $REPORT_FILE
--

Thanks

[1] https://git-scm.com/docs/git-worktree

>
> --
> Doug Ledford 
> GPG KeyID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD




signature.asc
Description: PGP signature

Re: Linux 3.10.108 (EOL)

2017-11-17 Thread Sebastian Gottschall


Am 18.11.2017 um 00:46 schrieb Alan Cox:

i just wanted to throw some stones on the bloated kernel problem which is
increasing

People used to be working on that, but then it seemed like the "size"
got to a point that people were comfortable with it.  Are you sure that

There's also a lot of pushback to things that add a ton of ifdefs.


just changing some build options would not make your image smaller?
Letting people know sometime in the past few years that the kernel was
getting "too big" for you would have been good to do :)

It's also an increasingly hard problem to deal with because the scale of
big machines means the algorithms themselves in a modern Linux OS just
don't make sense for a tiddly embedded router.

I know lots of people build them that way but if you compare it with one
of the more conservative *BSD builds you have to wonder why not use BSD
instead - especially with nanoBSD ?

(and BSD has the reverse problem - most BSD does not scale to a modern
bigger machine of course).

Alan
"1.2.13 was the last true Linux"  ;-)



easy. i have to port alot of cpu platforms to bsd then and since i'm doing

wireless routers i will run into a problem with all the drivers i have 
to rewrite for bsd and the bsd wireless stack is simply shit


its basicly a impossible task. and most of my code is gpl licensed. mmh 
mixing with bsd code, not a good idea



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Blank console but X11 works on MCP79 - old regression since 3.8

2017-11-17 Thread Ilia Mirkin

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin  wrote:
> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary  
> wrote:
>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>>
>>>  wrote:
>>> > @@ -483,8 +483,8 @@
>>> >  nouveau :02:00.0: disp:0860:  -> 0500
>>> >  nouveau :02:00.0: disp:0864: 
>>> >  nouveau :02:00.0: disp:0868:  -> 04000500
>>> > -nouveau :02:00.0: disp:086c:  -> 00100500
>>> > -nouveau :02:00.0: disp:0870: e900 -> 1e00
>>> > +nouveau :02:00.0: disp:086c:  -> 00100a00
>>> > +nouveau :02:00.0: disp:0870: e900 -> e800
>>> >  nouveau :02:00.0: disp:0874:  -> 
>>> >  nouveau :02:00.0: disp:0878: 
>>> >  nouveau :02:00.0: disp:0880: 0500
>>> >
>>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in
>>> > 64MB case. Why?
>>> >
>>> > I get blank screen even with 64MB with video=1280x1024-8 kernel
>>> > parameter. Console works with video=1280x1024-16 even with 32MB stolen
>>> > memory.
>>> >
>>> > Conclusions: 8-bit support is broken and bpp reduction is weird.
>>>
>>> OK, well that makes a *ton* of sense (8bpp being broken).
>>>
>>> I think the idea of bpp reduction is that when you're on your shiny
>>> new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating
>>> all that to a pinned fbcon - almost half of that would go to a single
>>> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
>>> have at least a few fb-sized buffers for backbuffer rendering, etc.
>>>
>>> The specific limits could probably use tweaking - I think they only
>>> consider VRAM size, not the fb size.
>>>
>>> I guess 8bpp worked prior to the change you bisected though, so we
>>> should figure out what we did wrong in the new code.
>>
>> Yes, booted 3.7 (last working kernel) and it's running in 8bpp.
>
> By the way, instead of booting $kernel, you can use modetest from
> libdrm/tests. Not sure if it supports C8 though =/

It didn't. But it does now - I mailed a patch to dri-devel, also (with
slight fix) available at

https://people.freedesktop.org/~imirkin/patches/0001-modetest-add-C8-support-to-generate-SMPTE-pattern.patch

This works on GK208 but not on G92 (whose display unit is much closer
to your MCP79's). You can run as

./modetest -s DVI-I-1:1920x1200@C8

This should display a SMPTE pattern, and exit when you hit enter. When
it does so, it doesn't restore fbcon, but you can swtich to another
vty to get console back.

I get a white picture on G92. Now just have to figure out how to fix
it. Someone should also test on a G80 if possible, since that takes a
different path as well.

  -ilia

RE: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

2017-11-17 Thread Wang, Wei W

On Friday, November 17, 2017 8:45 PM, Michael S. Tsirkin wrote:
> On Fri, Nov 17, 2017 at 07:35:03PM +0800, Wei Wang wrote:
> > On 11/16/2017 09:27 PM, Wei Wang wrote:
> > > On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
> > > > On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
> > > > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature
> > > > > indicates the support of reporting hints of guest free pages to
> > > > > the host via virtio-balloon. The host requests the guest to
> > > > > report the free pages by sending commands via the virtio-balloon
> configuration registers.
> > > > >
> > > > > When the guest starts to report, the first element added to the
> > > > > free page vq is a sequence id of the start reporting command.
> > > > > The id is given by the host, and it indicates whether the
> > > > > following free pages correspond to the command. For example, the
> > > > > host may stop the report and start again with a new command id.
> > > > > The obsolete pages for the previous start command can be
> > > > > detected by the id dismatching on the host. The id is added to
> > > > > the vq using an output buffer, and the free pages are added to
> > > > > the vq using input buffer.
> > > > >
> > > > > Here are some explainations about the added configuration registers:
> > > > > - host2guest_cmd: a register used by the host to send commands
> > > > > to the guest.
> > > > > - guest2host_cmd: written by the guest to ACK to the host about
> > > > > the commands that have been received. The host will clear the
> > > > > corresponding bits on the host2guest_cmd register. The guest
> > > > > also uses this register to send commands to the host (e.g. when finish
> free page reporting).
> > > > > - free_page_cmd_id: the sequence id of the free page report
> > > > > command given by the host.
> > > > >
> > > > > Signed-off-by: Wei Wang 
> > > > > Signed-off-by: Liang Li 
> > > > > Cc: Michael S. Tsirkin 
> > > > > Cc: Michal Hocko 
> > > > > ---
> > > > >
> > > > > +
> > > > > +static void report_free_page(struct work_struct *work) {
> > > > > +struct virtio_balloon *vb;
> > > > > +
> > > > > +vb = container_of(work, struct virtio_balloon,
> > > > > report_free_page_work);
> > > > > +report_free_page_cmd_id(vb);
> > > > > +walk_free_mem_block(vb, 0, _balloon_send_free_pages);
> > > > > +/*
> > > > > + * The last few free page blocks that were added may not reach 
> > > > > the
> > > > > + * batch size, but need a kick to notify the device to
> > > > > handle them.
> > > > > + */
> > > > > +virtqueue_kick(vb->free_page_vq);
> > > > > +report_free_page_end(vb);
> > > > > +}
> > > > > +
> > > > I think there's an issue here: if pages are poisoned and
> > > > hypervisor subsequently drops them, testing them after allocation
> > > > will trigger a false positive.
> > > >
> > > > The specific configuration:
> > > >
> > > > PAGE_POISONING on
> > > > PAGE_POISONING_NO_SANITY off
> > > > PAGE_POISONING_ZERO off
> > > >
> > > >
> > > > Solutions:
> > > > 1. disable the feature in that configuration
> > > > suggested as an initial step
> > >
> > > Thanks for the finding.
> > > Similar to this option: I'm thinking could we make
> > > walk_free_mem_block() simply return if that option is on?
> > > That is, at the beginning of the function:
> > > if (!page_poisoning_enabled())
> > > return;
> > >
> >
> >
> > Thought about it more, I think it would be better to put this logic to
> > virtio_balloon:
> >
> > send_free_page_cmd_id(vb, >start_cmd_id);
> > if (page_poisoning_enabled() &&
> > !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
> > walk_free_mem_block(vb, 0, _balloon_send_free_pages);
> > send_free_page_cmd_id(vb, >stop_cmd_id);
> >
> >
> > walk_free_mem_block() should be a more generic API, and this potential
> > page poisoning issue is specific to live migration which is only one
> > use case of this function, so I think it is better to handle it in the
> > special use case itself.
> >
> > Best,
> > Wei
> >
> 
> It's a quick work-around but it doesn't make me very happy.
> 
> AFAIK e.g. RHEL has a debug kernel with poisoning enabled.
> If this never uses free page hinting at all, it will be much less useful for
> debugging guests.
> 

I understand your concern. I think people who use debugging guests don't regard 
performance as the first priority, and most vendors usually wouldn't use 
debugging guests for their products.

How about taking it as the initial solution? We can exploit more solutions 
after this series is done.

Best,
Wei

[PATCH] perf report/top: Add a tip about source line matching

2017-11-17 Thread Hyeim Yang

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Taeung Song 
---
 tools/perf/Documentation/tips.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/Documentation/tips.txt 
b/tools/perf/Documentation/tips.txt
index db0ca30..b60616a 100644
--- a/tools/perf/Documentation/tips.txt
+++ b/tools/perf/Documentation/tips.txt
@@ -32,3 +32,4 @@ Order by the overhead of source file name and line number: 
perf report -s srclin
 System-wide collection from all CPUs: perf record -a
 Show current config key-value pairs: perf config --list
 Show user configuration overrides: perf config --user --list
+Print matching source lines (may be slow): perf annotate --print-line 
-- 
2.7.4

Re: Linux 3.10.108 (EOL)

2017-11-17 Thread Willy Tarreau

On Fri, Nov 17, 2017 at 11:46:20PM +, Alan Cox wrote:
> > > i just wanted to throw some stones on the bloated kernel problem which is
> > > increasing  
> > 
> > People used to be working on that, but then it seemed like the "size"
> > got to a point that people were comfortable with it.  Are you sure that
> 
> There's also a lot of pushback to things that add a ton of ifdefs.
> 
> > just changing some build options would not make your image smaller?
> > Letting people know sometime in the past few years that the kernel was
> > getting "too big" for you would have been good to do :)
> 
> It's also an increasingly hard problem to deal with because the scale of
> big machines means the algorithms themselves in a modern Linux OS just
> don't make sense for a tiddly embedded router.

It's true but it's also true that a lot of these algorithm can be tuned
at build time. We have various memory allocators, tiny RCU, the ability
to disable SMP, we can even tune certain filesystems to use more or less
buffers, etc. It's not that bad at all and I'm not sure that many other
OSes have this level of flexibility.

> I know lots of people build them that way but if you compare it with one
> of the more conservative *BSD builds you have to wonder why not use BSD
> instead - especially with nanoBSD ?

Well, I maintain a kernel image that I use as a bootloader / recovery image
to (re-)install some machines. The kernel+rootfs image fits in 1.7 MB, and
in that size it supports a few network drivers, SATA, serial console, kexec,
EXT2+VFAT and a few other stuff. Obviously it's a bit limited, but it serves
this purpose well as it needs to fit into a 2 MB partition where GRUB is
already installed. It started with 2.6.16 about 12 years ago, then 2.6.35,
now 3.10.104. The image has increased a bit over time, but it also required
a lot less patches to shrink it.

If that can be useful, I can try to port these patches to modern kernels
to get them merged. However some of them add new options (eg: enable
diag/stats in igb driver, etc) and would probably need to be inverted to
disable certain features based on a central option to make the kernel much
smaller.

> (and BSD has the reverse problem - most BSD does not scale to a modern
> bigger machine of course).
> 
> Alan
> "1.2.13 was the last true Linux"  ;-)

I've been using this one for a while and have even deployed it a few times
as LAN->PPP gateways by reconverting old 2 MB RAM 386's (1.6 MB in fact since
384kB were lost and not remappable by then). It was unbeatable for this
purpose, though I'm not aiming at making this possible nowadays, most
machines have at least a bit more RAM :-)

Willy

Re: [PATCH 3.18 08/20] tun/tap: sanitize TUNSETSNDBUF input

On Thu, Nov 16, 2017 at 04:25:13PM -0500, Craig Gallek wrote:
> On Thu, Nov 16, 2017 at 12:28 PM, Greg Kroah-Hartman
>  wrote:
> > 3.18-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Craig Gallek 
> >
> >
> > [ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d ]
> >
> > Syzkaller found several variants of the lockup below by setting negative
> > values with the TUNSETSNDBUF ioctl.  This patch adds a sanity check
> > to both the tun and tap versions of this ioctl.
> >
> >   watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389]
> >   Modules linked in:
> >   irq event stamp: 329692056
> >   hardirqs last  enabled at (329692055): [] 
> > _raw_spin_unlock_irqrestore+0x31/0x75
> >   hardirqs last disabled at (329692056): [] 
> > apic_timer_interrupt+0x98/0xb0
> >   softirqs last  enabled at (35659740): [] 
> > __do_softirq+0x328/0x48c
> >   softirqs last disabled at (35659731): [] 
> > irq_exit+0xbc/0xd0
> >   CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23
> >   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
> > 01/01/2011
> >   task: 880009452140 task.stack: 880006a2
> >   RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80
> >   RSP: 0018:880006a27c50 EFLAGS: 0282 ORIG_RAX: ff10
> >   RAX: 880009ac68d0 RBX: 880006a27ce0 RCX: 
> >   RDX: 0001 RSI: 880006a27ce0 RDI: 880009ac6900
> >   RBP: 880006a27c60 R08:  R09: 
> >   R10: 0001 R11: 0063ff00 R12: 880009ac6900
> >   R13: 880006a27cf8 R14: 0001 R15: 880006a27cf8
> >   FS:  7f4be4838700() GS:88000cc0() 
> > knlGS:
> >   CS:  0010 DS:  ES:  CR0: 80050033
> >   CR2: 20101000 CR3: 09616000 CR4: 06f0
> >   Call Trace:
> >prepare_to_wait+0x26/0xc0
> >sock_alloc_send_pskb+0x14e/0x270
> >? remove_wait_queue+0x60/0x60
> >tun_get_user+0x2cc/0x19d0
> >? __tun_get+0x60/0x1b0
> >tun_chr_write_iter+0x57/0x86
> >__vfs_write+0x156/0x1e0
> >vfs_write+0xf7/0x230
> >SyS_write+0x57/0xd0
> >entry_SYSCALL_64_fastpath+0x1f/0xbe
> >   RIP: 0033:0x7f4be4356df9
> >   RSP: 002b:7ffc18101c08 EFLAGS: 0293 ORIG_RAX: 0001
> >   RAX: ffda RBX:  RCX: 7f4be4356df9
> >   RDX: 0046 RSI: 20101000 RDI: 0005
> >   RBP: 7ffc18101c40 R08: 0001 R09: 0001
> >   R10: 0001 R11: 0293 R12: 559c75f64780
> >   R13: 7ffc18101d30 R14:  R15: 
> >
> > Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device")
> > Fixes: 20d29d7a916a ("net: macvtap driver")
> > Signed-off-by: Craig Gallek 
> > Reviewed-by: Eric Dumazet 
> > Signed-off-by: David S. Miller 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  drivers/net/macvtap.c |2 ++
> >  drivers/net/tun.c |4 
> >  2 files changed, 6 insertions(+)
> >
> > --- a/drivers/net/macvtap.c
> > +++ b/drivers/net/macvtap.c
> > @@ -1047,6 +1047,8 @@ static long macvtap_ioctl(struct file *f
> > case TUNSETSNDBUF:
> > if (get_user(u, up))
> > return -EFAULT;
> > +   if (s <= 0)
> > +   return -EINVAL;
> Yay build bot!  This 's' should be a 'u' in the 3.18 version.

Yes, that was a good catch, I'll go fix this up, thanks.

greg k-h

Re: drivers/net/wireless/broadcom/b43legacy/debugfs.c:224:23: error: implicit declaration of function 'debugfs_real_fops'

On Fri, Nov 17, 2017 at 09:15:46AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   cf9b0772f2e410645fece13b749bd56505b998b8
> commit: 7c8d469877b16d2c1cecf101a0abb7b218db85bc debugfs: add support for 
> more elaborate ->d_fsdata
> date:   9 days ago
> config: x86_64-randconfig-s1-11170747 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
> git checkout 7c8d469877b16d2c1cecf101a0abb7b218db85bc
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from include/linux/list.h:8:0,
> from include/linux/wait.h:6,
> from include/linux/wait_bit.h:7,
> from include/linux/fs.h:5,
> from drivers/net/wireless/broadcom/b43legacy/debugfs.c:26:
>drivers/net/wireless/broadcom/b43legacy/debugfs.c: In function 
> 'b43legacy_debugfs_read':
> >> drivers/net/wireless/broadcom/b43legacy/debugfs.c:224:23: error: implicit 
> >> declaration of function 'debugfs_real_fops' 
> >> [-Werror=implicit-function-declaration]
>  dfops = container_of(debugfs_real_fops(file),
>   ^
>include/linux/kernel.h:927:26: note: in definition of macro 'container_of'
>  void *__mptr = (void *)(ptr); \
>  ^~~
>include/linux/kernel.h:927:17: warning: cast to pointer from integer of 
> different size [-Wint-to-pointer-cast]
>  void *__mptr = (void *)(ptr); \
> ^
> >> drivers/net/wireless/broadcom/b43legacy/debugfs.c:224:10: note: in 
> >> expansion of macro 'container_of'
>  dfops = container_of(debugfs_real_fops(file),
>  ^~~~
>In file included from include/linux/linkage.h:4:0,
> from include/linux/fs.h:4,
> from drivers/net/wireless/broadcom/b43legacy/debugfs.c:26:
>include/linux/kernel.h:928:32: error: invalid type argument of unary '*' 
> (have 'int')
>  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
>^~
>include/linux/compiler.h:553:19: note: in definition of macro 
> '__compiletime_assert'
>   bool __cond = !(condition);\
>   ^
>include/linux/compiler.h:576:2: note: in expansion of macro 
> '_compiletime_assert'
>  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>  ^~~
>include/linux/build_bug.h:46:37: note: in expansion of macro 
> 'compiletime_assert'
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~
>include/linux/kernel.h:928:2: note: in expansion of macro 
> 'BUILD_BUG_ON_MSG'
>  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
>  ^~~~
>include/linux/kernel.h:928:20: note: in expansion of macro '__same_type'
>  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
>^~~
> >> drivers/net/wireless/broadcom/b43legacy/debugfs.c:224:10: note: in 
> >> expansion of macro 'container_of'
>  dfops = container_of(debugfs_real_fops(file),
>  ^~~~
>include/linux/kernel.h:929:18: error: invalid type argument of unary '*' 
> (have 'int')
> !__same_type(*(ptr), void),   \
>  ^~
>include/linux/compiler.h:553:19: note: in definition of macro 
> '__compiletime_assert'
>   bool __cond = !(condition);\
>   ^
>include/linux/compiler.h:576:2: note: in expansion of macro 
> '_compiletime_assert'
>  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>  ^~~
>include/linux/build_bug.h:46:37: note: in expansion of macro 
> 'compiletime_assert'
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~
>include/linux/kernel.h:928:2: note: in expansion of macro 
> 'BUILD_BUG_ON_MSG'
>  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
>  ^~~~
>include/linux/kernel.h:929:6: note: in expansion of macro '__same_type'
> !__same_type(*(ptr), void),   \
>  ^~~
> >> drivers/net/wireless/broadcom/b43legacy/debugfs.c:224:10: note: in 
> >> expansion of macro 'container_of'
>  dfops = container_of(debugfs_real_fops(file),
>  ^~~~
>In file included from include/linux/list.h:8:0,
> from include/linux/wait.h:6,
> from include/linux/wait_bit.h:7,
> from include/linux/fs.h:5,
> from drivers/net/wireless/broadcom/b43legacy/debugfs.c:26:
>drivers/net/wireless/broadcom/b43legacy/debugfs.c: In

Re: [linux-sunxi] Cedrus driver

2017-11-17 Thread Maxime Ripard

Hi Nicolas,

On Thu, Nov 16, 2017 at 02:59:55PM -0500, Nicolas Dufresne wrote:
> Le jeudi 16 novembre 2017 à 12:02 +0100, Maxime Ripard a écrit :
> > Assuming that the request API is in, we'd need to:
> >   - Finish the MPEG4 support
> >   - Work on more useful codecs (H264 comes to my mind)
> 
> For which we will have to review the tables and make sure they match
> the spec (the easy part). But as an example, that branch uses a table
> that merge Mpeg4 VOP and VOP Short Header. We need to make sure it does
> not pause problems or split it up. On top of that, ST and Rockchip
> teams should give some help and sync with these tables on their side.
> We also need to consider decoder like Tegra 2. In H264, they don't need
> frame parsing, but just the PPS/SPS data (might just be parsed in the
> driver, like CODA ?). There is other mode of operation, specially in
> H264/HEVC low latency, where the decoder will be similar, but will
> accept and process slices right away, without waiting for the full
> frame.

Sorry if it's a dumb question, but what branches and tables are you
talking about here?

> We also need some doc, to be able to tell the GStreamer and FFMPEG team
> how to detect and handle these decoder. I doubt the libv4l2 proposed
> approach will be used for these two projects since they already have
> their own parser and would like to not parse twice. As an example, we
> need to document that V4L2_PIX_FMT_MPEG2_FRAME implies using the
> Request API and specific CID. We should probably also ping the Chrome
> Devs, which probably have couple of pending branches around this.

We've had a prototype that wasn't based on libv4l but was based on the
VA-API, and it's been working great for us so far.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH 3/5] ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC

From: Jian Hu 

There are four I2C masters in EE domain, and one I2C Master in
AO domain, the DT info here should describe them all.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 57faaa9d8013..99e967aff439 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -129,6 +129,54 @@
#reset-cells = <1>;
};
 
+   i2c_m0: i2c@1f000 {
+   compatible = "amlogic,meson-axg-i2c";
+   status = "disabled";
+   reg = <0x0 0x1f000 0x0 0x20>;
+   interrupts = ,
+   ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < CLKID_I2C>;
+   clock-names = "clk_i2c";
+   };
+
+   i2c_m1: i2c@1e000 {
+   compatible = "amlogic,meson-axg-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x1e000 0x0 0x20>;
+   status = "disabled";
+   interrupts = ,
+   ;
+   clocks = < CLKID_I2C>;
+   clock-names = "clk_i2c";
+   };
+
+   i2c_m2: i2c@1d000 {
+   compatible = "amlogic,meson-axg-i2c";
+   status = "disabled";
+   reg = <0x0 0x1d000 0x0 0x20>;
+   interrupts = ,
+   ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < CLKID_I2C>;
+   clock-names = "clk_i2c";
+   };
+
+   i2c_m3: i2c@1c000 {
+   compatible = "amlogic,meson-axg-i2c";
+   status = "disabled";
+   reg = <0x0 0x1c000 0x0 0x20>;
+   interrupts = ,
+   ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < CLKID_I2C>;
+   clock-names = "clk_i2c";
+   };
+
uart_A: serial@24000 {
compatible = "amlogic,meson-gx-uart", 
"amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -312,6 +360,17 @@
};
};
 
+   i2c_ao: i2c@5000 {
+   compatible = "amlogic,meson-axg-i2c";
+   status = "disabled";
+   reg = <0x0 0x05000 0x0 0x20>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < CLKID_I2C>;
+   clock-names = "clk_i2c";
+   };
+
uart_AO: serial@3000 {
compatible = "amlogic,meson-gx-uart", 
"amlogic,meson-ao-uart";
reg = <0x0 0x3000 0x0 0x18>;
-- 
2.14.1

[PATCH 0/5] i2c: meson-axg: add I2C controller driver

This patch set try to add I2C controller driver for
the Amlogic's Meson-AXG SoC.

Jian Hu (5):
  dt-bindings: i2c: update documentation for the Meson-AXG
  i2c: meson: add configurable divider factors
  ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC
  ARM64: dts: meson-axg: describe pin DT info for I2C controller
  ARM64: dts: meson-axg: enable I2C Master-1 for the audio speaker

 .../devicetree/bindings/i2c/i2c-meson.txt  |   1 +
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts |   6 +
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 123 +
 drivers/i2c/busses/i2c-meson.c |  32 +-
 4 files changed, 158 insertions(+), 4 deletions(-)

-- 
2.14.1

[PATCH 5/5] ARM64: dts: meson-axg: enable I2C Master-1 for the audio speaker

From: Jian Hu 

In the S400 board, The I2C master-1 is connecting to
the audio speaker daughter board.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts 
b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 7b39a9fe2b0f..74730e40f992 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -28,3 +28,9 @@
pinctrl-0 = <_rgmii_y_pins>;
pinctrl-names = "default";
 };
+
+_m1 {
+   status = "okay";
+   pinctrl-0 = <_m1_z_pins>;
+   pinctrl-names = "default";
+};
-- 
2.14.1

[PATCH 1/5] dt-bindings: i2c: update documentation for the Meson-AXG

From: Jian Hu 

Update the doc to explicitly add Meson-AXG to support list

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt 
b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
index 611b934c7e10..3097d2b44dad 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
@@ -2,6 +2,7 @@ Amlogic Meson I2C controller
 
 Required properties:
  - compatible: must be "amlogic,meson6-i2c" or "amlogic,meson-gxbb-i2c"
+   "amlogic,meson-axg-i2c"
  - reg: physical address and length of the device registers
  - interrupts: a single interrupt specifier
  - clocks: clock for the device
-- 
2.14.1

[PATCH 2/5] i2c: meson: add configurable divider factors

From: Jian Hu 

This patch try to add support for I2C controller in Meson-AXG SoC,
Due to the IP changes between I2C controller, we need to introduce
a compatible data to make the divider factor configurable.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 drivers/i2c/busses/i2c-meson.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
index 88d15b92ec35..517f2cddeff3 100644
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -57,6 +58,10 @@ enum {
STATE_WRITE,
 };
 
+struct meson_i2c_data {
+   unsigned char div_factor;
+};
+
 /**
  * struct meson_i2c - Meson I2C device private data
  *
@@ -93,6 +98,8 @@ struct meson_i2c {
struct completion   done;
u32 tokens[2];
int num_tokens;
+
+   struct meson_i2c_data *data;
 };
 
 static void meson_i2c_set_mask(struct meson_i2c *i2c, int reg, u32 mask,
@@ -128,7 +135,7 @@ static void meson_i2c_set_clk_div(struct meson_i2c *i2c, 
unsigned int freq)
unsigned long clk_rate = clk_get_rate(i2c->clk);
unsigned int div;
 
-   div = DIV_ROUND_UP(clk_rate, freq * 4);
+   div = DIV_ROUND_UP(clk_rate, freq * i2c->data->div_factor);
 
/* clock divider has 12 bits */
if (div >= (1 << 12)) {
@@ -376,6 +383,9 @@ static int meson_i2c_probe(struct platform_device *pdev)
spin_lock_init(>lock);
init_completion(>done);
 
+   i2c->data = (struct meson_i2c_data *)
+   of_device_get_match_data(>dev);
+
i2c->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(i2c->clk)) {
dev_err(>dev, "can't get device clock\n");
@@ -440,11 +450,25 @@ static int meson_i2c_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct meson_i2c_data i2c_meson6_data = {
+   .div_factor = 4,
+};
+
+static const struct meson_i2c_data i2c_gxbb_data = {
+   .div_factor = 4,
+};
+
+static const struct meson_i2c_data i2c_axg_data = {
+   .div_factor = 3,
+};
+
 static const struct of_device_id meson_i2c_match[] = {
-   { .compatible = "amlogic,meson6-i2c" },
-   { .compatible = "amlogic,meson-gxbb-i2c" },
-   { },
+   { .compatible = "amlogic,meson6-i2c", .data = _meson6_data },
+   { .compatible = "amlogic,meson-gxbb-i2c", .data = _gxbb_data },
+   { .compatible = "amlogic,meson-axg-i2c", .data = _axg_data },
+   {},
 };
+
 MODULE_DEVICE_TABLE(of, meson_i2c_match);
 
 static struct platform_driver meson_i2c_driver = {
-- 
2.14.1

[PATCH 4/5] ARM64: dts: meson-axg: describe pin DT info for I2C controller

From: Jian Hu 

Describe all the pin mux for the I2C controller which found in
Meson-AXG SoC.

Signed-off-by: Jian Hu 
Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 99e967aff439..edbfd6022078 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -304,6 +304,70 @@
function = "eth";
};
};
+
+   i2c_m0_pins: i2c_m0 {
+   mux {
+   groups = "i2c_sck_m0",
+   "i2c_sda_m0";
+   function = "i2c_m0";
+   };
+   };
+
+   i2c_m1_z_pins: i2c_m1_z {
+   mux {
+   groups = "i2c_sck_m1_z",
+   "i2c_sda_m1_z";
+   function = "i2c_m1";
+   };
+   };
+
+   i2c_m1_x_pins: i2c_m1_x {
+   mux {
+   groups = "i2c_sck_m1_x",
+   "i2c_sda_m1_x";
+   function = "i2c_m1";
+   };
+   };
+
+   i2c_m2_x_pins: i2c_m2_x {
+   mux {
+   groups = "i2c_sck_m2_x",
+   "i2c_sda_m2_x";
+   function = "i2c_m2";
+   };
+   };
+
+   i2c_m2_a_pins: i2c_m2_a {
+   mux {
+   groups = "i2c_sck_m2_a",
+   "i2c_sda_m2_a";
+   function = "i2c_m2";
+   };
+   };
+
+   i2c_m3_a6_pins: i2c_m3_a6 {
+   mux {
+   groups = "i2c_sda_m3_a6",
+   "i2c_sck_m3_a7";
+   function = "i2c_m3";
+   };
+   };
+
+   i2c_m3_a12_pins: i2c_m3_a12 {
+   mux {
+   groups = "i2c_sda_m3_a12",
+   "i2c_sck_m3_a13";
+   function = "i2c_m3";
+   };
+   };
+
+   i2c_m3_a19_pins: i2c_m3_a19 {
+   mux {
+   groups = "i2c_sda_m3_a19",
+   "i2c_sck_m3_a20";
+   function = "i2c_m3";
+   };
+   };
};
};
 
-- 
2.14.1

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

2017-11-17 Thread LEROY Christophe


Meelis Roos  a écrit :


> For me, 4.13 worked and 4.14 hangs early during boot. Bisecting led to
> the following commit. I had STRICT_KERNEL_RWX enabled when I met the
> option. When I disabled STRICT_KERNEL_RWX, the same kernel booted fine.

Can you please check that 4.13 boots properly with 'nobats' kernel  
parametre ?


Yes, 4.13.0 with nobats works.


How early does it hang ? Any oops or trace ?

Christophe





Christophe

>
>
> 95902e6c8864d39b09134dcaa3c99d8161d1deea is the first bad commit
> commit 95902e6c8864d39b09134dcaa3c99d8161d1deea
> Author: Christophe Leroy 
> Date:   Wed Aug 2 15:51:05 2017 +0200
>
>powerpc/mm: Implement STRICT_KERNEL_RWX on PPC32
>
>This patch implements STRICT_KERNEL_RWX on PPC32.
>
>As for CONFIG_DEBUG_PAGEALLOC, it deactivates BAT and LTLB mappings
>in order to allow page protection setup at the level of each page.
>
>As BAT/LTLB mappings are deactivated, there might be a performance
>impact.
>
>Signed-off-by: Christophe Leroy 
>Signed-off-by: Michael Ellerman 
>
> :04 04 1eac3de57642856e31a914da2e1fe5368095f04b
> ee3634b9ae309852feebc69b8a6bd473944e212c M  arch
>
>
> Config:
>
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/powerpc 4.13.0-rc2 Kernel Configuration
> #
> # CONFIG_PPC64 is not set
>
> #
> # Processor support
> #
> CONFIG_PPC_BOOK3S_32=y
> # CONFIG_PPC_85xx is not set
> # CONFIG_PPC_8xx is not set
> # CONFIG_40x is not set
> # CONFIG_44x is not set
> # CONFIG_E200 is not set
> CONFIG_PPC_BOOK3S=y
> CONFIG_6xx=y
> CONFIG_PPC_FPU=y
> CONFIG_ALTIVEC=y
> CONFIG_PPC_STD_MMU=y
> CONFIG_PPC_STD_MMU_32=y
> # CONFIG_PPC_MM_SLICES is not set
> CONFIG_PPC_HAVE_PMU_SUPPORT=y
> # CONFIG_FORCE_SMP is not set
> # CONFIG_SMP is not set
> # CONFIG_PPC_DOORBELL is not set
> CONFIG_VDSO32=y
> CONFIG_CPU_BIG_ENDIAN=y
> CONFIG_PPC32=y
> CONFIG_32BIT=y
> # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
> # CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MAX=17
> CONFIG_ARCH_MMAP_RND_BITS_MIN=11
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=17
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
> # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
> # CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set
> CONFIG_NR_IRQS=512
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
> CONFIG_PPC=y
> # CONFIG_GENERIC_CSUM is not set
> CONFIG_EARLY_PRINTK=y
> CONFIG_PANIC_TIMEOUT=180
> CONFIG_GENERIC_NVRAM=y
> CONFIG_SCHED_OMIT_FRAME_POINTER=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> # CONFIG_PPC_UDBG_16550 is not set
> # CONFIG_GENERIC_TBSYNC is not set
> CONFIG_AUDIT_ARCH=y
> CONFIG_GENERIC_BUG=y
> # CONFIG_EPAPR_BOOT is not set
> # CONFIG_DEFAULT_UIMAGE is not set
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> # CONFIG_PPC_DCR_NATIVE is not set
> # CONFIG_PPC_DCR_MMIO is not set
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_PGTABLE_LEVELS=2
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
>
> #
> # General setup
> #
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_KERNEL_GZIP=y
> CONFIG_DEFAULT_HOSTNAME="pohl"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> # CONFIG_USELIB is not set
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
>
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
> CONFIG_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> # CONFIG_GENERIC_IRQ_DEBUGFS is not set
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CMOS_UPDATE=y
>
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
>
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> # CONFIG_BSD_PROCESS_ACCT is not set
> # CONFIG_TASKSTATS is not set
>
> #
> # RCU Subsystem
> #
> CONFIG_TINY_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> CONFIG_TINY_SRCU=y
> # CONFIG_TASKS_RCU is not set
> # CONFIG_RCU_STALL_COMMON is not set
> # CONFIG_RCU_NEED_SEGCBLIST is not set
> # CONFIG_BUILD_BIN2C is not set
> # CONFIG_IKCONFIG is not set
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
> CONFIG_CGROUPS=y
> # CONFIG_MEMCG is not set
> #

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Thu, Nov 16, 2017 at 03:24:46PM -0800, Josh Hunt wrote:
> On Thu, Nov 16, 2017 at 3:13 PM,   wrote:
> >
> > It's possible, but I didn't want to add a bunch of clutter to the
> > commit message. Right now it's somewhat easy to track it back to
> > automatic selection because:
> >
> >  1. I'm signed off on all of them, so I could chime in in the case
> > concerns/issues arise with a patch.
> >  2. They all have a corresponding review request email with the
> > AUTOSEL marker.
> >
> 
> I get the want to not clutter the commit logs. My comment was more
> directed to a few weeks or months after the patch has made it into a
> stable release. At that point I'm not sure the person who found the
> problem with the change would know to CC you on any correspondence, or
> even if the author of the change would know to contact you. Although I
> guess maybe they'd eventually track things down and report to stable,
> or Greg, or something else and it would eventually get back to you.

If they report it to stable@vger (as they should), it is trivial for us
to look in the logs to see where the patch came from.  It turns out that
the way Sasha formats these patches makes it obvious to me that it was
an auto-selected patch, so I can easily see that even without looking in
the email history.

So don't worry about us not being able to track things down, we are good
at that :)

thanks,

greg k-h

Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

2017-11-17 Thread Oleksandr Andrushchenko

ping

On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote:

Hi, all!

Foreword

This RFC is aimed to introduce support of para-virtualized sound frontend
driver for Xen [1] and gather opinions from the relevant communities
(ALSA, Xen). It implements the protocol from [2] with the
following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the use-cases
(at the moment) are based on scenarios where unprivileged OS
(e.g. Android, AGL etc) uses software mixers.
Both capture and playback are supported.

The relevant backend is implemented as a user-space application [3]
and uses accompanying helper library [4].

Both frontend driver and backend were tested on real HW running Xen
hypervisor

(Renesas R-Car ARM based H3/M3 boards, x86).

Discussion
==

During the first attempt to upstream the driver [5] number of comments
and
concerns were raised, one of the biggest flaws in the design were
questioned

by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
synchronization between frontend and backend during capture/playback.
Two options were discussed:

“In design of ALSA PCM core, drivers are expected to synchronize to
actual hardwares for semi-realtime data transmission. The
synchronization is done by two points:
1) Interrupts to respond events from actual hardwares.
2) Positions of actual data transmission in any serial sound interfaces
of actual hardwares.
“

and finally a change to the existing protocol was suggested:

“In 'include/xen/interface/io/sndif.h', there's no functionalities I
described the above:
1. notifications from DomU to Dom0 about the size of period for
interrupts from actual hardwares. Or no way from Dom0 to DomU about
the configured size of the period.
2. notifications of the interrupts from actual hardwares to DomU.”

This is implemented as a change to the sndif protocol [8] and allows
removing

period emulation:
1. Introduced a new event channel from back to front
2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS,
to be used for sending snd_pcm_period_elapsed at frontend (in Linux
implementation). Sent in bytes, not frames to make the protocol
generic and consistent)
3. New request for playback/capture control (XENSND_OP_TRIGGER) with
start/pause/stop/resume sub-ops.

Along with these changes other comments on the driver were addressed,
e.g. split into smaller chunks, moved the driver from misc to xen etc.

Hope, this helps to get the full picture of what was discussed and
makes it

possible to move forward.

Waiting for your valuable comments,

Thank you,
Oleksandr

[1] https://github.com/andr2000/linux/commits/snd_upstream_v1
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h

[3] https://github.com/xen-troops/snd_be
[4] https://github.com/xen-troops/libxenbe
[5] https://lkml.org/lkml/2017/8/7/363
[6]
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
[7]
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
[8]
https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed

___
Xen-devel mailing list
xen-de...@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH 4.13 00/44] 4.13.14-stable review

On Thu, Nov 16, 2017 at 03:45:46PM -0700, Shuah Khan wrote:
> On 11/16/2017 10:42 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.13.14 release.
> > There are 44 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Nov 18 17:28:05 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.14-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.13.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Great, thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH v3 4/5] remoteproc: qcom: Introduce sysmon

2017-11-17 Thread Chris Lew




On 11/16/2017 9:58 PM, Bjorn Andersson wrote:

On Thu 16 Nov 12:05 PST 2017, Chris Lew wrote:

+   req.event = SSCTL_SSR_EVENT_BEFORE_SHUTDOWN;


Are there plans to add the other SSR events to sysmon notifiers? I think the
SSCTL service expects to receive events about remote procs starting as well.



We could easily add support here to send out the AFTER_BOOTUP
notification, beyond that we would need to extend the subdev notifiers
as well.

But the downstream code paths does confuse me, can you confirm that
these messages are actually sent to the remote ssctl services?

Regards,
Bjorn



Yea the other three events are definitely sent to the remote. The remote 
side posts the events for other modules to query. I'm not sure if all of 
the events are used by other other modules though.


Thanks,
Chris
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] intel_ips: Convert timers to use timer_setup()

2017-11-17 Thread Kees Cook

On Fri, Nov 3, 2017 at 5:26 AM, Andy Shevchenko
 wrote:
> On Thu, Nov 2, 2017 at 9:55 PM, Kees Cook  wrote:
>> On Thu, Oct 5, 2017 at 1:41 AM, Andy Shevchenko
>>  wrote:
>>> On Thu, Oct 5, 2017 at 3:54 AM, Kees Cook  wrote:
 In preparation for unconditionally passing the struct timer_list pointer to
 all timer callbacks, switch to using the new timer_setup() and from_timer()
 to pass the timer pointer explicitly. Moves timer structure off stack and
 into struct ips_driver.
>>>
>>> Pushed to my testing queue, thanks!
>>
>> Hi,
>>
>> I don't see this in -next yet. Should the tip tree carry this conversion?
>
> I thought it was a result of discussion since we lack of patch that
> brought the core change.
>
> However, because I merged Wolfram's immutable branch in order to apply
> Hans' fix, I can carry your patch as well.
>
> Either would be fine with me.
>
> Going ahead, I applied it to my review and testing queue, thanks!

Hi again!

I'm just checking on this patch -- I haven't seen it in a pull request
to Linus yet (for the merge window he's threatened will be small).
This is one of the remaining conversion patches I need in v4.15. Is
this still planned to be merged for v4.15?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] qed: fix unnecessary call to memset cocci warnings

From: Vasyl Gomonovych 
Date: Thu, 16 Nov 2017 23:04:08 +0100

> Use kzalloc rather than kmalloc followed by memset with 0
> 
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c:1280:13-20: WARNING:
> kzalloc should be used for dcbx_info, instead of kmalloc/memset
> Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
> 
> Signed-off-by: Vasyl Gomonovych 

This patch doesn't even apply.

Re: [PATCH] net/netlabel: Add list_next_rcu() in rcu_dereference().

From: Tim Hansen 
Date: Thu, 16 Nov 2017 12:03:34 -0500

> Add list_next_rcu() for fetching next list in rcu_deference safely.
> 
> Found with sparse in linux-next tree on tag next-20171116.
> 
> Signed-off-by: Tim Hansen 

Applied.

Re: [PATCH] net: usb: hso.c: remove unneeded DRIVER_LICENSE #define

From: Greg Kroah-Hartman 
Date: Fri, 17 Nov 2017 15:19:39 +0100

> There is no need to #define the license of the driver, just put it in
> the MODULE_LICENSE() line directly as a text string.
> 
> This allows tools that check that the module license matches the source
> code license to work properly, as there is no need to unwind the
> unneeded dereference.
> 
> Cc: "David S. Miller" 
> Cc: Andreas Kemnade 
> Cc: Johan Hovold 
> Reported-by: Philippe Ombredanne 
> Signed-off-by: Greg Kroah-Hartman 

Applied.

[PATCH V2 0/3] perf/x86/intel: Add Branch Monitoring support

This patchset adds support for Intel's branch monitoring feature. This
feature uses heuristics to detect the occurrence of an ROP(Return Oriented
Programming) or ROP like(JOP: Jump oriented programming) attack. These
heuristics are based off certain performance monitoring statistics,
measured dynamically over a short configurable window period. ROP is a
malware trend in which the attacker can compromise a return pointer held
on the stack to redirect execution to a different desired instruction.

Currently, only the Cannonlake family of Intel processors support this
feature. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM.

Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a
Cannonlake system, the following perf events are added which can be viewed
with perf list:
  intel_bm/branch-misp/  [Kernel PMU event]
  intel_bm/call-ret/ [Kernel PMU event]
  intel_bm/far-branch/   [Kernel PMU event]
  intel_bm/indirect-branch-misp/ [Kernel PMU event]
  intel_bm/ret-misp/ [Kernel PMU event]
  intel_bm/rets/ [Kernel PMU event]

A perf-based kernel driver has been used to monitor the occurrence of
one of the 6 branch monitoring events. There are 2 counters that each
can select between one of these events for evaluation over a specified
instruction window size (0 to 1023). For each counter, a threshold value
(0 to 127) can be configured to set a point at which an interrupt is
generated. Each task can monitor a maximum of 2 events at any given time.

Apart from the kernel driver, this patchset adds CPUID of Cannonlake
processors to Intel family list and the Documentation/x86/intel_bm.txt
file with some information about Intel Branch monitoring.

Changes V0->V1:
1. Used the 'is_sampling_event' function
2. Added support to monitor 2 events for every task
3. Corrected typos
4. Added a lock to prevent race condition in concurrent perf_event_open()s
5. Got rid of start()/stop() and added its functionality in add()/del()
6. Removed read() callback as it was not doing anything.
6. Removed code for sampling events as we do not support sampling.
7. Added 'id' member to hw_perf_event::intel_bm to track which counter the
event is using.
8. Moved MSR accesses to the add()/del() callbacks

Changes V1->V2:
1. Edited commit message to make things less ambiguous
2. Corrected the Signed-off-by chain
3. Used a named construct for the counter enable bit
4. Added the corrected logic to unmask NMI bit of local APIC only for the
   first time a task is scheduled on a CPU. Removed the separate function
5. Restructured code in the NMI handler to save convoluted indentation
6. Removed the redundant read of the status register in add()
7. Removed the update function as it did not do what it is supposed to do
   Added this code to del() instead
8. Corrected the polarity of 'is_sampling_event' function when used
9. Removed the setting of event->count to 0 in event_init. This is
   redundant as this is its default value
10. Do not allow threshold to be set as 0

Megha Dey (3):
  x86/cpu/intel: Add Cannonlake to Intel family
  perf/x86/intel/bm.c: Add Intel Branch Monitoring support
  x86, bm: Add documentation on Intel Branch Monitoring

 Documentation/x86/intel_bm.txt  | 216 +
 arch/x86/events/Kconfig |  10 +
 arch/x86/events/intel/Makefile  |   2 +
 arch/x86/events/intel/bm.c  | 605 
 arch/x86/include/asm/intel-family.h |   2 +
 arch/x86/include/asm/msr-index.h|   5 +
 arch/x86/include/asm/processor.h|   4 +
 include/linux/perf_event.h  |   9 +-
 kernel/events/core.c|  16 +
 9 files changed, 868 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/x86/intel_bm.txt
 create mode 100644 arch/x86/events/intel/bm.c

-- 
1.9.1

[PATCH V2 1/3] x86/cpu/intel: Add Cannonlake to Intel family

Add CPUID of Cannonlake (CNL) processors to Intel family list.

Signed-off-by: Megha Dey 
---
 arch/x86/include/asm/intel-family.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/include/asm/intel-family.h 
b/arch/x86/include/asm/intel-family.h
index 35a6bc4..056bd41 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -65,6 +65,8 @@
 #define INTEL_FAM6_ATOM_DENVERTON  0x5F /* Goldmont Microserver */
 #define INTEL_FAM6_ATOM_GEMINI_LAKE0x7A
 
+#define INTEL_FAM6_CANNONLAKE_MOBILE   0x66
+
 /* Xeon Phi */
 
 #define INTEL_FAM6_XEON_PHI_KNL0x57 /* Knights Landing */
-- 
1.9.1

[PATCH V2 3/3] x86, bm: Add documentation on Intel Branch Monitoring

This patch adds the Documentation/x86/intel_bm.txt file with some
information about Intel Branch monitoring.

Signed-off-by: Megha Dey 
---
 Documentation/x86/intel_bm.txt | 216 +
 1 file changed, 216 insertions(+)
 create mode 100644 Documentation/x86/intel_bm.txt

diff --git a/Documentation/x86/intel_bm.txt b/Documentation/x86/intel_bm.txt
new file mode 100644
index 000..25b7177
--- /dev/null
+++ b/Documentation/x86/intel_bm.txt
@@ -0,0 +1,216 @@
+Intel(R) Branch Monitoring
+
+Copyright (C) 2017 Intel Corporation
+
+Megha Dey 
+Yu-Cheng Yu 
+
+I. Overview
+===
+
+The Cannonlake family of Intel processors support the branch monitoring
+feature. This feature uses heuristics to detect the occurrence of an ROP
+(Return Oriented Programming) or ROP like(JOP:Jump oriented programming)
+attack. These heuristics are based off certain performance monitoring
+statistics, measured dynamically over a short configurable window period.
+ROP is a malware trend in which the attacker can compromise a return
+pointer held on the stack to redirect execution to a different desired
+instruction.
+
+Support for branch monitoring has been added via Linux kernel perf event
+infrastructure. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM.
+
+Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a
+Cannonlake system, the following perf events are added which can be viewed
+with perf list:
+  intel_bm/branch-misp/  [Kernel PMU event]
+  intel_bm/call-ret/ [Kernel PMU event]
+  intel_bm/far-branch/   [Kernel PMU event]
+  intel_bm/indirect-branch-misp/ [Kernel PMU event]
+  intel_bm/ret-misp/ [Kernel PMU event]
+  intel_bm/rets/ [Kernel PMU event]
+
+II. Hardware details
+
+
+The MSRs associated with branch monitoring are as follows:
+
+1. BR_DETECT_CTRL : Branch Monitoring Global control
+   Used for enabling and configuring global capability
+
+2. BR_DETECT_STATUS : Branch Monitoring Global Status
+   Used by SW handler for determining detect status
+
+3. BR_DETECT_COUNTER_CONFIG_i : Branch Monitoring Counter Configuration
+   Per-cpu branch monitoring counter Configuration
+
+There are 2 8-bit counters that each can select between one of the
+following 6 events:
+
+1. RET instructions: Counts the number of near return instructions retired
+
+2. CALL-RET instructions: Counts the difference between the number of near
+   return and call instructions retired
+
+3. RET mispredicts: Mispredicted return instructions retired
+
+4. Branch (all) mispredicts: Counts the number of mispredicted branches
+
+5. Indirect branch mispredicts: Counts the number of mispredicted indirect
+   near branch instructions. Includes indirect near jump/call instructions
+
+6. Far branch instructions: Counts the number of far branches retired
+
+Branch Monitoring hardware utilizes various existing performance related
+counter events. Of the 6 events above, only call-ret is newly implemented.
+
+The events are evaluated over a specified 10-bit instruction window size
+(0 to 1023). For each counter, a threshold value (0 to 127) can be
+configured to set a point at which an interrupt is generated and a
+detection event action is taken (determined by user-space). This can take
+the form of signaling an interrupt and/or freezing the state of the last
+branch record information.
+
+The event counters are reset after every 'window size' instructions by the
+hardware.
+
+The feature is for user mode (privilege level > 0) operation only, which is
+the known malware security threat target environment. While in supervisor
+mode, this heuristic detection counter activity is suspended. This behavior
+(user mode) is independent of root vs. non-root with respect to
+virtualization technology execution.
+
+III. Software Implementation
+
+
+A perf-based kernel driver has been used to monitor the occurrence of
+one of the 6 branch monitoring events.
+
+If an branch monitoring interrupt is generated, the interrupt bit is set
+which is cleared by interrupt handler and the event counters are reset.
+
+The entire system can monitor a maximum of 2 events at any given time.
+These events can belong to the same or different tasks.
+
+Everytime a task is scheduled out, we save current window and count
+associated with the event being monitored. When the task is scheduled next,
+we start counting from previous count associated with this event. Thus, a
+full context switch in this case is not necessary.
+
+The Branch Monitoring exception can be configured as a regular interrupt or
+an NMI. We chain an NMI handler after PMU, because
+1. It will not interfere with PMU events
+2. We only monitor for user-mode events, and this

[PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

Currently, the cannonlake family of Intel processors support the
branch monitoring feature. Intel's Branch monitoring feature is trying
to utilize heuristics to detect the occurrence of an ROP (Return
Oriented Programming) attack.

A perf-based kernel driver has been used to monitor the occurrence of
one of the 6 branch monitoring events. There are 2 counters that each
can select between one of these events for evaluation over a specified
instruction window size (0 to 1023). For each counter, a threshold value
(0 to 127) can be configured to set a point at which ROP detection event
action is taken (determined by user-space). Each task can monitor
a maximum of 2 events at any given time.

Apart from window_size(global) and threshold(per-counter), various sysfs
entries are provided for the user to configure: guest_disable, lbr_freeze,
window_cnt_sel, cnt_and_mode (all global) and mispred_evt_cnt(per-counter).
For all events belonging to the same task, the global parameters are
shared.

Everytime a task is scheduled out, we save current window and count
associated with the event being monitored. When the task is scheduled
next, we start counting from previous count associated with this event.

To monitor a user space application for ROP related events, perf command
line can be used as follows:

perf stat -e  

eg. For the following test program (test.c) and threshold = 100
(echo 100 > /sys/devices/intel_bm/threshold)

void func(void)
{
return;
}

void main(void)
{
int i;

for (i = 0; i < 128; i++) {
func();
}

return;
}

perf stat -e intel_bm/rets/ ./test

 Performance counter stats for './test':

 1  intel_bm/rets/

   0.104705937 seconds time elapsed

perf returns the number of branch monitoring interrupts occurred during
the execution of the user-space application.

Signed-off-by: Yu-Cheng Yu 
Signed-off-by: Megha Dey 
---
 arch/x86/events/Kconfig  |  10 +
 arch/x86/events/intel/Makefile   |   2 +
 arch/x86/events/intel/bm.c   | 605 +++
 arch/x86/include/asm/msr-index.h |   5 +
 arch/x86/include/asm/processor.h |   4 +
 include/linux/perf_event.h   |   9 +-
 kernel/events/core.c |  16 ++
 7 files changed, 650 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/events/intel/bm.c

diff --git a/arch/x86/events/Kconfig b/arch/x86/events/Kconfig
index 9a7a144..40903ca 100644
--- a/arch/x86/events/Kconfig
+++ b/arch/x86/events/Kconfig
@@ -9,6 +9,16 @@ config PERF_EVENTS_INTEL_UNCORE
Include support for Intel uncore performance events. These are
available on NehalemEX and more modern processors.
 
+config PERF_EVENTS_INTEL_BM
+   bool "Intel Branch Monitoring support"
+   depends on PERF_EVENTS && CPU_SUP_INTEL && PCI
+   ---help---
+ Include support for Intel Branch monitoring. This feature utilizes
+ heuristics for detecting ROP(Return oriented programming) like
+ attacks. These heuristics are based off certain performance
+ monitoring statistics, measured dynamically over a short
+ configurable window period.
+
 config PERF_EVENTS_INTEL_RAPL
tristate "Intel rapl performance events"
depends on PERF_EVENTS && CPU_SUP_INTEL && PCI
diff --git a/arch/x86/events/intel/Makefile b/arch/x86/events/intel/Makefile
index 3468b0c..14235ec 100644
--- a/arch/x86/events/intel/Makefile
+++ b/arch/x86/events/intel/Makefile
@@ -2,6 +2,8 @@
 obj-$(CONFIG_CPU_SUP_INTEL)+= core.o bts.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= ds.o knc.o
 obj-$(CONFIG_CPU_SUP_INTEL)+= lbr.o p4.o p6.o pt.o
+obj-$(CONFIG_PERF_EVENTS_INTEL_BM) += intel-bm-perf.o
+intel-bm-perf-objs := bm.o
 obj-$(CONFIG_PERF_EVENTS_INTEL_RAPL)   += intel-rapl-perf.o
 intel-rapl-perf-objs   := rapl.o
 obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE) += intel-uncore.o
diff --git a/arch/x86/events/intel/bm.c b/arch/x86/events/intel/bm.c
new file mode 100644
index 000..68d8f6d
--- /dev/null
+++ b/arch/x86/events/intel/bm.c
@@ -0,0 +1,605 @@
+/*
+ * Support for Intel branch monitoring counters
+ *
+ * Intel branch monitoring MSRs are specified in the Intel® 64 and IA-32
+ * Software Developer’s Manual Volume 4 section 2.16.2 (October 2017)
+ *
+ * Copyright (c) 2017, Intel Corporation.
+ *
+ * Contact Information:
+ * Megha Dey 
+ * Yu-Cheng Yu 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more

Re: [PATCH] rdma: Add Jason as a co-maintainer

2017-11-17 Thread Doug Ledford

On Fri, 2017-11-17 at 14:32 -0700, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 02:45:01PM -0500, Doug Ledford wrote:
> 
> > On that point...I have my github repo tied into the 0day infrastructure,
> > not the official repo.  I do that because I've publicly announced that
> > my github repo is a WIP repo, and that it might be rebased.  That allows
> > me to correct build issues by fixing up the broken patch and thereby
> > keep bisectability at its highest.  If you use a branch/tag on k.o for
> > your 0day testing, then fixes have to be incremental and depending on
> > which patch broke the build, there might be a significant segment of
> > code that is no longer bisectable.
> 
> .. and this is because the k.o repo is setup to disallow force push
> for each branch, so a 0 day testing branch cannot be rebased?

Well, there are ways around the system if you really wanted to do so. 
You can push to k.o with an empty ref, aka something like 'git push k.o
:k.o/for-next', which will delete the old branch.  Then you could rebase
it locally and repush it.  But that would make you a very evil person
and if Linus found out he would (rightfully!) yell at you for many
paragraphs with lots of all caps ;-).

The other option is to delete the bad branch and push a new branch with
a different name and the rebase already done.  I did that a couple times
in the early days of this job.  Now a days, I wouldn't even do this for
anything short of a disk corrupting issue or something like that.  I've
come to appreciate just how much people rely on unchanging commit IDs.

So the fact that the k.o repos don't allow non-fast-forward pushes is an
inconvenience, but it doesn't stop you from doing it if you really
wanted to.  But it's very bad form to do so, and that's the real reason
that I keep my 0day source on github and tell people regularly that my
github repo is a "rebase allowed" repo.

So, my workflow in order to prevent getting a bad branch on k.o goes
something like this:

1) Bundle up patches that belong together as a bundle in patchworks
2) Review patches
3) Download bundle from patchworks, apply using git -am.  Do any edits
to commit messages at this stage, either by hand editing the bundle file
before you run git -am, or afterwards by doing a git rebase -i.
4) Build locally and frequently as you take stuff in.  I suggest a build
between each bundle.  It's much easier to fix up errors when they aren't
buried 40 patches deep in your day's work.  I use partial builds for the
intermediate builds (make SUBDIRS=drivers/infiniband usually, but other
directories if the bundle touched code elsewhere).
5) When I think I'm basically done for the day, then I do a final, full
kernel build.
6) Push to 0day repo, wait for results.  This is a good time to do
whatever run testing you plan on doing for this push.
7) Push to k.o once 0day and your testing has passed.

Following that workflow minimizes the chances of having a broken push to
k.o.  If something does actually slip through this workflow, then you
just fix it incrementally unless leaving the issue will cause a meltdown
of the Internet or something.

The one thing it doesn't catch, which is actually what caused the time
or two I had to delete a branch and make a new branch on k.o, is when
you have to manually apply a patch because git am said the patch didn't
apply cleanly.

Most times, just running patch -p1 -l < .git/rebase-apply/patch gets the
patch in.  Git am will reject patches for any fuzz.  If we were using
git merge/pull, there is often enough context for git to know when to
allow the fuzz, but the am mode of git doesn't have that info and dumps
on very minor issues.

So you manually apply the patch, accepting some fuzz, and inspect the
result.  Where I screwed up in the past, is when the patch adds a
totally new file to the repo.  My usual workflow after applying the
patch manually, and then inspecting any suspect areas and hand editing
files when hunks get rejected, is to run git add -u.  This fails to add
new files to the commit.  So, I had to add an additional git status step
to see if there are any new, untracked files before I run the final git
am --continue.

If you split step 5 above into 5a) Push from local work repo to local
prep repo and 5b) Do full kernel build in prep repo to test that all
code needed to compile is tracked by git, it would catch that mistake
before it makes it outside the firewall.  That's a change I may make
just to be on the safe side in the future.

-- 
Doug Ledford 
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 7/8] net: ovs: remove unused hardirq.h

2017-11-17 Thread Yang Shi

It looks the email address of Pravin in MAINTAINERS file is obsolete, 
sent to the right address.


Yang


On 11/17/17 3:02 PM, Yang Shi wrote:

Preempt counter APIs have been split out, currently, hardirq.h just
includes irq_enter/exit APIs which are not used by openvswitch at all.

So, remove the unused hardirq.h.

Signed-off-by: Yang Shi 
Cc: Pravin Shelar 
Cc: "David S. Miller" 
Cc: d...@openvswitch.org
---
  net/openvswitch/vport-internal_dev.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/net/openvswitch/vport-internal_dev.c 
b/net/openvswitch/vport-internal_dev.c
index 04a3128..2f47c65 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -16,7 +16,6 @@
   * 02110-1301, USA
   */
  
-#include 

  #include 
  #include 
  #include

Re: [GIT PULL 1/2] Kbuild updates for v4.15

On Fri, Nov 17, 2017 at 9:22 AM, Masahiro Yamada
 wrote:
>
> Here are Kbuild updates for v4.15.  Please pull!

Mind checking that I got the CFLAGS_KCOV behavior right. The conflict
looked pretty simple, but somebody should check the ordering of the

   export CFLAGS_KCOV

vs the actual setting (that is now in scripts/Makefile.kcov.

It probably doesn't matter, but our makefiles are black magic.

  Linus

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

2017-11-17 Thread Patrick McLean



On 2017-11-17 04:55 PM, Linus Torvalds wrote:
> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean  wrote:
>>
>> I am still getting the crash at d9e12200852d, I figured I would
>> double-check the "good" and "bad" kernels before starting a full bisect.
> 
> .. but without GCC_PLUGIN_RANDSTRUCT it's solid?

Yes, without GCC_PLUGIN_RANDSTRUCT it's solid.

> Kees removed even the baseline "randomize pure function pointer
> structures", so at that commit, nothing should be randomized.
> 
> But maybe the plugin code itself ends up confusing gcc somehow?
> 
> Even when it doesn't actually do that "relayout_struct()" on the
> structure, it always does those TYPE_ATTRIBUTES() games.

[GIT] Networking


1) Revert regression inducing change to the IPSEC template resolver,
   from Steffen Klassert.

2) Peeloffs can cause the wrong sk to be waken up in SCTP, fix from
   Xin Long.

3) Min packet MTU size is wrong in cpsw driver, from Grygorii Strashko.

4) Fix build failure in netfilter ctnetlink, from Arnd Bergmann.

5) ISDN hisax driver checks pnp_irq() for errors incorrectly, from
   Arvind Yadav.

6) Fix fealnx driver build failure on MIPS, from Huacai Chen.

7) Fix into leak in SCTP, the scope_id of socket addresses is not
   always filled in.  From Eric W. Biederman.

8) MTU inheritance between physical function and representor fix
   in nfp driver, from Dirk van der Merwe.

9) Fix memory leak in rsi driver, from Colin Ian King.

10) Fix expiration and generation ID handling of cached ipv4
redirect routes, from Xin Long.

Please pull, thanks a lot!

The following changes since commit 6363b3f3ac5be096d08c8c504128befa0c033529:

  Merge tag 'ipmi-for-4.15' of git://github.com/cminyard/linux-ipmi (2017-11-15 
15:12:28 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 461ee7f3286dd50be4726606819c4228bc485a17:

  net: usb: hso.c: remove unneeded DRIVER_LICENSE #define (2017-11-18 10:37:00 
+0900)


Ahmed Abdelsalam (1):
  ipv6: sr: update the struct ipv6_sr_hdr

Arnd Bergmann (1):
  netfilter: add ifdef around ctnetlink_proto_size

Arvind Yadav (12):
  isdn: hisax: Fix pnp_irq's error checking for setup_asuscom
  isdn: hisax: Fix pnp_irq's error checking for avm_pnp_setup
  isdn: hisax: Fix pnp_irq's error checking for setup_diva_isapnp
  isdn: hisax: Fix pnp_irq's error checking for setup_elsa_isapnp
  isdn: hisax: Fix pnp_irq's error checking for setup_hfcsx
  isdn: hisax: Fix pnp_irq's error checking for setup_hfcs
  isdn: hisax: Handle return value of pnp_irq and pnp_port_start
  isdn: hisax: Fix pnp_irq's error checking for setup_isurf
  isdn: hisax: Fix pnp_irq's error checking for setup_ix1micro
  isdn: hisax: Fix pnp_irq's error checking for setup_niccy
  isdn: hisax: Fix pnp_irq's error checking for setup_sedlbauer_isapnp
  isdn: hisax: Fix pnp_irq's error checking for setup_teles3

Colin Ian King (2):
  qed: use kzalloc instead of kmalloc and memset
  rsi: fix memory leak on buf and usb_reg_buf

David S. Miller (3):
  Merge branch 'isdn-hisax-Fix-pnp_irq-error-checking'
  Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
  Merge branch 'nfp-flower-fixes-and-typo-in-ethtool-stats-name'

Desnes Augusto Nunes do Rosario (1):
  ibmvnic: fix dma_mapping_error call

Dirk van der Merwe (1):
  nfp: inherit the max_mtu from the PF netdev

Eric W. Biederman (1):
  net/sctp: Always set scope_id in sctp_inet6_skb_msgname

Girish Moodalbail (1):
  ipvlan: NULL pointer dereference panic in ipvlan_port_destroy

Greg Kroah-Hartman (1):
  net: usb: hso.c: remove unneeded DRIVER_LICENSE #define

Grygorii Strashko (1):
  net: ethernet: ti: cpsw: fix min eth packet size

Herbert Xu (1):
  xfrm: Copy policy family in clone_policy

Huacai Chen (1):
  fealnx: Fix building error on MIPS

Joel Stanley (1):
  virto_net: remove empty file 'virtio_net.'

John Hurley (2):
  nfp: register flower reprs for egress dev offload
  nfp: remove false positive offloads in flower vxlan

Jon Maloy (1):
  tipc: enforce valid ratio between skb truesize and contents

Michal Kubecek (1):
  genetlink: fix genlmsg_nlhdr()

Pieter Jansen van Vuuren (2):
  nfp: fix flower offload metadata flag usage
  nfp: fix vlan receive MAC statistics typo

Steffen Klassert (1):
  Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find."

Tim Hansen (1):
  net/netlabel: Add list_next_rcu() in rcu_dereference().

Vitaly Kuznetsov (1):
  hv_netvsc: preserve hw_features on mtu/channels/ringparam changes

Xin Long (6):
  sctp: do not free asoc when it is already dead in sctp_sendmsg
  sctp: use the right sk after waking up from wait_buf sleep
  sctp: check stream reset info len before making reconf chunk
  sctp: set frag_point in sctp_setsockopt_maxseg correctly
  route: update fnhe_expires for redirect when the fnhe exists
  route: also update fnhe_genid when updating a route cache

 drivers/isdn/hisax/asuscom.c |   2 +-
 drivers/isdn/hisax/avm_pci.c |   2 +-
 drivers/isdn/hisax/diva.c|   2 +-
 drivers/isdn/hisax/elsa.c|   2 +-
 drivers/isdn/hisax/hfc_sx.c  |   2 +-
 drivers/isdn/hisax/hfcscard.c|   2 +-
 drivers/isdn/hisax/hisax_fcpcipnp.c  |   2 +
 drivers/isdn/hisax/isurf.c   |   2 +-
 drivers/isdn/hisax/ix1_micro.c

Re: [GIT PULL 1/2] Kbuild updates for v4.15

Oh, and I forgot to ask..

On Fri, Nov 17, 2017 at 9:22 AM, Masahiro Yamada
 wrote:
>
> One of the most remarkable improvements in this cycle is, Kbuild is
> now able to cache the result of shell commands.

I see the "limit it to 500 lines", but I don't see any real coherency.

So I take it that if you upgrade your gcc version, you may need to
blow this cache away manually?

Or is there something subtle going on that I've missed?

FWIW, I still think we should probably make the compiler versions etc
available to the configuration management rather than necessarily
cache them.

Linus

RE: [GIT PULL 2/3] ARM: SoC driver updates for 4.15

2017-11-17 Thread Li, Philip

On Fri, Nov 17, 2017 at 7:50 AM, Fengguang Wu wrote:
> On Fri, Nov 17, 2017 at 12:25:12AM +0100, Arnd Bergmann wrote:
> >On Thu, Nov 16, 2017 at 11:29 PM, Linus Torvalds
> > wrote:
> >> On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann  wrote:
> >>>
> >>> ARM: SoC driver updates for v4.15
> >>
> >> No. This is completely broken, and I can't imagine that it has ever
> >> compiled for *anybody*.
> >>
> >>   drivers/soc/renesas/r8a77970-sysc.c:14:10: fatal error:
> >> dt-bindings/power/r8a77970-sysc.h: No such file or directory
> >>#include 
> >>
> >> and the compiler is completely right. This branch added that
> >> r8a77970-sysc.c file, but never added the header file.
> >>
> >> And it's not some odd merge mistake of mine: I checked. That error is
> >> there in the original branch too.
> >>
> >> Tssk.
> >
> >Right, I need to figure out how this could have slipped through. I did
> >get several "BUILD SUCCESS" mails from the kbuild bot (see
> >https://pastebin.com/JDw3EKDZ), which claims to have built it
> >successfully in all configurations, including allmodconfig builds on
> >arm/arm64 and x86-64. Fengguang, do you remember problems
> >with false-negatives recently?
> 
> Sorry I checked log and didn't find any 0day reports for that error.
> 
> It actually hit the errors several times:
> 
> drivers/soc/renesas/r8a77970-sysc.c:14:11: sparse: unable to open 'dt-
> bindings/power/r8a77970-sysc.h'
> 
> 2017-10-21 07:23:12 on arm-soc/next/drivers
> 1c6788e8746d5250ad9bd16e1e48140a396f4733 x86_64-allmodconfig
> 
> 
> drivers/soc/renesas/r8a77970-sysc.c:14:45: fatal error: dt-
> bindings/power/r8a77970-sysc.h: No such file or directory
> 
> 2017-11-03 07:45:22 on arm-soc/next/drivers
> 30f3b0678ce6fc46bcdde61ca35821032d0f25b5 i386-allmodconfig
> 2017-11-03 08:42:45 on arm-soc/next/drivers
> 30f3b0678ce6fc46bcdde61ca35821032d0f25b5 arm-allmodconfig
> 2017-11-03 08:43:06 on arm-soc/next/drivers
> 30f3b0678ce6fc46bcdde61ca35821032d0f25b5 arm64-allmodconfig
> 
> So the robot is not working well in that case, I'll work with Philip
> to get that fixed.
Thanks Arnd/Fengguang. After the investigation from Shun, it shows the bisect
works as expected and can identify the bad commit. But this missing report
issue is because the build test server that runs the bisect happens to have
permission issue that prevents mutt to lock the "sent" file. 

This is more serious than expected since the issue has been there for quite long
time. I apologize for the misleading information provided that there's no error
reported out. We will monitor all the details carefully.

> 
> Regards,
> Fengguang

Re: [PATCH v3 2/5] soc: qcom: Introduce QMI helpers

2017-11-17 Thread Chris Lew



On 11/15/2017 12:10 PM, Bjorn Andersson wrote:
[..]> +static void qmi_handle_message(struct qmi_handle *qmi,

+  struct sockaddr_qrtr *sq,
+  const void *buf, size_t len)
+{
+   const struct qmi_header *hdr;
+   struct qmi_txn tmp_txn;
+   struct qmi_txn *txn = NULL;
+   int ret;
+
+   if (len < sizeof(*hdr)) {
+   pr_err("ignoring short QMI packet\n");
+   return;
+   }
+
+   hdr = buf;
+
+   /* If this is a response, find the matching transaction handle */
+   if (hdr->type == QMI_RESPONSE) {
+   mutex_lock(>txn_lock);
+   txn = idr_find(>txns, hdr->txn_id);
+   if (txn)
+   mutex_lock(>lock);
+   mutex_unlock(>txn_lock);
+   }
+
+   if (txn && txn->dest && txn->ei) {
+   ret = qmi_decode_message(buf, len, txn->ei, txn->dest);
+   if (ret < 0)
+   pr_err("failed to decode incoming message\n");
+
+   txn->result = ret;
+   complete(>completion);
+
+   mutex_unlock(>lock);
+   } else if (txn) {
+   qmi_invoke_handler(qmi, sq, txn, buf, len);
+
+   mutex_unlock(>lock);
+   } else {
+   /* Create a txn based on the txn_id of the incoming message */
+   memset(_txn, 0, sizeof(tmp_txn));
+   tmp_txn.id = hdr->txn_id;
+
+   qmi_invoke_handler(qmi, sq, _txn, buf, len);


I'm seeing an opportunity for user error with timed out transactions. If 
txn_wait gets timed out the txn is removed from the txns list. Later if 
we get the response, it comes down to this else with the tmp_txn. Some 
handlers may try to do a complete(>completion) like the 
qmi_sample_client ping_pong_cb. This leads to a null pointer dereference 
since the temp txn was never initialized.


Should clients not call complete and we can call the complete in the 
else if(txn) condition?


Thanks,
Chris
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] dt-bindings: trivial-devices: Remove fsl,mc13892

2017-11-17 Thread Jonathan Neuschäfer

This device's bindings are not trivial: Additional properties are
documented in in Documentation/devicetree/bindings/mfd/mc13xxx.txt.

Signed-off-by: Jonathan Neuschäfer 
---
 Documentation/devicetree/bindings/trivial-devices.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
b/Documentation/devicetree/bindings/trivial-devices.txt
index af284fbd4d23..6e8fa1183210 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt
@@ -57,7 +57,6 @@ epson,rx8010  I2C-BUS INTERFACE REAL TIME CLOCK MODULE
 epson,rx8025   High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE
 epson,rx8581   I2C-BUS INTERFACE REAL TIME CLOCK MODULE
 fsl,mag3110MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
-fsl,mc13892MC13892: Power Management Integrated Circuit (PMIC) for 
i.MX35/51
 fsl,mma7660MMA7660FC: 3-Axis Orientation/Motion Detection Sensor
 fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic 
Accelerometer
 fsl,mpl3115MPL3115: Absolute Digital Pressure Sensor
-- 
2.11.0

Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit

2017-11-17 Thread Yafang Shao

2017-11-18 1:49 GMT+08:00 Shakeel Butt :
> On Fri, Nov 17, 2017 at 9:41 AM, Yafang Shao  wrote:
>> 2017-11-18 1:35 GMT+08:00 Shakeel Butt :
>>> On Fri, Nov 17, 2017 at 9:09 AM, Yafang Shao  wrote:
 2017-11-18 0:45 GMT+08:00 Roman Gushchin :
> On Sat, Nov 18, 2017 at 12:20:40AM +0800, Yafang Shao wrote:
>> 2017-11-17 23:55 GMT+08:00 Roman Gushchin :
>> > On Thu, Nov 16, 2017 at 08:43:17PM -0800, Shakeel Butt wrote:
>> >> On Thu, Nov 16, 2017 at 7:09 PM, Yafang Shao  
>> >> wrote:
>> >> > Currently the default tmpfs size is totalram_pages / 2 if mount 
>> >> > tmpfs
>> >> > without "-o size=XXX".
>> >> > When we mount tmpfs in a container(i.e. docker), it is also
>> >> > totalram_pages / 2 regardless of the memory limit on this container.
>> >> > That may easily cause OOM if tmpfs occupied too much memory when 
>> >> > swap is
>> >> > off.
>> >> > So when we mount tmpfs in a memcg, the default size should be 
>> >> > limited by
>> >> > the memcg memory.limit.
>> >> >
>> >>
>> >> The pages of the tmpfs files are charged to the memcg of allocators
>> >> which can be in memcg different from the memcg in which the mount
>> >> operation happened. So, tying the size of a tmpfs mount where it was
>> >> mounted does not make much sense.
>> >
>> > Also, memory limit is adjustable,
>>
>> Yes. But that's irrelevant.
>>
>> > and using a particular limit value
>> > at a moment of tmpfs mounting doesn't provide any warranties further.
>> >
>>
>> I can not agree.
>> The default size of tmpfs is totalram / 2, the reason we do this is to
>> provide any warranties further IMHO.
>>
>> > Is there a reason why the userspace app which is mounting tmpfs can't
>> > set the size based on memory.limit?
>>
>> That's because of misuse.
>> The application should set size with "-o size=" when mount tmpfs, but
>> not all applications do this.
>> As we can't guarantee that all applications will do this, we should
>> give them a proper default value.
>
> The value you're suggesting is proper only if an app which is mounting
> tmpfs resides in the same memcg

 Yes.
 But maybe that's mostly used today?

> and the memory limit will not be adjusted
> significantly later.

 There's a similar issue for physical memory adjusted by memory hotplug.
 So what will happen if the physical memory adjusted significantly later ?

> Otherwise you can end up with a default value, which
> is worse than totalram/2, for instance, if tmpfs is mounted by some 
> helper,
> which is located in a separate and very limited memcg.

 That may happen.
 Maybe we could improve the solution to handle this issue ?


>>>
>>> Let's backtrack, what is the actual concern? If a user/process inside
>>> a memcg is allocating pages for a file on a tmpfs mounted without size
>>> parameter, you want the OS to return ENOSPC (if allocation is done by
>>> write syscall) earlier to not cause the user/process's memcg to OOM.
>>> Is that right?
>>>
>>
>> Right.
>>
>>> First, there is no guarantee to not cause OOM by restricting tmpfs to
>>> half the size of memcg limit due to the presence of other memory
>>> charged to that memcg. The memcg can OOM even before the tmpfs hits
>>> its size.
>>>
>>
>> Just guarantee that the OOM not caused by misuse of tmpfs.
>>
>>> Second, the users who really care to avoid such scenario should just
>>> set the size parameter of tmpfs.
>>
>> Of couse that is the best way.
>> But we can not ensue all applications will do it.
>> That's why I introduce a proper defalut value for them.
>>
>
> I think we disagree on the how to get proper default value. Unless you
> can restrict that all the memory allocated for a tmpfs mount will be
> charged to a specific memcg, you should not just pick limit of the
> memcg of the process mounting the tmpfs to set the default of tmpfs
> mount. If you can restrict tmpfs charging to a specific memcg then the
> limit of that memcg should be used to set the default of the tmpfs
> mount. However this feature is not present in the upstream kernel at
> the moment (We have this feature in our local kernel and I am planning
> to upstream that).

That will be fine if you could upstream this feature ASAP :)


Thanks
Yafang

[PATCH v2 00/13] Modernization and fixes for NuBus subsystem

This series begins with cleanups and fixes for the NuBus subsystem and
finishes with a patch to add support for the Linux Driver Model.
The next series, which requires this one, will modernize NuBus drivers.

Changes since v1:
- Added the missing NULL check in nubus_device_remove().
- Squashed the two /proc/bus/nubus/s/ patches into one patch.
- Combined the two sets of /proc/bus/nubus file operations into one set.
- Used the name 'nubus_rsrc' instead of 'nubus_functional_resource'.
- Used the name 'nubus_device_register' instead of 'nubus_device_add'.
- Dropped the unused EXPORT_SYMBOL(nubus_seq_write_rsrc_mem).
- Replaced licensing text in the new file with SPDX-License-Identifier.


Finn Thain (13):
  nubus: Avoid array underflow and overflow
  nubus: Fix up header split
  nubus: Use static functions where possible
  nubus: Fix log spam
  nubus: Validate slot resource IDs
  nubus: Call proc_mkdir() not more than once per slot directory
  nubus: Remove redundant code
  nubus: Clean up whitespace
  nubus: Generalize block resource handling
  nubus: Rework /proc/bus/nubus/s/ implementation
  nubus: Rename struct nubus_dev
  nubus: Add expansion_type values for various Mac models
  nubus: Add support for the driver model

 arch/m68k/include/asm/macintosh.h   |   9 +-
 arch/m68k/mac/config.c  | 110 +++
 drivers/net/ethernet/8390/mac8390.c |  26 +-
 drivers/net/ethernet/natsemi/macsonic.c |  30 +-
 drivers/nubus/Makefile  |   2 +-
 drivers/nubus/bus.c |  85 ++
 drivers/nubus/nubus.c   | 501 ++--
 drivers/nubus/proc.c| 237 ---
 drivers/video/fbdev/macfb.c |   2 +-
 include/linux/nubus.h   | 198 -
 include/uapi/linux/nubus.h  |  23 --
 11 files changed, 720 insertions(+), 503 deletions(-)
 create mode 100644 drivers/nubus/bus.c

-- 
2.13.6

[PATCH v2 05/13] nubus: Validate slot resource IDs

While we are here, include the slot number in the related error messages.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index bdf3f4f96705..72536ef28bd7 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -616,7 +616,7 @@ static int __init nubus_get_board_resource(struct 
nubus_board *board, int slot,
nbtdata[0], nbtdata[1], nbtdata[2], nbtdata[3]);
if (nbtdata[0] != 1 || nbtdata[1] != 0 ||
nbtdata[2] != 0 || nbtdata[3] != 0)
-   pr_err("this sResource is not a board 
resource!\n");
+   pr_err("Slot %X: sResource is not a board 
resource!\n", slot);
break;
}
case NUBUS_RESID_NAME:
@@ -671,6 +671,7 @@ static struct nubus_board * __init nubus_add_board(int 
slot, int bytelanes)
unsigned long dpat;
struct nubus_dir dir;
struct nubus_dirent ent;
+   int prev_resid = -1;
 
/* Move to the start of the format block */
rp = nubus_rom_addr(slot);
@@ -710,10 +711,10 @@ static struct nubus_board * __init nubus_add_board(int 
slot, int bytelanes)
 
/* Directory offset should be small and negative... */
if (!(board->doffset & 0x00FF))
-   pr_warn("Dodgy doffset!\n");
+   pr_warn("Slot %X: Dodgy doffset!\n", slot);
dpat = nubus_get_rom(, 4, bytelanes);
if (dpat != NUBUS_TEST_PATTERN)
-   pr_warn("Wrong test pattern %08lx!\n", dpat);
+   pr_warn("Slot %X: Wrong test pattern %08lx!\n", slot, dpat);
 
/*
 *  I wonder how the CRC is meant to work -
@@ -739,12 +740,15 @@ static struct nubus_board * __init nubus_add_board(int 
slot, int bytelanes)
   for each of them. */
if (nubus_readdir(, ) == -1) {
/* We can't have this! */
-   pr_err("Board resource not found!\n");
+   pr_err("Slot %X: Board resource not found!\n", slot);
return NULL;
-   } else {
-   nubus_get_board_resource(board, slot, );
}
 
+   if (ent.type < 1 || ent.type > 127)
+   pr_warn("Slot %X: Board resource ID is invalid!\n", slot);
+
+   nubus_get_board_resource(board, slot, );
+
while (nubus_readdir(, ) != -1) {
struct nubus_dev *dev;
struct nubus_dev **devp;
@@ -753,6 +757,15 @@ static struct nubus_board * __init nubus_add_board(int 
slot, int bytelanes)
if (dev == NULL)
continue;
 
+   /* Resources should appear in ascending ID order. This sanity
+* check prevents duplicate resource IDs.
+*/
+   if (dev->resid <= prev_resid) {
+   kfree(dev);
+   continue;
+   }
+   prev_resid = dev->resid;
+
/* We zeroed this out above */
if (board->first_dev == NULL)
board->first_dev = dev;
-- 
2.13.6

[PATCH v2 02/13] nubus: Fix up header split

Due to the '#ifdef __KERNEL__' being located in the wrong place, some
definitions from the kernel API were placed in the UAPI header during
the scripted header split. Fix this. Also, remove the duplicate comment
which is only relevant to the UAPI header.

Fixes: 607ca46e97a1 ("UAPI: (Scripted) Disintegrate include/linux")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 include/linux/nubus.h  | 27 +++
 include/uapi/linux/nubus.h | 23 ---
 2 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/include/linux/nubus.h b/include/linux/nubus.h
index 18c300222362..a6edf7838e22 100644
--- a/include/linux/nubus.h
+++ b/include/linux/nubus.h
@@ -5,16 +5,28 @@
   Originally written by Alan Cox.
 
   Hacked to death by C. Scott Ananian and David Huggins-Daines.
-  
-  Some of the constants in here are from the corresponding
-  NetBSD/OpenBSD header file, by Allen Briggs.  We figured out the
-  rest of them on our own. */
+*/
+
 #ifndef LINUX_NUBUS_H
 #define LINUX_NUBUS_H
 
 #include 
 #include 
 
+struct nubus_dir {
+   unsigned char *base;
+   unsigned char *ptr;
+   int done;
+   int mask;
+};
+
+struct nubus_dirent {
+   unsigned char *base;
+   unsigned char type;
+   __u32 data; /* Actually 24 bits used */
+   int mask;
+};
+
 struct nubus_board {
struct nubus_board* next;
struct nubus_dev* first_dev;
@@ -130,4 +142,11 @@ void nubus_get_rsrc_mem(void *dest, const struct 
nubus_dirent *dirent,
 unsigned int len);
 void nubus_get_rsrc_str(char *dest, const struct nubus_dirent *dirent,
 unsigned int maxlen);
+
+/* Returns a pointer to the "standard" slot space. */
+static inline void *nubus_slot_addr(int slot)
+{
+   return (void *)(0xF000 | (slot << 24));
+}
+
 #endif /* LINUX_NUBUS_H */
diff --git a/include/uapi/linux/nubus.h b/include/uapi/linux/nubus.h
index f3776cc80f4d..48031e7858f1 100644
--- a/include/uapi/linux/nubus.h
+++ b/include/uapi/linux/nubus.h
@@ -221,27 +221,4 @@ enum nubus_display_res_id {
NUBUS_RESID_SIXTHMODE   = 0x0085
 };
 
-struct nubus_dir
-{
-   unsigned char *base;
-   unsigned char *ptr;
-   int done;
-   int mask;
-};
-
-struct nubus_dirent
-{
-   unsigned char *base;
-   unsigned char type;
-   __u32 data; /* Actually 24bits used */
-   int mask;
-};
-
-
-/* We'd like to get rid of this eventually.  Only daynaport.c uses it now. */
-static inline void *nubus_slot_addr(int slot)
-{
-   return (void *)(0xF000|(slot<<24));
-}
-
 #endif /* _UAPILINUX_NUBUS_H */
-- 
2.13.6

[PATCH v2 07/13] nubus: Remove redundant code

Eliminate unused values from struct nubus_dev to save wasted memory
(a Radius PrecisionColor 24X card has about 95 functional resources
and up to six such cards may be fitted). Also remove redundant static
variable initialization, an unreachable !MACH_IS_MAC conditional,
the unused nubus_find_device() function and the bogus get_nubus_list()
prototype.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 52 +--
 drivers/nubus/proc.c  |  2 --
 include/linux/nubus.h | 17 +
 3 files changed, 22 insertions(+), 49 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index 72536ef28bd7..7a0af37e52b8 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -282,23 +282,6 @@ EXPORT_SYMBOL(nubus_rewinddir);
 /* Driver interface functions, more or less like in pci.c */
 
 struct nubus_dev*
-nubus_find_device(unsigned short category, unsigned short type,
- unsigned short dr_hw, unsigned short dr_sw,
- const struct nubus_dev *from)
-{
-   struct nubus_dev *itor = from ? from->next : nubus_devices;
-
-   while (itor) {
-   if (itor->category == category && itor->type == type &&
-   itor->dr_hw == dr_hw && itor->dr_sw == dr_sw)
-   return itor;
-   itor = itor->next;
-   }
-   return NULL;
-}
-EXPORT_SYMBOL(nubus_find_device);
-
-struct nubus_dev*
 nubus_find_type(unsigned short category, unsigned short type,
const struct nubus_dev *from)
 {
@@ -469,8 +452,10 @@ nubus_get_functional_resource(struct nubus_board *board, 
int slot,
}
case NUBUS_RESID_NAME:
{
-   nubus_get_rsrc_str(dev->name, , sizeof(dev->name));
-   pr_debug("name: %s\n", dev->name);
+   char name[64];
+
+   nubus_get_rsrc_str(name, , sizeof(name));
+   pr_debug("name: %s\n", name);
break;
}
case NUBUS_RESID_DRVRDIR:
@@ -479,32 +464,39 @@ nubus_get_functional_resource(struct nubus_board *board, 
int slot,
   use this :-) */
struct nubus_dir drvr_dir;
struct nubus_dirent drvr_ent;
+   unsigned char *driver;
 
nubus_get_subdir(, _dir);
nubus_readdir(_dir, _ent);
-   dev->driver = nubus_dirptr(_ent);
-   pr_debug("driver at: 0x%p\n", dev->driver);
+   driver = nubus_dirptr(_ent);
+   pr_debug("driver at: 0x%p\n", driver);
break;
}
case NUBUS_RESID_MINOR_BASEOS:
+   {
/* We will need this in order to support
   multiple framebuffers.  It might be handy
   for Ethernet as well */
-   nubus_get_rsrc_mem(>iobase, , 4);
-   pr_debug("memory offset: 0x%08lx\n", dev->iobase);
+   u32 base_offset;
+
+   nubus_get_rsrc_mem(_offset, , 4);
+   pr_debug("memory offset: 0x%08x\n", base_offset);
break;
+   }
case NUBUS_RESID_MINOR_LENGTH:
+   {
/* Ditto */
-   nubus_get_rsrc_mem(>iosize, , 4);
-   pr_debug("memory length: 0x%08lx\n", dev->iosize);
+   u32 length;
+
+   nubus_get_rsrc_mem(, , 4);
+   pr_debug("memory length: 0x%08x\n", length);
break;
+   }
case NUBUS_RESID_FLAGS:
-   dev->flags = ent.data;
-   pr_debug("flags: 0x%06x\n", dev->flags);
+   pr_debug("flags: 0x%06x\n", ent.data);
break;
case NUBUS_RESID_HWDEVID:
-   dev->hwdevid = ent.data;
-   pr_debug("hwdevid: 0x%06x\n", dev->hwdevid);
+   pr_debug("hwdevid: 0x%06x\n", ent.data);
break;
default:
/* Local/Private resources have their own
@@ -837,8 +829,6 @@ static int __init nubus_init(void)
if (!MACH_IS_MAC)
return 0;
 
-   nubus_devices = NULL;
-   nubus_boards = NULL;
nubus_scan_bus();
nubus_proc_init();
return 0;
diff --git a/drivers/nubus/proc.c b/drivers/nubus/proc.c
index 91211192f36f..41ec859bdd8b 100644
--- a/drivers/nubus/proc.c
+++ b/drivers/nubus/proc.c
@@ -230,8 +230,6 @@ void __init

Re: [PATCH 1/4] documentation: Add compatibles for Amlogic Meson AXG pin controllers

2017-11-17 Thread Neil Armstrong

On 08/11/2017 07:47, Yixun Lan wrote:
> From: Xingyu Chen 
> 
> Add compatibles for Amlogic Meson AXG pin controllers
> 
> Signed-off-by: Xingyu Chen 
> Signed-off-by: Yixun Lan 
> ---
>  Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
> index 2392557ede27..2c12f9789116 100644
> --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
> @@ -9,6 +9,8 @@ Required properties for the root node:
> "amlogic,meson-gxbb-aobus-pinctrl"
> "amlogic,meson-gxl-periphs-pinctrl"
> "amlogic,meson-gxl-aobus-pinctrl"
> +   "amlogic,meson-axg-periphs-pinctrl"
> +   "amlogic,meson-axg-aobus-pinctrl"
>   - reg: address and size of registers controlling irq functionality
>  
>  === GPIO sub-nodes ===
> 

Reviewed-by: Neil Armstrong

Re: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

2017-11-17 Thread Michael S. Tsirkin

On Thu, Nov 16, 2017 at 09:27:24PM +0800, Wei Wang wrote:
> On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
> > On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
> > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
> > > support of reporting hints of guest free pages to the host via
> > > virtio-balloon. The host requests the guest to report the free pages by
> > > sending commands via the virtio-balloon configuration registers.
> > > 
> > > When the guest starts to report, the first element added to the free page
> > > vq is a sequence id of the start reporting command. The id is given by
> > > the host, and it indicates whether the following free pages correspond
> > > to the command. For example, the host may stop the report and start again
> > > with a new command id. The obsolete pages for the previous start command
> > > can be detected by the id dismatching on the host. The id is added to the
> > > vq using an output buffer, and the free pages are added to the vq using
> > > input buffer.
> > > 
> > > Here are some explainations about the added configuration registers:
> > > - host2guest_cmd: a register used by the host to send commands to the
> > > guest.
> > > - guest2host_cmd: written by the guest to ACK to the host about the
> > > commands that have been received. The host will clear the corresponding
> > > bits on the host2guest_cmd register. The guest also uses this register
> > > to send commands to the host (e.g. when finish free page reporting).
> > > - free_page_cmd_id: the sequence id of the free page report command
> > > given by the host.
> > > 
> > > Signed-off-by: Wei Wang 
> > > Signed-off-by: Liang Li 
> > > Cc: Michael S. Tsirkin 
> > > Cc: Michal Hocko 
> > > ---
> > > 
> > > +
> > > +static void report_free_page(struct work_struct *work)
> > > +{
> > > + struct virtio_balloon *vb;
> > > +
> > > + vb = container_of(work, struct virtio_balloon, report_free_page_work);
> > > + report_free_page_cmd_id(vb);
> > > + walk_free_mem_block(vb, 0, _balloon_send_free_pages);
> > > + /*
> > > +  * The last few free page blocks that were added may not reach the
> > > +  * batch size, but need a kick to notify the device to handle them.
> > > +  */
> > > + virtqueue_kick(vb->free_page_vq);
> > > + report_free_page_end(vb);
> > > +}
> > > +
> > I think there's an issue here: if pages are poisoned and hypervisor
> > subsequently drops them, testing them after allocation will
> > trigger a false positive.
> > 
> > The specific configuration:
> > 
> > PAGE_POISONING on
> > PAGE_POISONING_NO_SANITY off
> > PAGE_POISONING_ZERO off
> > 
> > 
> > Solutions:
> > 1. disable the feature in that configuration
> > suggested as an initial step
> 
> Thanks for the finding.
> Similar to this option: I'm thinking could we make walk_free_mem_block()
> simply return if that option is on?
> That is, at the beginning of the function:
> if (!page_poisoning_enabled())
> return;
> 
> I think in most usages, people would not choose to use the poisoning option
> due to the added overhead.
> 
> 
> Probably we could make it a separate fix patch of this report following
> patch 5 to explain the above reasons in the commit.
> 
> > 2. pass poison value to host so it can validate page content
> > before it drops it
> > 3. pass poison value to host so it can init allocated pages with that value
> > 
> > In fact one nice side effect would be that unmap
> > becomes safe even though free list is not locked anymore.
> 
> I haven't got this point yet,  how would it bring performance benefit?

Upon getting a free page, host could check that its content
matches the poison value. If it doesn't page has been used.

But let's ignore this for now.

> > It would be interesting to see whether this last has
> > any value performance-wise.
> > 
> 
> Best,
> Wei

Re: [PATCH 2/4] pinctrl: meson-axg: Introduce a pinctrl pinmux ops for Meson-AXG SoC

2017-11-17 Thread Neil Armstrong

On 08/11/2017 07:47, Yixun Lan wrote:
> From: Xingyu Chen 
> 
> The pin controller has been updated in the Amlogic Meson AXG series,
> which use continuous 4-bit register to select function for each pin.
> In order to support this, a new pinmux operations "meson_axg_pmx_ops"
> has been added.
> 
> Signed-off-by: Xingyu Chen 
> Signed-off-by: Yixun Lan 
> ---
>  drivers/pinctrl/meson/Kconfig |   3 +
>  drivers/pinctrl/meson/Makefile|   1 +
>  drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 118 
> ++
>  drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h |  62 ++
>  drivers/pinctrl/meson/pinctrl-meson.h |   1 +
>  5 files changed, 185 insertions(+)
>  create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
>  create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h
> 
> diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
> index 1a51778759ea..fe5e6ca88412 100644
> --- a/drivers/pinctrl/meson/Kconfig
> +++ b/drivers/pinctrl/meson/Kconfig
> @@ -38,4 +38,7 @@ config PINCTRL_MESON_GXL
>  config PINCTRL_MESON8_PMX
>   bool
>  
> +config PINCTRL_MESON_AXG_PMX
> + bool
> +
>  endif
> diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
> index cbd47bb74549..8de839512677 100644
> --- a/drivers/pinctrl/meson/Makefile
> +++ b/drivers/pinctrl/meson/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_PINCTRL_MESON8) += pinctrl-meson8.o
>  obj-$(CONFIG_PINCTRL_MESON8B) += pinctrl-meson8b.o
>  obj-$(CONFIG_PINCTRL_MESON_GXBB) += pinctrl-meson-gxbb.o
>  obj-$(CONFIG_PINCTRL_MESON_GXL) += pinctrl-meson-gxl.o
> +obj-$(CONFIG_PINCTRL_MESON_AXG_PMX) += pinctrl-meson-axg-pmx.o
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c 
> b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> new file mode 100644
> index ..e8931d9cf863
> --- /dev/null
> +++ b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
> @@ -0,0 +1,118 @@
> +/*
> + * Second generation of pinmux driver for Amlogic Meson-AXG SoC.
> + *
> + * Copyright (c) 2017 Baylibre SAS.
> + * Author:  Jerome Brunet  
> + *
> + * Copyright (c) 2017 Amlogic, Inc. All rights reserved.
> + * Author: Xingyu Chen 
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ or MIT)
> + */
> +
> +/*
> + * This new generation of pinctrl IP is mainly adopted by the
> + * Meson-AXG SoC and later series, which use 4-width continuous
> + * register bit to select the function for each pin.
> + *
> + * The value 0 is always selecting the GPIO mode, while other
> + * values (start from 1) for selecting the function mode.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-meson.h"
> +#include "pinctrl-meson-axg-pmx.h"
> +
> +static int meson_axg_pmx_get_bank(struct meson_pinctrl *pc,
> + unsigned int pin,
> + struct meson_pmx_bank **bank)
> +{
> + int i;
> + struct meson_axg_pmx_data *pmx = pc->data->pmx_data;
> +
> + for (i = 0; i < pmx->num_pmx_banks; i++)
> + if (pin >= pmx->pmx_banks[i].first &&
> + pin <= pmx->pmx_banks[i].last) {
> + *bank = >pmx_banks[i];
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int meson_pmx_calc_reg_and_offset(struct meson_pmx_bank *bank,
> + unsigned int pin, unsigned int *reg,
> + unsigned int *offset)
> +{
> + int shift;
> +
> + shift = pin - bank->first;
> +
> + *reg = bank->reg + (bank->offset + (shift << 2)) / 32;
> + *offset = (bank->offset + (shift << 2)) % 32;
> +
> + return 0;
> +}
> +
> +static int meson_axg_pmx_update_function(struct meson_pinctrl *pc,
> + unsigned int pin, unsigned int func)
> +{
> + int ret;
> + int reg;
> + int offset;
> + struct meson_pmx_bank *bank;
> +
> + ret = meson_axg_pmx_get_bank(pc, pin, );
> + if (ret)
> + return ret;
> +
> + meson_pmx_calc_reg_and_offset(bank, pin, , );
> +
> + ret = regmap_update_bits(pc->reg_mux, reg << 2,
> + 0xf << offset, (func & 0xf) << offset);
> +
> + return ret;
> +}
> +
> +static int meson_axg_pmx_set_mux(struct pinctrl_dev *pcdev,
> + unsigned int func_num, unsigned int group_num)
> +{
> + int i;
> + int ret;
> + struct meson_pinctrl *pc = pinctrl_dev_get_drvdata(pcdev);
> + struct meson_pmx_func *func = >data->funcs[func_num];
> + struct meson_pmx_group *group = >data->groups[group_num];
> + struct meson_pmx_axg_data *pmx_data =
> + (struct meson_pmx_axg_data *)group->data;
> +
> + dev_dbg(pc->dev, "enable function %s, group %s\n", func->name,
> + group->name);
> +
> + for (i = 0; i < group->num_pins; i++) {
> + ret =

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

2017-11-17 Thread Jarkko Sakkinen

On Tue, Nov 14, 2017 at 04:34:21PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 07, 2017 at 09:04:04AM -0700, Jason Gunthorpe wrote:
> > On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote:
> > 
> > > I am assuming you are talking about the following patches - using
> > > struct tpm_chip instead of chip number and this patch.
> > 
> > yes
> > 
> > > I won't be able to test if struct tpm_chip usage as I don't have
> > > multiple tpm hw in one machine. In case of tpm rng changes I can test
> > > only the lifecycle of tpm rng device. Is that enough? I feel my test
> > > will be limited. Please provide your thoughts on this.
> > 
> > That is certainly better than no testing.
> > 
> > Jason
> 
> WFM too.
> 
> Tested-by: Jarkko Sakkinen 
> Reviewed-by: Jarkko Sakkinen 
> 
> /Jarkko

I applied these commits. Please check that everything is correct as
I had to do manual work with the 2nd commit.

/Jarkko

[PATCH 07/10] staging: fsl-mc: remove some superfluous WARN_ONs

2017-11-17 Thread laurentiu.tudor

From: Laurentiu Tudor 

These WARN_ONs shouldn't trigger unless something went very wrong.
Since the driver is in a stable state let's remove these debug
WARN_ONs.

Signed-off-by: Laurentiu Tudor 
---
 drivers/staging/fsl-mc/bus/dprc-driver.c  |  8 
 drivers/staging/fsl-mc/bus/fsl-mc-allocator.c | 10 --
 drivers/staging/fsl-mc/bus/fsl-mc-bus.c   | 12 
 drivers/staging/fsl-mc/bus/fsl-mc-msi.c   |  1 -
 .../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c|  3 ---
 drivers/staging/fsl-mc/bus/mc-io.c| 19 ---
 6 files changed, 53 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dprc-driver.c 
b/drivers/staging/fsl-mc/bus/dprc-driver.c
index 06df528..d6a84dd 100644
--- a/drivers/staging/fsl-mc/bus/dprc-driver.c
+++ b/drivers/staging/fsl-mc/bus/dprc-driver.c
@@ -39,8 +39,6 @@ static int __fsl_mc_device_remove_if_not_in_mc(struct device 
*dev, void *data)
struct fsl_mc_child_objs *objs;
struct fsl_mc_device *mc_dev;
 
-   WARN_ON(!dev);
-   WARN_ON(!data);
mc_dev = to_fsl_mc_device(dev);
objs = data;
 
@@ -60,8 +58,6 @@ static int __fsl_mc_device_remove_if_not_in_mc(struct device 
*dev, void *data)
 
 static int __fsl_mc_device_remove(struct device *dev, void *data)
 {
-   WARN_ON(!dev);
-   WARN_ON(data);
fsl_mc_device_remove(to_fsl_mc_device(dev));
return 0;
 }
@@ -453,8 +449,6 @@ static int disable_dprc_irq(struct fsl_mc_device *mc_dev)
int error;
struct fsl_mc_io *mc_io = mc_dev->mc_io;
 
-   WARN_ON(mc_dev->obj_desc.irq_count != 1);
-
/*
 * Disable generation of interrupt, while we configure it:
 */
@@ -496,8 +490,6 @@ static int register_dprc_irq_handler(struct fsl_mc_device 
*mc_dev)
int error;
struct fsl_mc_device_irq *irq = mc_dev->irqs[0];
 
-   WARN_ON(mc_dev->obj_desc.irq_count != 1);
-
/*
 * NOTE: devm_request_threaded_irq() invokes the device-specific
 * function that programs the MSI physically in the device
diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c 
b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
index 8ea3920..d472a85 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-allocator.c
@@ -199,7 +199,6 @@ int __must_check fsl_mc_resource_allocate(struct fsl_mc_bus 
*mc_bus,
struct fsl_mc_resource, node);
 
if (!resource) {
-   WARN_ON(res_pool->free_count != 0);
error = -ENXIO;
dev_err(_bus_dev->dev,
"No more resources of type %s left\n",
@@ -474,7 +473,6 @@ int __must_check fsl_mc_allocate_irqs(struct fsl_mc_device 
*mc_dev)
irqs[i] = to_fsl_mc_irq(resource);
res_allocated_count++;
 
-   WARN_ON(irqs[i]->mc_dev);
irqs[i]->mc_dev = mc_dev;
irqs[i]->dev_irq_index = i;
}
@@ -516,7 +514,6 @@ void fsl_mc_free_irqs(struct fsl_mc_device *mc_dev)
return;
 
for (i = 0; i < irq_count; i++) {
-   WARN_ON(!irqs[i]->mc_dev);
irqs[i]->mc_dev = NULL;
fsl_mc_resource_free([i]->resource);
}
@@ -553,17 +550,10 @@ static void fsl_mc_cleanup_resource_pool(struct 
fsl_mc_device *mc_bus_dev,
_bus->resource_pools[pool_type];
int free_count = 0;
 
-   WARN_ON(res_pool->type != pool_type);
-   WARN_ON(res_pool->free_count != res_pool->max_count);
-
list_for_each_entry_safe(resource, next, _pool->free_list, node) {
free_count++;
-   WARN_ON(resource->type != res_pool->type);
-   WARN_ON(resource->parent_pool != res_pool);
devm_kfree(_bus_dev->dev, resource);
}
-
-   WARN_ON(free_count != res_pool->free_count);
 }
 
 void fsl_mc_cleanup_all_resource_pools(struct fsl_mc_device *mc_bus_dev)
diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c 
b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
index 409f2b9..1c2fd8d 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
@@ -162,12 +162,7 @@ static int fsl_mc_driver_probe(struct device *dev)
struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
int error;
 
-   if (WARN_ON(!dev->driver))
-   return -EINVAL;
-
mc_drv = to_fsl_mc_driver(dev->driver);
-   if (WARN_ON(!mc_drv->probe))
-   return -EINVAL;
 
error = mc_drv->probe(mc_dev);
if (error < 0) {
@@ -184,9 +179,6 @@ static int fsl_mc_driver_remove(struct device *dev)
struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
int error;
 
-   if (WARN_ON(!dev->driver))
-   return -EINVAL;
-
error =

[PATCH 03/10] staging: fsl-mc/dpio: drop EXPORT_SYMBOL() for a few functions

2017-11-17 Thread laurentiu.tudor

From: Laurentiu Tudor 

These functions are only used within this driver so no need for
EXPORT_SYMBOL().

Signed-off-by: Laurentiu Tudor 
---
 drivers/staging/fsl-mc/bus/dpio/dpio-service.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c 
b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
index 591d8b7..fca8c90dc 100644
--- a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
+++ b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
@@ -156,7 +156,6 @@ struct dpaa2_io *dpaa2_io_create(const struct dpaa2_io_desc 
*desc)
 
return obj;
 }
-EXPORT_SYMBOL(dpaa2_io_create);
 
 /**
  * dpaa2_io_down() - release the dpaa2_io object.
@@ -171,7 +170,6 @@ void dpaa2_io_down(struct dpaa2_io *d)
 {
kfree(d);
 }
-EXPORT_SYMBOL(dpaa2_io_down);
 
 #define DPAA_POLL_MAX 32
 
@@ -218,7 +216,6 @@ irqreturn_t dpaa2_io_irq(struct dpaa2_io *obj)
qbman_swp_interrupt_set_inhibit(swp, 0);
return IRQ_HANDLED;
 }
-EXPORT_SYMBOL(dpaa2_io_irq);
 
 /**
  * dpaa2_io_service_register() - Prepare for servicing of FQDAN or CDAN
-- 
2.9.4

[GIT PULL] s390 patches for the 4.15 merge window #2

2017-11-17 Thread Martin Schwidefsky

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:

The second part of the s390 patches for the 4.15 merge window:

 - Rework of the vdso code to avoid the use of the access register mode

 - Use perf AUX buffers for the transport of diagnostic sample data

 - Add perf_regs and user stack dump support

 - Enable perf call graphs for user space programs

 - Add perf register support for floating-point registers

 - All remaining s390 related timer_setup conversions

 - Bug fixes and cleanups.

The shortlog:

Heiko Carstens (8):
  s390/vdso: add missing boot_vdso_data declaration
  s390/spinlock: fix indentation
  s390/mm: remove unused code
  s390/nmi: remove unused code
  s390: enable CPU alternatives unconditionally
  s390/perf: add perf_regs support and user stack dump
  s390/perf: add support for perf_regs and libdw
  s390: remove unused parameter from Makefile

Hendrik Brueckner (6):
  s390/cpum_sf: do not register PMU if no sampling mode is authorized
  s390/perf: define common DWARF register string table
  s390/perf: extend perf_regs support to include floating-point registers
  s390/perf: add perf register support for floating-point registers
  s390/cpum_sf: load program parameter at sampler enablement
  s390/cpum_sf: correctly set the PID and TID in perf samples

Kees Cook (5):
  s390: qdio: Convert timers to use timer_setup()
  s390/cio: Convert timers to use timer_setup()
  s390/sclp: Convert timers to use timer_setup()
  s390/ap_bus: Convert timers to use timer_setup()
  s390/scsi: Convert timers to use timer_setup()

Martin Schwidefsky (2):
  s390/mm,kvm: improve detection of KVM guest faults
  s390: remove all code using the access register mode

Michael Holzheu (1):
  s390: Remove CONFIG_HARDENED_USERCOPY

Pu Hou (4):
  s390/cpumf: introduce AUX buffer for dump diagnostic sample data
  s390/cpumf: enable using AUX buffer
  s390/perf: add callback to perf to enable using AUX buffer
  s390/cpumf: remove raw event support in basic-only sampling mode

Steffen Maier (1):
  zfcp: purely mechanical update using timer API, plus blank lines

Vasily Gorbik (3):
  s390: correct some inline assembly constraints
  s390/kbuild: get rid of a warning when compiling with KCOV
  s390/disassembler: increase show_code buffer size

 arch/s390/Kconfig   |  19 +-
 arch/s390/configs/default_defconfig |   5 +-
 arch/s390/configs/gcov_defconfig|   4 -
 arch/s390/configs/performance_defconfig |   4 -
 arch/s390/include/asm/alternative.h |  20 +-
 arch/s390/include/asm/cpu_mf.h  |   8 +-
 arch/s390/include/asm/futex.h   |   9 +-
 arch/s390/include/asm/lowcore.h |  37 +-
 arch/s390/include/asm/mmu_context.h |  36 +-
 arch/s390/include/asm/perf_event.h  |  17 -
 arch/s390/include/asm/processor.h   |   6 +-
 arch/s390/include/asm/ptrace.h  |   2 +
 arch/s390/include/asm/setup.h   |   2 +-
 arch/s390/include/asm/uaccess.h |  29 +-
 arch/s390/include/asm/vdso.h|   1 +
 arch/s390/include/uapi/asm/perf_regs.h  |  43 ++
 arch/s390/kernel/Makefile   |   5 +-
 arch/s390/kernel/asm-offsets.c  |   2 +-
 arch/s390/kernel/dis.c  |   4 +-
 arch/s390/kernel/entry.S|  33 +-
 arch/s390/kernel/head64.S   |   2 +-
 arch/s390/kernel/module.c   |  15 +-
 arch/s390/kernel/nmi.c  |   2 -
 arch/s390/kernel/perf_cpum_sf.c | 768 ++--
 arch/s390/kernel/perf_regs.c|  70 +++
 arch/s390/kernel/vdso.c |  44 +-
 arch/s390/kernel/vdso32/getcpu.S|  16 +-
 arch/s390/kernel/vdso64/clock_gettime.S |  19 +-
 arch/s390/kernel/vdso64/getcpu.S|  15 +-
 arch/s390/lib/spinlock.c|   7 +-
 arch/s390/lib/uaccess.c |  90 ++-
 arch/s390/mm/fault.c| 110 ++--
 arch/s390/mm/gmap.c |   9 +-
 arch/s390/mm/init.c |   1 +
 arch/s390/mm/pgalloc.c  |   4 +-
 arch/s390/tools/Makefile|   2 +-
 drivers/s390/char/con3215.c |   6 +-
 drivers/s390/char/con3270.c |  10 +-
 drivers/s390/char/sclp.c|  45 +-
 drivers/s390/char/sclp_con.c|   5 +-
 drivers/s390/char/sclp_tty.c|   5 +-
 drivers/s390/char/sclp_vt220.c  |   6 +-
 drivers/s390/char/tape_core.c

Re: [PATCH 1/5] dt-bindings: i2c: update documentation for the Meson-AXG

Hi Neil


On 11/17/17 21:02, Neil Armstrong wrote:
> On 17/11/2017 09:02, Yixun Lan wrote:
>> From: Jian Hu 
>>
>> Update the doc to explicitly add Meson-AXG to support list
>>
>> Signed-off-by: Jian Hu 
>> Signed-off-by: Yixun Lan 
>> ---
>>  Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt 
>> b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
>> index 611b934c7e10..3097d2b44dad 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
>> @@ -2,6 +2,7 @@ Amlogic Meson I2C controller
>>  
>>  Required properties:
>>   - compatible: must be "amlogic,meson6-i2c" or "amlogic,meson-gxbb-i2c"
>> +"amlogic,meson-axg-i2c"
> 
> Hi Yixun, Jian,
> 
> Maybe you should reformat by using :
> - compatible: must be :
>   "amlogic,meson6-i2c" for Meson8 and compatible SoCs
>   "amlogic,meson-gxbb-i2c" for GXBB and compatible SoCs
>   "amlogic,meson-axg-i2c"for AXG and compatible SoCs
> 
> Neil
> 
sure, we can do this.
thanks for the review
>>   - reg: physical address and length of the device registers
>>   - interrupts: a single interrupt specifier
>>   - clocks: clock for the device
>>
> 
> .
>

RE: [PATCH v3 1/2] acpi/x86: Fix improper handling of SCI INT for platforms supporting only IOAPIC mode

2017-11-17 Thread Sajjan, Vikas C

On Thu, 16 Nov 2017, Vikas C Sajjan wrote:

> The platforms which support only IOAPIC mode, pass the SCI information 
> above the legacy space (0-15) via the FADT mechanism and not via MADT.
> In such cases the mp_override_legacy_irq() used by 
> acpi_sci_ioapic_setup() to register SCI interrupts fails for 
> interrupts >= 16, since it is meant to handle only legacy space and 
> throws error "Invalid bus_irq %u for legacy override". Hence add a new 
> function to handle SCI interrupts >= 16 and invoke it conditionally in 
> acpi_sci_ioapic_setup().The code duplication due to this new function will be 
> cleaned up in a separate patch.

This reads way better, but I have a small nit pick. In the example I gave you 
there were multiple paragraphs on purpose to separate the different parts. So 
if I just split the above lump into separate paragraphs:

[1]
   The platforms which support only IOAPIC mode, pass the SCI information
   above the legacy space (0-15) via the FADT mechanism and not via MADT.

[2]
   In such cases the mp_override_legacy_irq() used by acpi_sci_ioapic_setup()
   to register SCI interrupts fails for interrupts >= 16, since it is meant to
   handle only legacy space and throws error "Invalid bus_irq %u for legacy
   override".

[3]
   Hence add a new function to handle SCI interrupts >= 16 and
   invoke it conditionally in acpi_sci_ioapic_setup().

[4]
   The code duplication due to this new function will be cleaned up in a
   separate patch.

then this is clearly structured:

[1] describes the context.

[2] describes the failure

[3] describes the solution

[4] is an extra note to tell the reviewer/reader that you are aware of the
code duplication and this is addressed later. 

No need to resend. I can do that when picking it up.
Thanks.

> Co-developed-by: Sunil V L 

I had a discussion with Greg about this tag which resulted in a patch so it 
should be soon part of the official documentation:

 https://lkml.kernel.org/r/20171116132309.ga8...@kroah.com

Great. Good to know that.

We agreed that both authors should add their Signed-off-by to document that the 
work conforms with the Developer Certificate of Origin. I'll add that if that's 
ok for you.

I am OK with that. Please go ahead.

Thanks for following up!

Thank you for the review.

   tglx

[PATCH v2] arm64: dts: ls1088a: add fsl-mc hardware resource manager node

2017-11-17 Thread Ioana Ciornei

Add the fsl-mc node in the LS1088A device tree.

Signed-off-by: Ioana Ciornei 
---
Changes in v2:
  - add a newline in between nodes
  - use hexadecimal unit-addresses

 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 71 ++
 1 file changed, 71 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index bd80e9a..e1a96b2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -166,6 +166,77 @@
 <1 10 IRQ_TYPE_LEVEL_LOW>;/* Hypervisor PPI */
};
 
+   fsl_mc: fsl-mc@80c00 {
+   compatible = "fsl,qoriq-mc";
+   reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
+ <0x 0x0834 0 0x4>; /* MC control reg */
+   msi-parent = <>;
+   #address-cells = <3>;
+   #size-cells = <1>;
+
+   /*
+* Region type 0x0 - MC portals
+* Region type 0x1 - QBMAN portals
+*/
+   ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
+ 0x1 0x0 0x0 0x8 0x1800 0x800>;
+
+   dpmacs {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dpmac1: dpmac@1 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <1>;
+   };
+
+   dpmac2: dpmac@2 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <2>;
+   };
+
+   dpmac3: dpmac@3 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <3>;
+   };
+
+   dpmac4: dpmac@4 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <4>;
+   };
+
+   dpmac5: dpmac@5 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <5>;
+   };
+
+   dpmac6: dpmac@6 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <6>;
+   };
+
+   dpmac7: dpmac@7 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <7>;
+   };
+
+   dpmac8: dpmac@8 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <8>;
+   };
+
+   dpmac9: dpmac@9 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <9>;
+   };
+
+   dpmac10: dpmac@a {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <0xa>;
+   };
+   };
+   };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
-- 
1.9.1

Re: [PATCH 1/2] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display

2017-11-17 Thread Lukasz Majewski

Hi Shawn,

> On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> > This is the support for aa070mc01-ca1 Mitsubishi display.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> >  arch/arm/boot/dts/Makefile |  1 +
> >  .../imx6q-display5-mitsubishi-aa070-800x480.dts| 51
> > ++ 2 files changed, 52 insertions(+)
> >  create mode 100644
> > arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index d9d0c82e7d20..10b3ad078dea 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6q-cm-fx6.dtb \
> > imx6q-cubox-i.dtb \
> > imx6q-dfi-fs700-m60.dtb \
> > +   imx6q-display5-mitsubishi-aa070-800x480.dtb \
> > imx6q-display5-tianma-tm070-1280x768.dtb \
> > imx6q-dmo-edmqmx6.dtb \
> > imx6q-evi.dtb \  
> 
> 
> 
> > +#include "imx6q-display5.dtsi"
> > +
> > + {
> > +   compatible = "mitsubishi,aa070mc01-ca1";
> > +};  
> 
> How many DTB files do you want to add for this display5 board?  

This is a single board, which can support panels which I've posted.

Those dtbs I do pack to u-boot' FIT image and don't need to worry that
some display is not working (after setting bootloader env variable).

> It's
> obvious no fun to maintain a bunch of DTB files for all the panels
> this board can support.

Please note that those files excessively use #include directive, and
there is not so much code added (the longest part is license and
comments).

>  Let's stop right here.

If I may ask - how shall I proceed? What would be your suggestion to
move on (dtb overlays) ?


> 
> Shawn
> 
> > +
> > + {
> > +   lvds0: lvds-channel@0 {
> > +   fsl,data-mapping = "spwg";
> > +   fsl,data-width = <24>;
> > +   };
> > +};
> > -- 
> > 2.11.0
> >   



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpImfyFMaqTA.pgp
Description: OpenPGP digital signature

[PATCH] ntb: remove unneeded DRIVER_LICENSE #defines

There is no need to #define the license of the driver, just put it in
the MODULE_LICENSE() line directly as a text string.

This allows tools that check that the module license matches the source
code license to work properly, as there is no need to unwind the
unneeded dereference, especially when the string is defined just a few
lines above the usage of it.

Cc: Jon Mason 
Cc: Dave Jiang 
Cc: Allen Hubbe 
Cc: Gary R Hook 
Cc: Serge Semin 
Reported-by: Philippe Ombredanne 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/ntb/ntb.c   | 3 +--
 drivers/ntb/test/ntb_perf.c | 3 +--
 drivers/ntb/test/ntb_pingpong.c | 3 +--
 drivers/ntb/test/ntb_tool.c | 3 +--
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/ntb/ntb.c b/drivers/ntb/ntb.c
index 03b80d89b980..bdcd59b13c1f 100644
--- a/drivers/ntb/ntb.c
+++ b/drivers/ntb/ntb.c
@@ -63,12 +63,11 @@
 #define DRIVER_NAME"ntb"
 #define DRIVER_DESCRIPTION "PCIe NTB Driver Framework"
 
-#define DRIVER_LICENSE "Dual BSD/GPL"
 #define DRIVER_VERSION "1.0"
 #define DRIVER_RELDATE "24 March 2015"
 #define DRIVER_AUTHOR  "Allen Hubbe "
 
-MODULE_LICENSE(DRIVER_LICENSE);
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index 759f772fa00c..d2b2e5958540 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -63,7 +63,6 @@
 #define DRIVER_NAME"ntb_perf"
 #define DRIVER_DESCRIPTION "PCIe NTB Performance Measurement Tool"
 
-#define DRIVER_LICENSE "Dual BSD/GPL"
 #define DRIVER_VERSION "1.0"
 #define DRIVER_AUTHOR  "Dave Jiang "
 
@@ -78,7 +77,7 @@
 #define MAX_SEG_ORDER  20 /* no larger than 1M for kmalloc buffer */
 #define PIDX   NTB_DEF_PEER_IDX
 
-MODULE_LICENSE(DRIVER_LICENSE);
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
diff --git a/drivers/ntb/test/ntb_pingpong.c b/drivers/ntb/test/ntb_pingpong.c
index 938a18bcfc3f..250cc286b768 100644
--- a/drivers/ntb/test/ntb_pingpong.c
+++ b/drivers/ntb/test/ntb_pingpong.c
@@ -68,12 +68,11 @@
 #define DRIVER_NAME"ntb_pingpong"
 #define DRIVER_DESCRIPTION "PCIe NTB Simple Pingpong Client"
 
-#define DRIVER_LICENSE "Dual BSD/GPL"
 #define DRIVER_VERSION "1.0"
 #define DRIVER_RELDATE "24 March 2015"
 #define DRIVER_AUTHOR  "Allen Hubbe "
 
-MODULE_LICENSE(DRIVER_LICENSE);
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
index a69815c45ce6..c45b8f798f7b 100644
--- a/drivers/ntb/test/ntb_tool.c
+++ b/drivers/ntb/test/ntb_tool.c
@@ -109,12 +109,11 @@
 #define DRIVER_NAME"ntb_tool"
 #define DRIVER_DESCRIPTION "PCIe NTB Debugging Tool"
 
-#define DRIVER_LICENSE "Dual BSD/GPL"
 #define DRIVER_VERSION "1.0"
 #define DRIVER_RELDATE "22 April 2015"
 #define DRIVER_AUTHOR  "Allen Hubbe "
 
-MODULE_LICENSE(DRIVER_LICENSE);
+MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
-- 
2.15.0

Re: [Openipmi-developer] [PATCH] ipmi: Stop timers before cleaning up the module

2017-11-17 Thread Corey Minyard


On 11/15/2017 01:33 AM, Masamitsu Yamazaki wrote:

System may crash after unloading ipmi_si.ko module
because a timer may remain and fire after the module cleaned up resources.


This is a big improvement, thanks.  I'll work on getting this into 4.15.

Thanks,

-corey


cleanup_one_si() contains the following processing.

 /*
  * Make sure that interrupts, the timer and the thread are
  * stopped and will not run again.
  */
 if (to_clean->irq_cleanup)
 to_clean->irq_cleanup(to_clean);
 wait_for_timer_and_thread(to_clean);

 /*
  * Timeouts are stopped, now make sure the interrupts are off
  * in the BMC.  Note that timers and CPU interrupts are off,
  * so no need for locks.
  */
 while (to_clean->curr_msg || (to_clean->si_state != SI_NORMAL)) {
 poll(to_clean);
 schedule_timeout_uninterruptible(1);
 }
 
si_state changes as following in the while loop calling poll(to_clean).


   SI_GETTING_MESSAGES
 => SI_CHECKING_ENABLES
  => SI_SETTING_ENABLES
   => SI_GETTING_EVENTS
=> SI_NORMAL

As written in the code comments above,
timers are expected to stop before the polling loop and not to run again.
But the timer is set again in the following process
when si_state becomes SI_SETTING_ENABLES.

   => poll
  => smi_event_handler
=> handle_transaction_done
   // smi_info->si_state == SI_SETTING_ENABLES
  => start_getting_events
=> start_new_msg
 => smi_mod_timer
   => mod_timer

As a result, before the timer set in start_new_msg() expires,
the polling loop may see si_state becoming SI_NORMAL
and the module clean-up finishes.

For example, hard LOCKUP and panic occurred as following.
smi_timeout was called after smi_event_handler,
kcs_event and hangs at port_inb()
trying to access I/O port after release.

#11 [88069fdc5ef0] end_repeat_nmi at 816ac8d3
 [exception RIP: port_inb+19]
 RIP: c0473053  RSP: 88069fdc3d80  RFLAGS: 0006
 RAX: 8806800f8e00  RBX: 880682bd9400  RCX: 
 RDX: 0ca3  RSI: 0ca3  RDI: 8806800f8e40
 RBP: 88069fdc3d80   R8: 81d86dfc   R9: 81e36426
 R10: 000509f0  R11: 0010  R12: 00]:00
 R13:   R14: 0246  R15: 8806800f8e00
 ORIG_RAX:   CS: 0010  SS: 
---  ---
#12 [88069fdc3d80] port_inb at c0473053 [ipmi_si]
#13 [88069fdc3d88] kcs_event at c0477952 [ipmi_si]
#14 [88069fdc3db0] smi_event_handler at c047465d [ipmi_si]
#15 [88069fdc3df0] smi_timeout at c0474f9e [ipmi_si]

To fix the problem I defined a flag, timer_can_start,
as member of struct smi_info.
The flag is enabled immediately after initializing the timer
and disabled immediately before waiting for timer deletion.

Fixes: 0cfec916e86d ("ipmi: Start the timer and thread on internal msgs")
Signed-off-by: Yamazaki Masamitsu 



diff -Nurp a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
--- a/drivers/char/ipmi/ipmi_si_intf.c  2017-11-09 15:00:31.436926440 +0900
+++ b/drivers/char/ipmi/ipmi_si_intf.c  2017-11-13 14:14:02.399051610 +0900
@@ -242,6 +242,9 @@ struct smi_info {
/* The timer for this si. */
struct timer_list   si_timer;
  
+	/* This flag is set, if the timer can be set */

+   booltimer_can_start;
+
/* This flag is set, if the timer is running (timer_pending() isn't 
enough) */
booltimer_running;
  
@@ -417,6 +420,8 @@ out:
  
  static void smi_mod_timer(struct smi_info *smi_info, unsigned long new_val)

  {
+   if (!smi_info->timer_can_start)
+   return;
smi_info->last_timeout_jiffies = jiffies;
mod_timer(_info->si_timer, new_val);
smi_info->timer_running = true;
@@ -436,21 +441,18 @@ static void start_new_msg(struct smi_inf
smi_info->handlers->start_transaction(smi_info->si_sm, msg, size);
  }
  
-static void start_check_enables(struct smi_info *smi_info, bool start_timer)

+static void start_check_enables(struct smi_info *smi_info)
  {
unsigned char msg[2];
  
  	msg[0] = (IPMI_NETFN_APP_REQUEST << 2);

msg[1] = IPMI_GET_BMC_GLOBAL_ENABLES_CMD;
  
-	if (start_timer)

-   start_new_msg(smi_info, msg, 2);
-   else
-   smi_info->handlers->start_transaction(smi_info->si_sm, msg, 2);
+   start_new_msg(smi_info, msg, 2);
smi_info->si_state = SI_CHECKING_ENABLES;
  }
  
-static void start_clear_flags(struct smi_info *smi_info, bool start_timer)

+static void start_clear_flags(struct smi_info *smi_info)
  {
unsigned char msg[3];
  
@@ -459,10 +461,7 @@ static void start_clear_flags(struct smi

msg[1] =

Re: [PATCH] ntb: remove unneeded DRIVER_LICENSE #defines

2017-11-17 Thread Philippe Ombredanne

On Fri, Nov 17, 2017 at 3:20 PM, Greg Kroah-Hartman
 wrote:
> There is no need to #define the license of the driver, just put it in
> the MODULE_LICENSE() line directly as a text string.
>
> This allows tools that check that the module license matches the source
> code license to work properly, as there is no need to unwind the
> unneeded dereference, especially when the string is defined just a few
> lines above the usage of it.
>
> Cc: Jon Mason 
> Cc: Dave Jiang 
> Cc: Allen Hubbe 
> Cc: Gary R Hook 
> Cc: Serge Semin 
> Reported-by: Philippe Ombredanne 
> Signed-off-by: Greg Kroah-Hartman 


Reviewed-by: Philippe Ombredanne 
-- 
Cordially
Philippe Ombredanne

Re: [PATCH] scsi: csiostor: remove unneeded DRIVER_LICENSE #define

2017-11-17 Thread Philippe Ombredanne

On Fri, Nov 17, 2017 at 3:21 PM, Greg Kroah-Hartman
 wrote:
> There is no need to #define the license of the driver, just put it in
> the MODULE_LICENSE() line directly as a text string.
>
> This allows tools that check that the module license matches the source
> code license to work properly, as there is no need to unwind the
> unneeded dereference, especially when the string is defined in a .h file
> far away from the .c file it is used in.
>
> Cc: "James E.J. Bottomley" 
> Cc: "Martin K. Petersen" 
> Cc: Varun Prakash 
> Reported-by: Philippe Ombredanne 
> Signed-off-by: Greg Kroah-Hartman 


Reviewed-by: Philippe Ombredanne 
-- 
Cordially
Philippe Ombredanne

[PATCH v2 0/2] Fix find_first_zero_bit() usage

2017-11-17 Thread Niklas Cassel

From: Niklas Cassel 

find_first_zero_bit()'s parameter 'size' is defined in bits,
not in bytes.

Calling find_first_zero_bit() with the wrong size unit
will lead to insidious bugs.

Fix all uses of find_first_zero_bit() called with
sizeof() as size argument in drivers/pci.

Niklas Cassel (2):
  PCI: designware-ep: Fix find_first_zero_bit() usage
  PCI: endpoint: Fix find_first_zero_bit() usage

 drivers/pci/dwc/pcie-designware-ep.c | 6 ++
 drivers/pci/endpoint/pci-ep-cfs.c| 3 +--
 2 files changed, 3 insertions(+), 6 deletions(-)

-- 
2.14.2

[PATCH 2/2] ASoC: da7218: Correct IRQ level in DT binding example

2017-11-17 Thread Adam Thomson

Current DT binding documentation shows an example where the IRQ
for the device is chosen to be ACTIVE_HIGH. This is incorrect as
the device only supports ACTIVE_LOW, so this commit fixes that
discrepancy.

Signed-off-by: Adam Thomson 
---
 Documentation/devicetree/bindings/sound/da7218.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/da7218.txt 
b/Documentation/devicetree/bindings/sound/da7218.txt
index 5ca5a70..3ab9dfe 100644
--- a/Documentation/devicetree/bindings/sound/da7218.txt
+++ b/Documentation/devicetree/bindings/sound/da7218.txt
@@ -73,7 +73,7 @@ Example:
compatible = "dlg,da7218";
reg = <0x1a>;
interrupt-parent = <>;
-   interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
wakeup-source;
 
VDD-supply = <_audio>;
-- 
1.9.1

Re: [PATCH v2] ecryptfs: sync before truncating lower inode

2017-11-17 Thread Tyler Hicks

On 11/15/2017 06:58 PM, Dmitry Torokhov wrote:
> On Wed, Apr 26, 2017 at 11:02 AM, Andrey Pronin  wrote:
>> If the updated ecryptfs header data is not written to disk before
>> the lower file is truncated, a crash may leave the filesystem
>> in the state when the lower file truncation is journaled, while
>> the changes to the ecryptfs header are lost (if the underlying
>> filesystem is ext4 in data=ordered mode, for example). As a result,
>> upon remounting and repairing the file may have a pre-truncation
>> length and garbage data after the post-truncation end.
>>
>> To reproduce, make a snapshot of the underlying ext4 filesystem
>> mounted with data=ordered while asynchronously truncating to zero a
>> group of files in ecryptfs mounted on top. Mount ecryptfs for the
>> snapshot and check the contents of the group of files that was
>> being truncated. The following script reproduces it in almost 100%
>> of runs:
>>
>> cd /tmp
>> mkdir -p ./loop
>> dd if=/dev/zero of=./file.img bs=1M count=10
>> PW=secret
>>
>> LOOPDEV=`losetup --find --show ./file.img`
>> mkfs -t ext4 $LOOPDEV
>> mount -t ext4 -o rw,nodev,relatime,seclabel,commit=600,data=ordered\
>>  $LOOPDEV ./loop
>> mkdir -p ./loop/vault ./loop/mount
>> mount -t ecryptfs -o rw,relatime,seclabel,ecryptfs_cipher=aes,\
>> ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_passthrough=no,\
>> ecryptfs_enable_filename_crypto=no,passphrase_passwd="$PW",no_sig_cache\
>>  ./loop/vault ./loop/mount
>> for i in `seq 1 100`; do echo $i > ./loop/mount/test.$i; done
>> sync
>> for i in `seq 100 -1 1`; do truncate -s 0 ./loop/mount/test.$i; done &
>> sleep 0.1; sync; cp ./file.img ./file.snap; sleep 1
>> umount ./loop/mount
>> umount ./loop
>> losetup -d $LOOPDEV
>>
>> LOOPDEV=`losetup --find --show ./file.snap`
>> mount -t ext4 -o rw,nodev,relatime,seclabel,commit=600,data=ordered\
>>  $LOOPDEV ./loop
>> mount -t ecryptfs -o rw,relatime,seclabel,ecryptfs_cipher=aes,\
>> ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_passthrough=no,\
>> ecryptfs_enable_filename_crypto=no,passphrase_passwd="$PW",no_sig_cache\
>>  ./loop/vault ./loop/mount
>> for i in `seq 1 100`; do
>>   if [ `stat -c %s ./loop/mount/test.$i` != 0 ] &&
>>  [ `cat ./loop/mount/test.$i` != $i ]; then
>>echo -n "!!! garbage at $i: ";  cat ./loop/mount/test.$i; echo
>>   fi
>> done
>> umount ./loop/mount
>> umount ./loop
>> losetup -d $LOOPDEV
>>
>> Signed-off-by: Andrey Pronin 
>> ---
>>
>> Changes since v1:
>>  - Switched to datasync=1 for ecryptfs_fsync_lower() in truncate_upper()\
> 
> It looks like this patch got lost... Can we get it in?

It did get lost. I'll have another look at it and get it into an
upcoming -rc release. Thanks for the reminder!

Tyler

> 
> Thanks!
> 
>>
>>  fs/ecryptfs/ecryptfs_kernel.h |  1 +
>>  fs/ecryptfs/inode.c   |  6 ++
>>  fs/ecryptfs/read_write.c  | 22 ++
>>  3 files changed, 29 insertions(+)
>>
>> diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
>> index f622a733f7ad..567698421270 100644
>> --- a/fs/ecryptfs/ecryptfs_kernel.h
>> +++ b/fs/ecryptfs/ecryptfs_kernel.h
>> @@ -689,6 +689,7 @@ int ecryptfs_read_lower_page_segment(struct page 
>> *page_for_ecryptfs,
>>  pgoff_t page_index,
>>  size_t offset_in_page, size_t size,
>>  struct inode *ecryptfs_inode);
>> +int ecryptfs_fsync_lower(struct inode *ecryptfs_inode, int datasync);
>>  struct page *ecryptfs_get_locked_page(struct inode *inode, loff_t index);
>>  int ecryptfs_parse_packet_length(unsigned char *data, size_t *size,
>>  size_t *length_size);
>> diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
>> index 5eab400e2590..a96988ba6928 100644
>> --- a/fs/ecryptfs/inode.c
>> +++ b/fs/ecryptfs/inode.c
>> @@ -827,6 +827,12 @@ static int truncate_upper(struct dentry *dentry, struct 
>> iattr *ia,
>>"rc = [%d]\n", rc);
>> goto out;
>> }
>> +   rc = ecryptfs_fsync_lower(inode, 1);
>> +   if (rc) {
>> +   printk(KERN_WARNING "Problem with 
>> ecryptfs_fsync_lower,"
>> +  "continue without syncing; "
>> +  "rc = [%d]\n", rc);
>> +   }
>> /* We are reducing the size of the ecryptfs file, and need to
>>  * know if we need to reduce the size of the lower file. */
>> lower_size_before_truncate =
>> diff --git a/fs/ecryptfs/read_write.c b/fs/ecryptfs/read_write.c
>> index 09fe622274e4..ba2dd6263875 100644
>> --- a/fs/ecryptfs/read_write.c
>> +++ b/fs/ecryptfs/read_write.c
>> @@ -271,3 +271,25 @@ int ecryptfs_read_lower_page_segment(struct page 
>> *page_for_ecryptfs,
>> flush_dcache_page(page_for_ecryptfs);
>> return

Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails

2017-11-17 Thread Javier Martinez Canillas

On 11/18/2017 12:55 AM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 07:14:21PM +, Roberts, William C wrote:
> 
>> I don't know why spaces would filter by command code. But it does
>> seem to be loaded By getting the command codes from the tpm in
>> tpm2_get_tpm_pt().
> 
> Ah, I forgot. So my remark is not quite right :\
> 

Right, so it seems I didn't completely misunderstand the code after all :)

>> I don't think that it’s the right fix. I don't think the in-kernel
>> RM should be filtering, but please enlighten my ignorance. Phillip
>> did the userspace RM and understand the RM issues way better than I.
> 
> It needs to prevent unauthorized stuff from being sent to the TPM, so
> if the kernel does not know how to parse the command it shouldn't send
> it. It is a matter of security..
>

What I fail to understand is why that's not a problem when the TPM spaces
infrastructure isn't used, tpm_validate_command() function just returns
true if space is NULL. So when sending command to /dev/tpm0 directly, a
rogue user-space program can send any arbitrary data to the TPM.

And also according to the TCG spec, the TPM should validate the command
header before it attempts to process the command.

> I can't remember if we synthezied responses for anything else, it
> could make sense to return the usual not supported command response
> for this specific thing. But the length error should remain EINVAL I
> think..
>
> Jason
> 

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean  wrote:
>
> I am still getting the crash at d9e12200852d, I figured I would
> double-check the "good" and "bad" kernels before starting a full bisect.

.. but without GCC_PLUGIN_RANDSTRUCT it's solid?

Kees removed even the baseline "randomize pure function pointer
structures", so at that commit, nothing should be randomized.

But maybe the plugin code itself ends up confusing gcc somehow?

Even when it doesn't actually do that "relayout_struct()" on the
structure, it always does those TYPE_ATTRIBUTES() games.

   Linus

[GIT PULL] rpmsg updates for v4.15

2017-11-17 Thread Bjorn Andersson

The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9:

  Linux 4.14-rc5 (2017-10-15 21:01:12 -0400)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/rpmsg-v4.15

for you to fetch changes up to 38a9acb3bb7b2561a08144ff80a292889f389a9b:

  rpmsg: glink: The mbox client knows_txdone (2017-11-15 22:58:01 -0800)


rpmsg updates for v4.15

This turn RPMSG_VIRTIO into a user selectable config, fixes a few bugs in GLINK
and provides the support for specifying initial buffer sizes for GLINK
channels.


Anup Patel (1):
  rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

Arun Kumar Neelakantam (1):
  rpmsg: glink: Initialize the "intent_req_comp" completion variable

Bjorn Andersson (2):
  rpmsg: glink: Add missing MODULE_LICENSE
  rpmsg: glink: The mbox client knows_txdone

Chris Lew (3):
  dt-bindings: soc: qcom: Support GLINK intents
  rpmsg: glink: Add support to preallocate intents
  rpmsg: glink: Use best fit intent during tx

 .../devicetree/bindings/soc/qcom/qcom,glink.txt| 10 +
 drivers/remoteproc/Kconfig |  4 --
 drivers/rpmsg/Kconfig  |  3 +-
 drivers/rpmsg/qcom_glink_native.c  | 51 +-
 4 files changed, 52 insertions(+), 16 deletions(-)

[GIT PULL] remoteproc updates for v4.15

2017-11-17 Thread Bjorn Andersson

The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9:

  Linux 4.14-rc5 (2017-10-15 21:01:12 -0400)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/rproc-v4.15

for you to fetch changes up to 1a5d5c592e902191bfa091ec9169aa43299a7d0f:

  remoteproc: qcom: Fix error handling paths in order to avoid memory leaks 
(2017-11-14 23:20:11 -0800)


remoteproc updates for v4.15

This adds an interface for configuring Qualcomm's "secure SMMU" and adds
support for booting the modem Hexagon on MSM8996.

Two new debugfs entries are added in the remoteproc core to introspect the list
of memory carveouts and the loaded resource table.


Avaneesh Kumar Dwivedi (4):
  firmware: scm: Add new SCM call API for switching memory ownership
  remoteproc: qcom: refactor mss fw image loading sequence
  remoteproc: qcom: Make secure world call for mem ownership switch
  remoteproc: qcom: Add support for mss remoteproc on msm8996

Bjorn Andersson (1):
  remoteproc: qcom: Drop pr_err in q6v5_xfer_mem_ownership()

Christophe JAILLET (1):
  remoteproc: qcom: Fix error handling paths in order to avoid memory leaks

Loic Pallardy (2):
  remoteproc: debug: add resource table dump feature
  remoteproc: debug: add carveouts list dump feature

 .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |   1 +
 drivers/firmware/qcom_scm-32.c |   7 +
 drivers/firmware/qcom_scm-64.c |  27 ++
 drivers/firmware/qcom_scm.c|  95 +++
 drivers/firmware/qcom_scm.h|   5 +
 drivers/remoteproc/qcom_q6v5_pil.c | 291 ++---
 drivers/remoteproc/remoteproc_debugfs.c| 130 +
 include/linux/qcom_scm.h   |  16 ++
 8 files changed, 533 insertions(+), 39 deletions(-)

Re: [GIT pull] printk updates for 4.15

2017-11-17 Thread Thomas Gleixner

On Fri, 17 Nov 2017, Linus Torvalds wrote:
> On Fri, Nov 17, 2017 at 4:26 PM, Thomas Gleixner  wrote:
> >
> > Here you go. It survived suspend resume in a VM.
> 
> That looks almost too small.
> 
> If this were to allow us to basically unify BOOTTIME/MONOTONIC, that
> would be lovely.

I surely missed something. John should figure that out faster than me.

> Should we just try it, with the understanding that we'll quite
> possibly have to just revert?

You've seen the warning in the changelog :)

> Assuming this works, what would the "phase two" patch that actually
> unifies the two (as opposed to make them have the same value) look
> like?
> 
> Is that just basically just removing the dozen or so "offst_boot"
> uses, or are there other possible simplifications?

Pretty much. We can't get rid of CLOCK_BOOTTIME and the handling of it,
though we can remove one hrtimer clock base by mapping boot time to
monotonic. That's about it.

Thanks,

tglx

[GIT PULL] hwspinlock update for v4.15

2017-11-17 Thread Bjorn Andersson

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/hwlock-v4.15

for you to fetch changes up to d048236dfdfe454f059a0837431c3ae3d166d4d6:

  hwspinlock: Change hwspinlock to a bool (2017-11-06 21:59:34 -0800)


hwspinlock update for v4.15

This changes the HWSPINLOCK core Kconfig option to bool, to aid when other core
code depends on it.


Baolin Wang (1):
  hwspinlock: Change hwspinlock to a bool

 drivers/hwspinlock/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] HID: rmi: Support the Fujitsu R726 Pad dock using hid-rmi

2017-11-17 Thread Andrew Duggan

The Fujitsu R726 Pad has an optional USB keyboard dock which contains
a Synaptics touchpad. The dock identifies itself as a
Primax Rezel Tablet Keyboard.

Signed-off-by: Andrew Duggan 
---
 drivers/hid/hid-core.c | 1 +
 drivers/hid/hid-ids.h  | 1 +
 drivers/hid/hid-rmi.c  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 330ca98..caacbab 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2253,6 +2253,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
 #if IS_ENABLED(CONFIG_HID_RMI)
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_COVER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_RAZER, USB_DEVICE_ID_RAZER_BLADE_14) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_REZEL) },
 #endif
 #if IS_ENABLED(CONFIG_HID_ROCCAT)
{ HID_USB_DEVICE(USB_VENDOR_ID_ROCCAT, USB_DEVICE_ID_ROCCAT_ARVO) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index be2e005..81c0915 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1146,6 +1146,7 @@
 #define USB_VENDOR_ID_PRIMAX   0x0461
 #define USB_DEVICE_ID_PRIMAX_MOUSE_4D220x4d22
 #define USB_DEVICE_ID_PRIMAX_KEYBOARD  0x4e05
+#define USB_DEVICE_ID_PRIMAX_REZEL 0x4e72
 
 
 #define USB_VENDOR_ID_RISO_KAGAKU  0x1294  /* Riso Kagaku Corp. */
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index ef241d6..a2731f8 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -724,6 +724,7 @@ static const struct hid_device_id rmi_id[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_RAZER, USB_DEVICE_ID_RAZER_BLADE_14),
.driver_data = RMI_DEVICE_HAS_PHYS_BUTTONS },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_COVER) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_REZEL) },
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID) },
{ }
 };
-- 
2.7.4

Re: [RFC PATCH 0/7] Fix Intel audio Kconfig issues