linux-next: Tree for Jul 10

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to your linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170707:

The unicore32 tree gained conflicts against the kbuild tree.

The vfs tree gained a build failure for which I applied a hack patch.
And another (from an interaction with the akpm-current tree) for which
I applied a fix patch.

The spi tree gained a build failure so I dropped it for today.

The rtc tree gained a conflict against Linus' tree.

The akpm-current tree gained a conflict against the vfs tree.

The akpm tree gained a conflict against the kbuild tree.

Non-merge commits (relative to Linus' tree): 2763
 2306 files changed, 410296 insertions(+), 48628 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (d3e3b7eac886 afs: Add metadata xattrs)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (11352460b8dc ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (b36c20244af3 Merge tag 'mlx5-fixes-2017-07-09' of 
https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (c644bd79c0a7 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (20e2b791796b ALSA: msnd: Optimize / harden DSP 
and MIDI loops)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (650fc870a2ef Merge tag 
'docs-4.13' of git://git.lwn.net/linux)
Merging tty.current/tty-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging usb.current/usb-linus (cee37d83e6d9 Merge branch 'work.read_write' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 

linux-next: Tree for Jul 10

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to your linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170707:

The unicore32 tree gained conflicts against the kbuild tree.

The vfs tree gained a build failure for which I applied a hack patch.
And another (from an interaction with the akpm-current tree) for which
I applied a fix patch.

The spi tree gained a build failure so I dropped it for today.

The rtc tree gained a conflict against Linus' tree.

The akpm-current tree gained a conflict against the vfs tree.

The akpm tree gained a conflict against the kbuild tree.

Non-merge commits (relative to Linus' tree): 2763
 2306 files changed, 410296 insertions(+), 48628 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (d3e3b7eac886 afs: Add metadata xattrs)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (11352460b8dc ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (b36c20244af3 Merge tag 'mlx5-fixes-2017-07-09' of 
https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (c644bd79c0a7 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (20e2b791796b ALSA: msnd: Optimize / harden DSP 
and MIDI loops)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (650fc870a2ef Merge tag 
'docs-4.13' of git://git.lwn.net/linux)
Merging tty.current/tty-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging usb.current/usb-linus (cee37d83e6d9 Merge branch 'work.read_write' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 

Re: [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper

[Ram Pai]

On Mon, Jul 10, 2017 at 08:41:30AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > get_pte_pkey() helper returns the pkey associated with
> > a address corresponding to a given mm_struct.
> > 
> > Signed-off-by: Ram Pai 
> > ---
> >  arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 
> >  arch/powerpc/mm/hash_utils_64.c   |   28 
> > +
> >  2 files changed, 33 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
> > b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> > index f7a6ed3..369f9ff 100644
> > --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> > +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> > @@ -450,6 +450,11 @@ extern int hash_page(unsigned long ea, unsigned long 
> > access, unsigned long trap,
> >  int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long 
> > vsid,
> >  pte_t *ptep, unsigned long trap, unsigned long flags,
> >  int ssize, unsigned int shift, unsigned int mmu_psize);
> > +
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address);
> > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> > +
> >  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >  extern int __hash_page_thp(unsigned long ea, unsigned long access,
> >unsigned long vsid, pmd_t *pmdp, unsigned long trap,
> > diff --git a/arch/powerpc/mm/hash_utils_64.c 
> > b/arch/powerpc/mm/hash_utils_64.c
> > index 1e74529..591990c 100644
> > --- a/arch/powerpc/mm/hash_utils_64.c
> > +++ b/arch/powerpc/mm/hash_utils_64.c
> > @@ -1573,6 +1573,34 @@ void hash_preload(struct mm_struct *mm, unsigned 
> > long ea,
> > local_irq_restore(flags);
> >  }
> >  
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +/*
> > + * return the protection key associated with the given address
> > + * and the mm_struct.
> > + */
> > +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address)
> > +{
> > +   pte_t *ptep;
> > +   u16 pkey = 0;
> > +   unsigned long flags;
> > +
> > +   if (REGION_ID(address) == VMALLOC_REGION_ID)
> > +   mm = _mm;
> 
> IIUC, protection keys are only applicable for user space. This
> function is getting used to populate siginfo structure. Then how
> can we ever request this for any address in VMALLOC region.

make sense. this check is not needed.

> 
> > +
> > +   if (!mm || !mm->pgd)
> > +   return 0;
> 
> Is this really required at this stage ?

its a sanity check to gaurd against bad inputs. See a problem?
RP

-- 
Ram Pai

Re: [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper

[Ram Pai]

On Mon, Jul 10, 2017 at 08:41:30AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > get_pte_pkey() helper returns the pkey associated with
> > a address corresponding to a given mm_struct.
> > 
> > Signed-off-by: Ram Pai 
> > ---
> >  arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 
> >  arch/powerpc/mm/hash_utils_64.c   |   28 
> > +
> >  2 files changed, 33 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
> > b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> > index f7a6ed3..369f9ff 100644
> > --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> > +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> > @@ -450,6 +450,11 @@ extern int hash_page(unsigned long ea, unsigned long 
> > access, unsigned long trap,
> >  int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long 
> > vsid,
> >  pte_t *ptep, unsigned long trap, unsigned long flags,
> >  int ssize, unsigned int shift, unsigned int mmu_psize);
> > +
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address);
> > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> > +
> >  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >  extern int __hash_page_thp(unsigned long ea, unsigned long access,
> >unsigned long vsid, pmd_t *pmdp, unsigned long trap,
> > diff --git a/arch/powerpc/mm/hash_utils_64.c 
> > b/arch/powerpc/mm/hash_utils_64.c
> > index 1e74529..591990c 100644
> > --- a/arch/powerpc/mm/hash_utils_64.c
> > +++ b/arch/powerpc/mm/hash_utils_64.c
> > @@ -1573,6 +1573,34 @@ void hash_preload(struct mm_struct *mm, unsigned 
> > long ea,
> > local_irq_restore(flags);
> >  }
> >  
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +/*
> > + * return the protection key associated with the given address
> > + * and the mm_struct.
> > + */
> > +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address)
> > +{
> > +   pte_t *ptep;
> > +   u16 pkey = 0;
> > +   unsigned long flags;
> > +
> > +   if (REGION_ID(address) == VMALLOC_REGION_ID)
> > +   mm = _mm;
> 
> IIUC, protection keys are only applicable for user space. This
> function is getting used to populate siginfo structure. Then how
> can we ever request this for any address in VMALLOC region.

make sense. this check is not needed.

> 
> > +
> > +   if (!mm || !mm->pgd)
> > +   return 0;
> 
> Is this really required at this stage ?

its a sanity check to gaurd against bad inputs. See a problem?
RP

-- 
Ram Pai

Re: [PATCH] NVMe: Added another device ID with stripe quirk

[Sagi Grimberg]

That's true for all Intel controllers going forward, but this
is actually an older controller that pre-dates NOIOB. It's the exact
same as the 8086:0A54 model, but a particular vendor decided their
rebranded device needs to be made special with a different DID.


Meh..



We all agree that's a terrible way to go about this for mutliple reasons,
but we can't go back in time to tell the decision makers of this folly. So
I think we need to let this last one go through with the quirk.

Acked-by: Keith Busch 


Reluctantly-accepted-by: Christoph Hellwig 



David, can you resend the patch? For some reason I
can't locate it in my mailbox...

Re: [PATCH] NVMe: Added another device ID with stripe quirk

[Sagi Grimberg]

That's true for all Intel controllers going forward, but this
is actually an older controller that pre-dates NOIOB. It's the exact
same as the 8086:0A54 model, but a particular vendor decided their
rebranded device needs to be made special with a different DID.


Meh..



We all agree that's a terrible way to go about this for mutliple reasons,
but we can't go back in time to tell the decision makers of this folly. So
I think we need to let this last one go through with the quirk.

Acked-by: Keith Busch 


Reluctantly-accepted-by: Christoph Hellwig 



David, can you resend the patch? For some reason I
can't locate it in my mailbox...

[PATCH v3 2/2] x86/efi: clean up dead code around efi_reserve_boot_services()

[Naoya Horiguchi]

EFI_BOOT_SERVICES_{CODE|DATA} regions never overlap the kernel now,
so we can clean up the check in efi_reserve_boot_services().

Signed-off-by: Naoya Horiguchi 
---
 arch/x86/platform/efi/quirks.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git next-20170705/arch/x86/platform/efi/quirks.c 
next-20170705_patched/arch/x86/platform/efi/quirks.c
index 8a99a2e..191f6f7 100644
--- next-20170705/arch/x86/platform/efi/quirks.c
+++ next-20170705_patched/arch/x86/platform/efi/quirks.c
@@ -292,27 +292,6 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 
size)
efi_memmap_install(new_phys, num_entries);
 }
 
-/*
- * Helper function for efi_reserve_boot_services() to figure out if we
- * can free regions in efi_free_boot_services().
- *
- * Use this function to ensure we do not free regions owned by somebody
- * else. We must only reserve (and then free) regions:
- *
- * - Not within any part of the kernel
- * - Not the BIOS reserved area (E820_TYPE_RESERVED, E820_TYPE_NVS, etc)
- */
-static bool can_free_region(u64 start, u64 size)
-{
-   if (start + size > __pa_symbol(_text) && start <= __pa_symbol(_end))
-   return false;
-
-   if (!e820__mapped_all(start, start+size, E820_TYPE_RAM))
-   return false;
-
-   return true;
-}
-
 void __init efi_reserve_boot_services(void)
 {
efi_memory_desc_t *md;
@@ -350,7 +329,7 @@ void __init efi_reserve_boot_services(void)
 * one else cares about it. We own it and can
 * free it later.
 */
-   if (can_free_region(start, size))
+   if (e820__mapped_all(start, start+size, E820_TYPE_RAM))
continue;
}
 
-- 
2.7.0

[PATCH v3 1/2] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

[Naoya Horiguchi]

KASLR chooses kernel location from E820_TYPE_RAM regions by walking over
e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and
EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to
UEFI spec, all memory regions marked as EfiBootServicesCode and
EfiBootServicesData are available for free memory after the first call
of ExitBootServices(). So such regions should be usable for kernel on
spec basis.

In x86, however, we have some workaround for broken firmware, where we
keep such regions reserved until SetVirtualAddressMap() is done.
See the following code in should_map_region():

static bool should_map_region(efi_memory_desc_t *md)
{
...
/*
 * Map boot services regions as a workaround for buggy
 * firmware that accesses them even when they shouldn't.
 *
 * See efi_{reserve,free}_boot_services().
 */
if (md->type == EFI_BOOT_SERVICES_CODE ||
md->type == EFI_BOOT_SERVICES_DATA)
return false;

This workaround suppressed a boot crash, but potential issues still
remain because no one prevents the regions from overlapping with kernel
image by KASLR.

So let's make sure that EFI_BOOT_SERVICES_{CODE|DATA} regions are never
chosen as kernel memory for the workaround to work fine.

Signed-off-by: Naoya Horiguchi 
---
v2 -> v3:
- skip EFI_LOADER_CODE and EFI_LOADER_DATA in region scan

v1 -> v2:
- switch efi_mirror_found to local variable
- insert break when EFI_MEMORY_MORE_RELIABLE found
---
 arch/x86/boot/compressed/kaslr.c | 44 +---
 1 file changed, 32 insertions(+), 12 deletions(-)

diff --git next-20170705/arch/x86/boot/compressed/kaslr.c 
next-20170705_patched/arch/x86/boot/compressed/kaslr.c
index 94f08fd..44778e9 100644
--- next-20170705/arch/x86/boot/compressed/kaslr.c
+++ next-20170705_patched/arch/x86/boot/compressed/kaslr.c
@@ -560,10 +560,8 @@ static void process_mem_region(struct mem_vector *entry,
}
 }
 
-/* Marks if efi mirror regions have been found and handled. */
-static bool efi_mirror_found;
-
-static void process_efi_entry(unsigned long minimum, unsigned long image_size)
+/* Returns true if we really enter efi memmap walk, otherwise returns false. */
+static bool process_efi_entry(unsigned long minimum, unsigned long image_size)
 {
struct efi_info *e = _params->efi_info;
struct mem_vector region;
@@ -572,18 +570,18 @@ static void process_efi_entry(unsigned long minimum, 
unsigned long image_size)
char *signature;
u32 nr_desc;
int i;
-
+   bool efi_mirror_found;
 
signature = (char *)_params->efi_info.efi_loader_signature;
if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
strncmp(signature, EFI64_LOADER_SIGNATURE, 4))
-   return;
+   return false;
 
 #ifdef CONFIG_X86_32
/* Can't handle data above 4GB at this time */
if (e->efi_memmap_hi) {
warn("Memory map is above 4GB, EFI should be disabled.\n");
-   return;
+   return false;
}
pmap =  e->efi_memmap;
 #else
@@ -594,12 +592,35 @@ static void process_efi_entry(unsigned long minimum, 
unsigned long image_size)
for (i = 0; i < nr_desc; i++) {
md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
-   region.start = md->phys_addr;
-   region.size = md->num_pages << EFI_PAGE_SHIFT;
-   process_mem_region(, minimum, image_size);
efi_mirror_found = true;
+   break;
}
}
+
+   for (i = 0; i < nr_desc; i++) {
+   md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
+
+   /*
+* According to spec, EFI_BOOT_SERVICES_{CODE|DATA} are also
+* available for kernel image, but we don't include them for
+* the workaround for buggy firmware.
+*/
+   if (md->type != EFI_CONVENTIONAL_MEMORY)
+   continue;
+
+   if (efi_mirror_found &&
+   !(md->attribute & EFI_MEMORY_MORE_RELIABLE))
+   continue;
+
+   region.start = md->phys_addr;
+   region.size = md->num_pages << EFI_PAGE_SHIFT;
+   process_mem_region(, minimum, image_size);
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted EFI scan (slot_areas full)!\n");
+   break;
+   }
+   }
+   return true;
 }
 
 static void process_e820_entry(unsigned long minimum, unsigned long image_size)
@@ -637,8 +658,7 @@ static unsigned long 

[PATCH v3 1/2] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

[Naoya Horiguchi]

KASLR chooses kernel location from E820_TYPE_RAM regions by walking over
e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and
EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to
UEFI spec, all memory regions marked as EfiBootServicesCode and
EfiBootServicesData are available for free memory after the first call
of ExitBootServices(). So such regions should be usable for kernel on
spec basis.

In x86, however, we have some workaround for broken firmware, where we
keep such regions reserved until SetVirtualAddressMap() is done.
See the following code in should_map_region():

static bool should_map_region(efi_memory_desc_t *md)
{
...
/*
 * Map boot services regions as a workaround for buggy
 * firmware that accesses them even when they shouldn't.
 *
 * See efi_{reserve,free}_boot_services().
 */
if (md->type == EFI_BOOT_SERVICES_CODE ||
md->type == EFI_BOOT_SERVICES_DATA)
return false;

This workaround suppressed a boot crash, but potential issues still
remain because no one prevents the regions from overlapping with kernel
image by KASLR.

So let's make sure that EFI_BOOT_SERVICES_{CODE|DATA} regions are never
chosen as kernel memory for the workaround to work fine.

Signed-off-by: Naoya Horiguchi 
---
v2 -> v3:
- skip EFI_LOADER_CODE and EFI_LOADER_DATA in region scan

v1 -> v2:
- switch efi_mirror_found to local variable
- insert break when EFI_MEMORY_MORE_RELIABLE found
---
 arch/x86/boot/compressed/kaslr.c | 44 +---
 1 file changed, 32 insertions(+), 12 deletions(-)

diff --git next-20170705/arch/x86/boot/compressed/kaslr.c 
next-20170705_patched/arch/x86/boot/compressed/kaslr.c
index 94f08fd..44778e9 100644
--- next-20170705/arch/x86/boot/compressed/kaslr.c
+++ next-20170705_patched/arch/x86/boot/compressed/kaslr.c
@@ -560,10 +560,8 @@ static void process_mem_region(struct mem_vector *entry,
}
 }
 
-/* Marks if efi mirror regions have been found and handled. */
-static bool efi_mirror_found;
-
-static void process_efi_entry(unsigned long minimum, unsigned long image_size)
+/* Returns true if we really enter efi memmap walk, otherwise returns false. */
+static bool process_efi_entry(unsigned long minimum, unsigned long image_size)
 {
struct efi_info *e = _params->efi_info;
struct mem_vector region;
@@ -572,18 +570,18 @@ static void process_efi_entry(unsigned long minimum, 
unsigned long image_size)
char *signature;
u32 nr_desc;
int i;
-
+   bool efi_mirror_found;
 
signature = (char *)_params->efi_info.efi_loader_signature;
if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
strncmp(signature, EFI64_LOADER_SIGNATURE, 4))
-   return;
+   return false;
 
 #ifdef CONFIG_X86_32
/* Can't handle data above 4GB at this time */
if (e->efi_memmap_hi) {
warn("Memory map is above 4GB, EFI should be disabled.\n");
-   return;
+   return false;
}
pmap =  e->efi_memmap;
 #else
@@ -594,12 +592,35 @@ static void process_efi_entry(unsigned long minimum, 
unsigned long image_size)
for (i = 0; i < nr_desc; i++) {
md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
-   region.start = md->phys_addr;
-   region.size = md->num_pages << EFI_PAGE_SHIFT;
-   process_mem_region(, minimum, image_size);
efi_mirror_found = true;
+   break;
}
}
+
+   for (i = 0; i < nr_desc; i++) {
+   md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
+
+   /*
+* According to spec, EFI_BOOT_SERVICES_{CODE|DATA} are also
+* available for kernel image, but we don't include them for
+* the workaround for buggy firmware.
+*/
+   if (md->type != EFI_CONVENTIONAL_MEMORY)
+   continue;
+
+   if (efi_mirror_found &&
+   !(md->attribute & EFI_MEMORY_MORE_RELIABLE))
+   continue;
+
+   region.start = md->phys_addr;
+   region.size = md->num_pages << EFI_PAGE_SHIFT;
+   process_mem_region(, minimum, image_size);
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted EFI scan (slot_areas full)!\n");
+   break;
+   }
+   }
+   return true;
 }
 
 static void process_e820_entry(unsigned long minimum, unsigned long image_size)
@@ -637,8 +658,7 @@ static unsigned long find_random_phys_addr(unsigned long 

[PATCH v3 2/2] x86/efi: clean up dead code around efi_reserve_boot_services()

[Naoya Horiguchi]

EFI_BOOT_SERVICES_{CODE|DATA} regions never overlap the kernel now,
so we can clean up the check in efi_reserve_boot_services().

Signed-off-by: Naoya Horiguchi 
---
 arch/x86/platform/efi/quirks.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git next-20170705/arch/x86/platform/efi/quirks.c 
next-20170705_patched/arch/x86/platform/efi/quirks.c
index 8a99a2e..191f6f7 100644
--- next-20170705/arch/x86/platform/efi/quirks.c
+++ next-20170705_patched/arch/x86/platform/efi/quirks.c
@@ -292,27 +292,6 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 
size)
efi_memmap_install(new_phys, num_entries);
 }
 
-/*
- * Helper function for efi_reserve_boot_services() to figure out if we
- * can free regions in efi_free_boot_services().
- *
- * Use this function to ensure we do not free regions owned by somebody
- * else. We must only reserve (and then free) regions:
- *
- * - Not within any part of the kernel
- * - Not the BIOS reserved area (E820_TYPE_RESERVED, E820_TYPE_NVS, etc)
- */
-static bool can_free_region(u64 start, u64 size)
-{
-   if (start + size > __pa_symbol(_text) && start <= __pa_symbol(_end))
-   return false;
-
-   if (!e820__mapped_all(start, start+size, E820_TYPE_RAM))
-   return false;
-
-   return true;
-}
-
 void __init efi_reserve_boot_services(void)
 {
efi_memory_desc_t *md;
@@ -350,7 +329,7 @@ void __init efi_reserve_boot_services(void)
 * one else cares about it. We own it and can
 * free it later.
 */
-   if (can_free_region(start, size))
+   if (e820__mapped_all(start, start+size, E820_TYPE_RAM))
continue;
}
 
-- 
2.7.0

Re: [RFC v5 32/38] powerpc: capture the violated protection key on fault

[Ram Pai]

On Mon, Jul 10, 2017 at 08:40:19AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > Capture the protection key that got violated in paca.
> > This value will be used by used to inform the signal
> > handler.
> > 
> > Signed-off-by: Ram Pai 
> > ---
> >  arch/powerpc/include/asm/paca.h   |1 +
> >  arch/powerpc/kernel/asm-offsets.c |1 +
> >  arch/powerpc/mm/fault.c   |3 +++
> >  3 files changed, 5 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/powerpc/include/asm/paca.h 
> > b/arch/powerpc/include/asm/paca.h
> > index c8bd1fc..0c06188 100644
> > --- a/arch/powerpc/include/asm/paca.h
> > +++ b/arch/powerpc/include/asm/paca.h
> > @@ -94,6 +94,7 @@ struct paca_struct {
> > u64 dscr_default;   /* per-CPU default DSCR */
> >  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > u64 paca_amr;   /* value of amr at exception */
> > +   u16 paca_pkey;  /* exception causing pkey */
> >  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> >  
> >  #ifdef CONFIG_PPC_STD_MMU_64
> > diff --git a/arch/powerpc/kernel/asm-offsets.c 
> > b/arch/powerpc/kernel/asm-offsets.c
> > index 17f5d8a..7dff862 100644
> > --- a/arch/powerpc/kernel/asm-offsets.c
> > +++ b/arch/powerpc/kernel/asm-offsets.c
> > @@ -244,6 +244,7 @@ int main(void)
> >  
> >  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > OFFSET(PACA_AMR, paca_struct, paca_amr);
> > +   OFFSET(PACA_PKEY, paca_struct, paca_pkey);
> >  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> >  
> > OFFSET(ACCOUNT_STARTTIME, paca_struct, accounting.starttime);
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index a6710f5..c8674a7 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -265,6 +265,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> > address,
> > if (error_code & DSISR_KEYFAULT) {
> > code = SEGV_PKUERR;
> > get_paca()->paca_amr = read_amr();
> > +   get_paca()->paca_pkey = get_pte_pkey(current->mm, address);
> > goto bad_area_nosemaphore;
> > }
> >  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> > @@ -290,6 +291,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> > address,
> >  
> > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
> >  
> > +
> 
> Stray empty line addition here.
> 
> > /*
> >  * We want to do this outside mmap_sem, because reading code around nip
> >  * can result in fault, which will cause a deadlock when called with
> > @@ -453,6 +455,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> > address,
> > if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
> > is_exec, 0)) {
> > get_paca()->paca_amr = read_amr();
> > +   get_paca()->paca_pkey = vma_pkey(vma);
> 
> Why not get_pte_pkey() here as well ? IIUC both these function would
> give us the same pkey, then why is the difference when we process a
> page fault for real protection key violation in HW compared to cross
> checking of VMA protection key in SW for regular page faults.

Unfortunately if we have reached here, it means the pgd-pmd-pdt-...pte
structures have not yet been totally populated for the task. Hence we
cannot walk the tree, to find the pte, to find the key. hence we have to 
depend on vma_pkey() to get the key from the vma.

RP




-- 
Ram Pai

Re: [RFC v5 32/38] powerpc: capture the violated protection key on fault

[Ram Pai]

On Mon, Jul 10, 2017 at 08:40:19AM +0530, Anshuman Khandual wrote:
> On 07/06/2017 02:52 AM, Ram Pai wrote:
> > Capture the protection key that got violated in paca.
> > This value will be used by used to inform the signal
> > handler.
> > 
> > Signed-off-by: Ram Pai 
> > ---
> >  arch/powerpc/include/asm/paca.h   |1 +
> >  arch/powerpc/kernel/asm-offsets.c |1 +
> >  arch/powerpc/mm/fault.c   |3 +++
> >  3 files changed, 5 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/powerpc/include/asm/paca.h 
> > b/arch/powerpc/include/asm/paca.h
> > index c8bd1fc..0c06188 100644
> > --- a/arch/powerpc/include/asm/paca.h
> > +++ b/arch/powerpc/include/asm/paca.h
> > @@ -94,6 +94,7 @@ struct paca_struct {
> > u64 dscr_default;   /* per-CPU default DSCR */
> >  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > u64 paca_amr;   /* value of amr at exception */
> > +   u16 paca_pkey;  /* exception causing pkey */
> >  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> >  
> >  #ifdef CONFIG_PPC_STD_MMU_64
> > diff --git a/arch/powerpc/kernel/asm-offsets.c 
> > b/arch/powerpc/kernel/asm-offsets.c
> > index 17f5d8a..7dff862 100644
> > --- a/arch/powerpc/kernel/asm-offsets.c
> > +++ b/arch/powerpc/kernel/asm-offsets.c
> > @@ -244,6 +244,7 @@ int main(void)
> >  
> >  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > OFFSET(PACA_AMR, paca_struct, paca_amr);
> > +   OFFSET(PACA_PKEY, paca_struct, paca_pkey);
> >  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> >  
> > OFFSET(ACCOUNT_STARTTIME, paca_struct, accounting.starttime);
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index a6710f5..c8674a7 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -265,6 +265,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> > address,
> > if (error_code & DSISR_KEYFAULT) {
> > code = SEGV_PKUERR;
> > get_paca()->paca_amr = read_amr();
> > +   get_paca()->paca_pkey = get_pte_pkey(current->mm, address);
> > goto bad_area_nosemaphore;
> > }
> >  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> > @@ -290,6 +291,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> > address,
> >  
> > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
> >  
> > +
> 
> Stray empty line addition here.
> 
> > /*
> >  * We want to do this outside mmap_sem, because reading code around nip
> >  * can result in fault, which will cause a deadlock when called with
> > @@ -453,6 +455,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> > address,
> > if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
> > is_exec, 0)) {
> > get_paca()->paca_amr = read_amr();
> > +   get_paca()->paca_pkey = vma_pkey(vma);
> 
> Why not get_pte_pkey() here as well ? IIUC both these function would
> give us the same pkey, then why is the difference when we process a
> page fault for real protection key violation in HW compared to cross
> checking of VMA protection key in SW for regular page faults.

Unfortunately if we have reached here, it means the pgd-pmd-pdt-...pte
structures have not yet been totally populated for the task. Hence we
cannot walk the tree, to find the pte, to find the key. hence we have to 
depend on vma_pkey() to get the key from the vma.

RP




-- 
Ram Pai

Re: [PATCH] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

[Naoya Horiguchi]

On Fri, Jul 07, 2017 at 11:58:14AM +0100, Matt Fleming wrote:
> On Fri, 07 Jul, at 06:11:24AM, Naoya Horiguchi wrote:
> > On Fri, Jul 07, 2017 at 11:07:59AM +0800, Baoquan He wrote:
> > > On 07/06/17 at 03:57pm, Matt Fleming wrote:
> > > > On Thu, 06 Jul, at 08:31:07AM, Naoya Horiguchi wrote:
> > > > > + for (i = 0; i < nr_desc; i++) {
> > > > > + md = (efi_memory_desc_t *)(pmap + (i * 
> > > > > e->efi_memdesc_size));
> > > > > +
> > > > > + /*
> > > > > +  * EFI_BOOT_SERVICES_{CODE|DATA} are avoided because 
> > > > > boot
> > > > > +  * services regions could be accessed after 
> > > > > ExitBootServices()
> > > > > +  * due to the workaround for buggy firmware.
> > > > > +  */
> > > > > + if (!(md->type == EFI_LOADER_CODE ||
> > > > > +   md->type == EFI_LOADER_DATA ||
> > > > > +   md->type == EFI_CONVENTIONAL_MEMORY))
> > > > > + continue;
> > > > 
> > > > Wouldn't it make more sense to *only* use EFI_CONVENTIONAL_MEMORY?
> > > > 
> > > > You can't re-use EFI_LOADER_* regions because the kaslr code is run so
> > > > early in boot that you've no idea if data the kernel will need is in
> > > > those EFI_LOADER_* regions.
> > > > 
> > > > For example, we pass struct setup_data objects inside of
> > > > EFI_LOADER_DATA regions.
> > > 
> > > It doesn't matter because we have tried to avoid those memory setup_data
> > > resides in in mem_avoid_overlap(). Here discarding EFI_LOADER_* could
> > > discard the whole regions while setup_data could occupy small part of
> > > them.
> > 
> > Hi Matt, Baoquan,
> > 
> > I added these three checks to accept any regions corresponding to
> > E820_TYPE_RAM except EFI_BOOT_SERVICES_*, just thinking of that it's minimum
> > surprising.  Baoquan gave a good justification on that, so I'll leave it
> > as-is in next version.
> 
> I disagree. The least surprising option would be to use the region
> type that everyone (boot loader, kernel, firmware) agrees is free:
> EFI_CONVENTIONAL_MEMORY.

OK, I will do it.

Re: [PATCH] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

[Naoya Horiguchi]

On Fri, Jul 07, 2017 at 11:58:14AM +0100, Matt Fleming wrote:
> On Fri, 07 Jul, at 06:11:24AM, Naoya Horiguchi wrote:
> > On Fri, Jul 07, 2017 at 11:07:59AM +0800, Baoquan He wrote:
> > > On 07/06/17 at 03:57pm, Matt Fleming wrote:
> > > > On Thu, 06 Jul, at 08:31:07AM, Naoya Horiguchi wrote:
> > > > > + for (i = 0; i < nr_desc; i++) {
> > > > > + md = (efi_memory_desc_t *)(pmap + (i * 
> > > > > e->efi_memdesc_size));
> > > > > +
> > > > > + /*
> > > > > +  * EFI_BOOT_SERVICES_{CODE|DATA} are avoided because 
> > > > > boot
> > > > > +  * services regions could be accessed after 
> > > > > ExitBootServices()
> > > > > +  * due to the workaround for buggy firmware.
> > > > > +  */
> > > > > + if (!(md->type == EFI_LOADER_CODE ||
> > > > > +   md->type == EFI_LOADER_DATA ||
> > > > > +   md->type == EFI_CONVENTIONAL_MEMORY))
> > > > > + continue;
> > > > 
> > > > Wouldn't it make more sense to *only* use EFI_CONVENTIONAL_MEMORY?
> > > > 
> > > > You can't re-use EFI_LOADER_* regions because the kaslr code is run so
> > > > early in boot that you've no idea if data the kernel will need is in
> > > > those EFI_LOADER_* regions.
> > > > 
> > > > For example, we pass struct setup_data objects inside of
> > > > EFI_LOADER_DATA regions.
> > > 
> > > It doesn't matter because we have tried to avoid those memory setup_data
> > > resides in in mem_avoid_overlap(). Here discarding EFI_LOADER_* could
> > > discard the whole regions while setup_data could occupy small part of
> > > them.
> > 
> > Hi Matt, Baoquan,
> > 
> > I added these three checks to accept any regions corresponding to
> > E820_TYPE_RAM except EFI_BOOT_SERVICES_*, just thinking of that it's minimum
> > surprising.  Baoquan gave a good justification on that, so I'll leave it
> > as-is in next version.
> 
> I disagree. The least surprising option would be to use the region
> type that everyone (boot loader, kernel, firmware) agrees is free:
> EFI_CONVENTIONAL_MEMORY.

OK, I will do it.

Re: [RFC v5 00/38] powerpc: Memory Protection Keys

[Anshuman Khandual]

On 07/06/2017 02:51 AM, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.
> 
> The overall idea:
> 
>  A process allocates a   key  and associates it with
>  an  address  range  withinits   address   space.
>  The process  then  can  dynamically  set read/write 
>  permissions on  the   key   without  involving  the 
>  kernel. Any  code that  violates   the  permissions
>  of  the address space; as defined by its associated
>  key, will receive a segmentation fault.
> 
> This patch series enables the feature on PPC64 HPTE
> platform.
> 
> ISA3.0 section 5.7.13 describes the detailed specifications.
> 
> 
> Testing:
>   This patch series has passed all the protection key
>   tests available in  the selftests directory.
>   The tests are updated to work on both x86 and powerpc.
> 
> version v5:
>   (1) reverted back to the old design -- store the 
>   key in the pte, instead of bypassing it.
>   The v4 design slowed down the hash page path.
>   (2) detects key violation when kernel is told to 
>   access user pages.
>   (3) further refined the patches into smaller consumable
>   units
>   (4) page faults handlers captures the faulting key 
>   from the pte instead of the vma. This closes a
>   race between where the key update in the vma and
>   a key fault caused cause by the key programmed
>   in the pte.
>   (5) a key created with access-denied should
>   also set it up to deny write. Fixed it.
>   (6) protection-key number is displayed in smaps
>   the x86 way.

Hello Ram,

This patch series has now grown a lot. Do you have this
hosted some where for us to pull and test it out ? BTW
do you have data points to show the difference in
performance between this version and the last one where
we skipped the bits from PTE and directly programmed the
HPTE entries looking into VMA bits.

- Anshuman

Re: [RFC v5 00/38] powerpc: Memory Protection Keys

[Anshuman Khandual]

On 07/06/2017 02:51 AM, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.
> 
> The overall idea:
> 
>  A process allocates a   key  and associates it with
>  an  address  range  withinits   address   space.
>  The process  then  can  dynamically  set read/write 
>  permissions on  the   key   without  involving  the 
>  kernel. Any  code that  violates   the  permissions
>  of  the address space; as defined by its associated
>  key, will receive a segmentation fault.
> 
> This patch series enables the feature on PPC64 HPTE
> platform.
> 
> ISA3.0 section 5.7.13 describes the detailed specifications.
> 
> 
> Testing:
>   This patch series has passed all the protection key
>   tests available in  the selftests directory.
>   The tests are updated to work on both x86 and powerpc.
> 
> version v5:
>   (1) reverted back to the old design -- store the 
>   key in the pte, instead of bypassing it.
>   The v4 design slowed down the hash page path.
>   (2) detects key violation when kernel is told to 
>   access user pages.
>   (3) further refined the patches into smaller consumable
>   units
>   (4) page faults handlers captures the faulting key 
>   from the pte instead of the vma. This closes a
>   race between where the key update in the vma and
>   a key fault caused cause by the key programmed
>   in the pte.
>   (5) a key created with access-denied should
>   also set it up to deny write. Fixed it.
>   (6) protection-key number is displayed in smaps
>   the x86 way.

Hello Ram,

This patch series has now grown a lot. Do you have this
hosted some where for us to pull and test it out ? BTW
do you have data points to show the difference in
performance between this version and the last one where
we skipped the bits from PTE and directly programmed the
HPTE entries looking into VMA bits.

- Anshuman

[PATCH] mfd: ab8500-core: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  162981009 184   174914453 drivers/mfd/ab8500-core.o

File size After adding 'const':
   textdata bss dec hex filename
  16490 817 184   174914453 drivers/mfd/ab8500-core.o

Signed-off-by: Arvind Yadav 
---
 drivers/mfd/ab8500-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 8511c06..30d09d1 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -1059,15 +1059,15 @@ static DEVICE_ATTR(dbbrstn, S_IRUGO | S_IWUSR,
NULL,
 };
 
-static struct attribute_group ab8500_attr_group = {
+static const struct attribute_group ab8500_attr_group = {
.attrs  = ab8500_sysfs_entries,
 };
 
-static struct attribute_group ab8505_attr_group = {
+static const struct attribute_group ab8505_attr_group = {
.attrs  = ab8505_sysfs_entries,
 };
 
-static struct attribute_group ab9540_attr_group = {
+static const struct attribute_group ab9540_attr_group = {
.attrs  = ab9540_sysfs_entries,
 };
 
-- 
1.9.1

[PATCH] mfd: ab8500-core: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  162981009 184   174914453 drivers/mfd/ab8500-core.o

File size After adding 'const':
   textdata bss dec hex filename
  16490 817 184   174914453 drivers/mfd/ab8500-core.o

Signed-off-by: Arvind Yadav 
---
 drivers/mfd/ab8500-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 8511c06..30d09d1 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -1059,15 +1059,15 @@ static DEVICE_ATTR(dbbrstn, S_IRUGO | S_IWUSR,
NULL,
 };
 
-static struct attribute_group ab8500_attr_group = {
+static const struct attribute_group ab8500_attr_group = {
.attrs  = ab8500_sysfs_entries,
 };
 
-static struct attribute_group ab8505_attr_group = {
+static const struct attribute_group ab8505_attr_group = {
.attrs  = ab8505_sysfs_entries,
 };
 
-static struct attribute_group ab9540_attr_group = {
+static const struct attribute_group ab9540_attr_group = {
.attrs  = ab9540_sysfs_entries,
 };
 
-- 
1.9.1

Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

[Peter Rosin]

On 2017-07-09 01:04, Kuppuswamy, Sathyanarayanan wrote:
> Hi Peter,
> 
> On 7/8/2017 1:55 PM, Peter Rosin wrote:
>> On 2017-07-07 23:41, sathyanarayanan.kuppusw...@linux.intel.com wrote:
>>> From: Kuppuswamy Sathyanarayanan 
>>> 
>>>
>>> Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER
>>> is not enabled.
>> Hi!
>>
>> Consumers should "select MULTIPLEXER",
>   If their driver can't work without mux_* calls then  you can make it 
> compulsory. But its not always true.
>>   so this does not make sense.
>> Or do you have a driver that has an optional mux consumer?
> I came across this case when I was working on Intel USB MUX driver. I 
> think you know the history behind it. Although I am not planning to 
> merge that driver now, but I think the use case is still valid.

Yeah, it's a valid use case. But why add a facility that noone uses? Sure,
if there's an actual consumer that needs it. But there isn't...

See, I have spent considerable time taking stuff like this out in order to
get the thing merged at all. I even think I wrote dummy inlines like this
at some point (but I'm not sure if I actually wrote them and I don't think
I submitted them. But I did think about it, that's for sure). Anyway, I'm
not very happy about ballooning the core with support for non-essentials
just yet. Maybe my mind-set will change over time?

(And no, I don't *know* the history behind the "Intel USB MUX driver",
 I e.g. never saw the consumer code. And I have the feeling that stuff
 were discussed in other threads that I was not part of and some (most?)
 questions I asked about it was left unanswered.)

Cheers,
peda

Re: [PATCH v1 1/1] mux: consumer: Add dummy functions for !CONFIG_MULTIPLEXER case

[Peter Rosin]

On 2017-07-09 01:04, Kuppuswamy, Sathyanarayanan wrote:
> Hi Peter,
> 
> On 7/8/2017 1:55 PM, Peter Rosin wrote:
>> On 2017-07-07 23:41, sathyanarayanan.kuppusw...@linux.intel.com wrote:
>>> From: Kuppuswamy Sathyanarayanan 
>>> 
>>>
>>> Add dummy functions to avoid compile time issues when CONFIG_MULTIPLEXER
>>> is not enabled.
>> Hi!
>>
>> Consumers should "select MULTIPLEXER",
>   If their driver can't work without mux_* calls then  you can make it 
> compulsory. But its not always true.
>>   so this does not make sense.
>> Or do you have a driver that has an optional mux consumer?
> I came across this case when I was working on Intel USB MUX driver. I 
> think you know the history behind it. Although I am not planning to 
> merge that driver now, but I think the use case is still valid.

Yeah, it's a valid use case. But why add a facility that noone uses? Sure,
if there's an actual consumer that needs it. But there isn't...

See, I have spent considerable time taking stuff like this out in order to
get the thing merged at all. I even think I wrote dummy inlines like this
at some point (but I'm not sure if I actually wrote them and I don't think
I submitted them. But I did think about it, that's for sure). Anyway, I'm
not very happy about ballooning the core with support for non-essentials
just yet. Maybe my mind-set will change over time?

(And no, I don't *know* the history behind the "Intel USB MUX driver",
 I e.g. never saw the consumer code. And I have the feeling that stuff
 were discussed in other threads that I was not part of and some (most?)
 questions I asked about it was left unanswered.)

Cheers,
peda

linux-next: manual merge of the akpm tree with the kbuild tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/xtensa/include/asm/Kbuild

between commit:

  35ff5ae79f85 ("xtensa: move generic-y of exported headers to uapi/asm/Kbuild")

from the kbuild tree and patch:

  "xtensa: use generic fb.h"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/xtensa/include/asm/Kbuild
index c04efde775a5,bdc12d426b24..
--- a/arch/xtensa/include/asm/Kbuild
+++ b/arch/xtensa/include/asm/Kbuild
@@@ -3,9 -4,13 +3,10 @@@ generic-y += clkdev.
  generic-y += div64.h
  generic-y += dma-contiguous.h
  generic-y += emergency-restart.h
 -generic-y += errno.h
  generic-y += exec.h
  generic-y += extable.h
+ generic-y += fb.h
 -generic-y += fcntl.h
  generic-y += hardirq.h
 -generic-y += ioctl.h
  generic-y += irq_regs.h
  generic-y += irq_work.h
  generic-y += kdebug.h

linux-next: manual merge of the akpm tree with the kbuild tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/xtensa/include/asm/Kbuild

between commit:

  35ff5ae79f85 ("xtensa: move generic-y of exported headers to uapi/asm/Kbuild")

from the kbuild tree and patch:

  "xtensa: use generic fb.h"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/xtensa/include/asm/Kbuild
index c04efde775a5,bdc12d426b24..
--- a/arch/xtensa/include/asm/Kbuild
+++ b/arch/xtensa/include/asm/Kbuild
@@@ -3,9 -4,13 +3,10 @@@ generic-y += clkdev.
  generic-y += div64.h
  generic-y += dma-contiguous.h
  generic-y += emergency-restart.h
 -generic-y += errno.h
  generic-y += exec.h
  generic-y += extable.h
+ generic-y += fb.h
 -generic-y += fcntl.h
  generic-y += hardirq.h
 -generic-y += ioctl.h
  generic-y += irq_regs.h
  generic-y += irq_work.h
  generic-y += kdebug.h

Re: [PATCH] vfio: Remove unnecessary uses of vfio_container.group_lock

[Alexey Kardashevskiy]

On 08/07/17 08:15, Alex Williamson wrote:
> The original intent of vfio_container.group_lock is to protect
> vfio_container.group_list, however over time it's become a crutch to
> prevent changes in container composition any time we call into the
> iommu driver backend.  This introduces problems when we start to have
> more complex interactions, for example when a user's DMA unmap request
> triggers a notification to an mdev vendor driver, who responds by
> attempting to unpin mappings within that request, re-entering the
> iommu backend.  We incorrectly assume that the use of read-locks here
> allow for this nested locking behavior, but a poorly timed write-lock
> could in fact trigger a deadlock.
> 
> The current use of group_lock seems to fall into the trap of locking
> code, not data.  Correct that by removing uses of group_lock that are
> not directly related to group_list.  Note that the vfio type1 iommu
> backend has its own mutex, vfio_iommu.lock, which it uses to protect
> itself for each of these interfaces anyway.  The group_lock appears to
> be a redundancy for these interfaces and type1 even goes so far as to
> release its mutex to allow for exactly the re-entrant code path above.
> 
> Reported-by: Chuanxiao Dong 
> Signed-off-by: Alex Williamson 
> ---
> 
> Alexey, does the SPAPR/TCE iommu backend have any dependencies on this
> lock?  If so, let's create a lock in the spapr_tce backend like we
> have in type1 to handle it.


There is one already - tce_container::lock.


> I believe the ioctl passthrough is the
> only interface that can reach spapr_tce. 


There are also vfio_iommu_driver_ops::attach_group/detach_group but these
are also using tce_container::lock so spapr is going to be fine.


Acked-by: Alexey Kardashevskiy 





> Thanks,
> 
> Alex
> 
>  drivers/vfio/vfio.c |   38 --
>  1 file changed, 38 deletions(-)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 7597a377eb4e..330d50582f40 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1175,15 +1175,11 @@ static long vfio_fops_unl_ioctl(struct file *filep,
>   ret = vfio_ioctl_set_iommu(container, arg);
>   break;
>   default:
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   data = container->iommu_data;
>  
>   if (driver) /* passthrough all unrecognized ioctls */
>   ret = driver->ops->ioctl(data, cmd, arg);
> -
> - up_read(>group_lock);
>   }
>  
>   return ret;
> @@ -1237,15 +1233,11 @@ static ssize_t vfio_fops_read(struct file *filep, 
> char __user *buf,
>   struct vfio_iommu_driver *driver;
>   ssize_t ret = -EINVAL;
>  
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->read))
>   ret = driver->ops->read(container->iommu_data,
>   buf, count, ppos);
>  
> - up_read(>group_lock);
> -
>   return ret;
>  }
>  
> @@ -1256,15 +1248,11 @@ static ssize_t vfio_fops_write(struct file *filep, 
> const char __user *buf,
>   struct vfio_iommu_driver *driver;
>   ssize_t ret = -EINVAL;
>  
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->write))
>   ret = driver->ops->write(container->iommu_data,
>buf, count, ppos);
>  
> - up_read(>group_lock);
> -
>   return ret;
>  }
>  
> @@ -1274,14 +1262,10 @@ static int vfio_fops_mmap(struct file *filep, struct 
> vm_area_struct *vma)
>   struct vfio_iommu_driver *driver;
>   int ret = -EINVAL;
>  
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->mmap))
>   ret = driver->ops->mmap(container->iommu_data, vma);
>  
> - up_read(>group_lock);
> -
>   return ret;
>  }
>  
> @@ -1993,8 +1977,6 @@ int vfio_pin_pages(struct device *dev, unsigned long 
> *user_pfn, int npage,
>   goto err_pin_pages;
>  
>   container = group->container;
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->pin_pages))
>   ret = driver->ops->pin_pages(container->iommu_data, user_pfn,
> @@ -2002,7 +1984,6 @@ int vfio_pin_pages(struct device *dev, unsigned long 
> *user_pfn, int npage,
>   else
>   ret = -ENOTTY;
>  
> - up_read(>group_lock);
>   vfio_group_try_dissolve_container(group);
>  
>  err_pin_pages:
> @@ -2042,8 +2023,6 @@ int vfio_unpin_pages(struct device *dev, unsigned long 
> *user_pfn, int npage)
>   goto err_unpin_pages;
>  
>   container = group->container;
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
> 

Re: [PATCH] vfio: Remove unnecessary uses of vfio_container.group_lock

[Alexey Kardashevskiy]

On 08/07/17 08:15, Alex Williamson wrote:
> The original intent of vfio_container.group_lock is to protect
> vfio_container.group_list, however over time it's become a crutch to
> prevent changes in container composition any time we call into the
> iommu driver backend.  This introduces problems when we start to have
> more complex interactions, for example when a user's DMA unmap request
> triggers a notification to an mdev vendor driver, who responds by
> attempting to unpin mappings within that request, re-entering the
> iommu backend.  We incorrectly assume that the use of read-locks here
> allow for this nested locking behavior, but a poorly timed write-lock
> could in fact trigger a deadlock.
> 
> The current use of group_lock seems to fall into the trap of locking
> code, not data.  Correct that by removing uses of group_lock that are
> not directly related to group_list.  Note that the vfio type1 iommu
> backend has its own mutex, vfio_iommu.lock, which it uses to protect
> itself for each of these interfaces anyway.  The group_lock appears to
> be a redundancy for these interfaces and type1 even goes so far as to
> release its mutex to allow for exactly the re-entrant code path above.
> 
> Reported-by: Chuanxiao Dong 
> Signed-off-by: Alex Williamson 
> ---
> 
> Alexey, does the SPAPR/TCE iommu backend have any dependencies on this
> lock?  If so, let's create a lock in the spapr_tce backend like we
> have in type1 to handle it.


There is one already - tce_container::lock.


> I believe the ioctl passthrough is the
> only interface that can reach spapr_tce. 


There are also vfio_iommu_driver_ops::attach_group/detach_group but these
are also using tce_container::lock so spapr is going to be fine.


Acked-by: Alexey Kardashevskiy 





> Thanks,
> 
> Alex
> 
>  drivers/vfio/vfio.c |   38 --
>  1 file changed, 38 deletions(-)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 7597a377eb4e..330d50582f40 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1175,15 +1175,11 @@ static long vfio_fops_unl_ioctl(struct file *filep,
>   ret = vfio_ioctl_set_iommu(container, arg);
>   break;
>   default:
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   data = container->iommu_data;
>  
>   if (driver) /* passthrough all unrecognized ioctls */
>   ret = driver->ops->ioctl(data, cmd, arg);
> -
> - up_read(>group_lock);
>   }
>  
>   return ret;
> @@ -1237,15 +1233,11 @@ static ssize_t vfio_fops_read(struct file *filep, 
> char __user *buf,
>   struct vfio_iommu_driver *driver;
>   ssize_t ret = -EINVAL;
>  
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->read))
>   ret = driver->ops->read(container->iommu_data,
>   buf, count, ppos);
>  
> - up_read(>group_lock);
> -
>   return ret;
>  }
>  
> @@ -1256,15 +1248,11 @@ static ssize_t vfio_fops_write(struct file *filep, 
> const char __user *buf,
>   struct vfio_iommu_driver *driver;
>   ssize_t ret = -EINVAL;
>  
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->write))
>   ret = driver->ops->write(container->iommu_data,
>buf, count, ppos);
>  
> - up_read(>group_lock);
> -
>   return ret;
>  }
>  
> @@ -1274,14 +1262,10 @@ static int vfio_fops_mmap(struct file *filep, struct 
> vm_area_struct *vma)
>   struct vfio_iommu_driver *driver;
>   int ret = -EINVAL;
>  
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->mmap))
>   ret = driver->ops->mmap(container->iommu_data, vma);
>  
> - up_read(>group_lock);
> -
>   return ret;
>  }
>  
> @@ -1993,8 +1977,6 @@ int vfio_pin_pages(struct device *dev, unsigned long 
> *user_pfn, int npage,
>   goto err_pin_pages;
>  
>   container = group->container;
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->pin_pages))
>   ret = driver->ops->pin_pages(container->iommu_data, user_pfn,
> @@ -2002,7 +1984,6 @@ int vfio_pin_pages(struct device *dev, unsigned long 
> *user_pfn, int npage,
>   else
>   ret = -ENOTTY;
>  
> - up_read(>group_lock);
>   vfio_group_try_dissolve_container(group);
>  
>  err_pin_pages:
> @@ -2042,8 +2023,6 @@ int vfio_unpin_pages(struct device *dev, unsigned long 
> *user_pfn, int npage)
>   goto err_unpin_pages;
>  
>   container = group->container;
> - down_read(>group_lock);
> -
>   driver = container->iommu_driver;
>   if (likely(driver && driver->ops->unpin_pages))
>   

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

[Thierry Reding]

On Sun, Jul 09, 2017 at 07:36:14PM +0300, Paul Kocialkowski wrote:
> This registers the host1x node with the SMMU (as HC swgroup) to allow
> the host1x code to attach to it. It avoid failing the probe sequence,
> which resulted in the tegra drm driver not probing and thus nothing
> being displayed on-screen.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm/boot/dts/tegra124.dtsi | 1 +
>  1 file changed, 1 insertion(+)

Thanks for tracking this down. However, I don't think this is an
appropriate fix for v4.12 because it requires an update to the DTB in
order to preserve functionality, which means we've broken DT ABI. The
proper fix I think needs to be to make usage of the IOMMU completely
optional in the host1x driver.

So I think what happens without this DT change is that the call to
iommu_attach_device() fails and we have no way to recover from that. I
think what we need to do is to free the domain in that case and make
sure we can continue without one. It's probably best to add an error
message, or maybe a warning to make sure people are aware.

Do you have the time to address this? If not, perhaps Mikko can take a
look?

Thierry


signature.asc
Description: PGP signature

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/uapi/linux/stddef.h:1:0,
 from include/linux/stddef.h:4,
 from include/uapi/linux/posix_types.h:4,
 from include/uapi/linux/types.h:13,
 from include/linux/types.h:5,
 from include/linux/syscalls.h:71,
 from fs/dcache.c:17:
fs/dcache.c: In function 'release_dentry_name_snapshot':
include/linux/compiler.h:542:38: error: call to '__compiletime_assert_305' 
declared with attribute error: pointer type mismatch in container_of()
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/compiler.h:525:4: note: in definition of macro 
'__compiletime_assert'
prefix ## suffix();\
^
include/linux/compiler.h:542: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:860:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
  ^
fs/dcache.c:305:7: note: in expansion of macro 'container_of'
   p = container_of(name->name, struct external_name, name[0]);
   ^

Caused by commit

  2f23633e9c84 ("kernel.h: handle pointers to arrays better in container_of()")

interacting with commit

  49d31c2f389a ("dentry name snapshots")

from the vfs tree.

I applied the following fix patch.  I hope it is ok.  If so, please
apply to the vfs tree.

-- 
Cheers,
Stephen Rothwell

From: Stephen Rothwell 
Date: Mon, 10 Jul 2017 15:09:12 +1000
Subject: [PATCH] fix type for "dentry name snapshots"

Signed-off-by: Stephen Rothwell 
---
 include/linux/dcache.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index fcaba2d8638a..aae1cdb76851 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -597,8 +597,8 @@ static inline struct inode *d_real_inode(const struct 
dentry *dentry)
 }
 
 struct name_snapshot {
-   const char *name;
-   char inline_name[DNAME_INLINE_LEN];
+   const unsigned char *name;
+   unsigned char inline_name[DNAME_INLINE_LEN];
 };
 void take_dentry_name_snapshot(struct name_snapshot *, struct dentry *);
 void release_dentry_name_snapshot(struct name_snapshot *);
-- 
2.13.2

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

[Thierry Reding]

On Sun, Jul 09, 2017 at 07:36:14PM +0300, Paul Kocialkowski wrote:
> This registers the host1x node with the SMMU (as HC swgroup) to allow
> the host1x code to attach to it. It avoid failing the probe sequence,
> which resulted in the tegra drm driver not probing and thus nothing
> being displayed on-screen.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm/boot/dts/tegra124.dtsi | 1 +
>  1 file changed, 1 insertion(+)

Thanks for tracking this down. However, I don't think this is an
appropriate fix for v4.12 because it requires an update to the DTB in
order to preserve functionality, which means we've broken DT ABI. The
proper fix I think needs to be to make usage of the IOMMU completely
optional in the host1x driver.

So I think what happens without this DT change is that the call to
iommu_attach_device() fails and we have no way to recover from that. I
think what we need to do is to free the domain in that case and make
sure we can continue without one. It's probably best to add an error
message, or maybe a warning to make sure people are aware.

Do you have the time to address this? If not, perhaps Mikko can take a
look?

Thierry


signature.asc
Description: PGP signature

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/uapi/linux/stddef.h:1:0,
 from include/linux/stddef.h:4,
 from include/uapi/linux/posix_types.h:4,
 from include/uapi/linux/types.h:13,
 from include/linux/types.h:5,
 from include/linux/syscalls.h:71,
 from fs/dcache.c:17:
fs/dcache.c: In function 'release_dentry_name_snapshot':
include/linux/compiler.h:542:38: error: call to '__compiletime_assert_305' 
declared with attribute error: pointer type mismatch in container_of()
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/compiler.h:525:4: note: in definition of macro 
'__compiletime_assert'
prefix ## suffix();\
^
include/linux/compiler.h:542: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:860:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
  ^
fs/dcache.c:305:7: note: in expansion of macro 'container_of'
   p = container_of(name->name, struct external_name, name[0]);
   ^

Caused by commit

  2f23633e9c84 ("kernel.h: handle pointers to arrays better in container_of()")

interacting with commit

  49d31c2f389a ("dentry name snapshots")

from the vfs tree.

I applied the following fix patch.  I hope it is ok.  If so, please
apply to the vfs tree.

-- 
Cheers,
Stephen Rothwell

From: Stephen Rothwell 
Date: Mon, 10 Jul 2017 15:09:12 +1000
Subject: [PATCH] fix type for "dentry name snapshots"

Signed-off-by: Stephen Rothwell 
---
 include/linux/dcache.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index fcaba2d8638a..aae1cdb76851 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -597,8 +597,8 @@ static inline struct inode *d_real_inode(const struct 
dentry *dentry)
 }
 
 struct name_snapshot {
-   const char *name;
-   char inline_name[DNAME_INLINE_LEN];
+   const unsigned char *name;
+   unsigned char inline_name[DNAME_INLINE_LEN];
 };
 void take_dentry_name_snapshot(struct name_snapshot *, struct dentry *);
 void release_dentry_name_snapshot(struct name_snapshot *);
-- 
2.13.2

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Michael Ellerman]

Peter Zijlstra  writes:

> PPC folks, maddy, does this work for you guys?

It think it works for us, but I have some comments, I'll reply to the original.

cheers

> On Thu, Apr 20, 2017 at 08:07:49PM +0800, Jin Yao wrote:
>> It is often useful to know the branch types while analyzing branch
>> data. For example, a call is very different from a conditional branch.
>> 
>> Currently we have to look it up in binary while the binary may later
>> not be available and even the binary is available but user has to take
>> some time. It is very useful for user to check it directly in perf
>> report.
>> 
>> Perf already has support for disassembling the branch instruction
>> to get the x86 branch type.
>> 
>> To keep consistent on kernel and userspace and make the classification
>> more common, the patch adds the common branch type classification
>> in perf_event.h.
>> 
>> PERF_BR_NONE  : unknown
>> PERF_BR_JCC   : conditional jump
>> PERF_BR_JMP   : jump
>> PERF_BR_IND_JMP   : indirect jump
>> PERF_BR_CALL  : call
>> PERF_BR_IND_CALL  : indirect call
>> PERF_BR_RET   : return
>> PERF_BR_SYSCALL   : syscall
>> PERF_BR_SYSRET: syscall return
>> PERF_BR_IRQ   : hw interrupt/trap/fault
>> PERF_BR_INT   : sw interrupt
>> PERF_BR_IRET  : return from interrupt
>> PERF_BR_FAR_BRANCH: not generic far branch type
>> 
>> The patch also adds a new field type (4 bits) in perf_branch_entry
>> to record the branch type.
>> 
>> Since the disassembling of branch instruction needs some overhead,
>> a new PERF_SAMPLE_BRANCH_TYPE_SAVE is introduced to indicate if it
>> needs to disassemble the branch instruction and record the branch
>> type.
>> 
>> Change log
>> --
>> 
>> v6: Not changed.
>> 
>> v5: Not changed. The v5 patch series just change the userspace.
>> 
>> v4: Comparing to previous version, the major changes are:
>> 
>> 1. Remove the PERF_BR_JCC_FWD/PERF_BR_JCC_BWD, they will be
>>computed later in userspace.
>> 
>> 2. Remove the "cross" field in perf_branch_entry. The cross page
>>computing will be done later in userspace.
>> 
>> Signed-off-by: Jin Yao 
>> ---
>>  include/uapi/linux/perf_event.h   | 29 -
>>  tools/include/uapi/linux/perf_event.h | 29 -
>>  2 files changed, 56 insertions(+), 2 deletions(-)
>> 
>> diff --git a/include/uapi/linux/perf_event.h 
>> b/include/uapi/linux/perf_event.h
>> index d09a9cd..69af012 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -174,6 +174,8 @@ enum perf_branch_sample_type_shift {
>>  PERF_SAMPLE_BRANCH_NO_FLAGS_SHIFT   = 14, /* no flags */
>>  PERF_SAMPLE_BRANCH_NO_CYCLES_SHIFT  = 15, /* no cycles */
>>  
>> +PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT  = 16, /* save branch type */
>> +
>>  PERF_SAMPLE_BRANCH_MAX_SHIFT/* non-ABI */
>>  };
>>  
>> @@ -198,9 +200,32 @@ enum perf_branch_sample_type {
>>  PERF_SAMPLE_BRANCH_NO_FLAGS = 1U << 
>> PERF_SAMPLE_BRANCH_NO_FLAGS_SHIFT,
>>  PERF_SAMPLE_BRANCH_NO_CYCLES= 1U << 
>> PERF_SAMPLE_BRANCH_NO_CYCLES_SHIFT,
>>  
>> +PERF_SAMPLE_BRANCH_TYPE_SAVE=
>> +1U << PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT,
>> +
>>  PERF_SAMPLE_BRANCH_MAX  = 1U << PERF_SAMPLE_BRANCH_MAX_SHIFT,
>>  };
>>  
>> +/*
>> + * Common flow change classification
>> + */
>> +enum {
>> +PERF_BR_NONE= 0,/* unknown */
>> +PERF_BR_JCC = 1,/* conditional jump */
>> +PERF_BR_JMP = 2,/* jump */
>> +PERF_BR_IND_JMP = 3,/* indirect jump */
>> +PERF_BR_CALL= 4,/* call */
>> +PERF_BR_IND_CALL= 5,/* indirect call */
>> +PERF_BR_RET = 6,/* return */
>> +PERF_BR_SYSCALL = 7,/* syscall */
>> +PERF_BR_SYSRET  = 8,/* syscall return */
>> +PERF_BR_IRQ = 9,/* hw interrupt/trap/fault */
>> +PERF_BR_INT = 10,   /* sw interrupt */
>> +PERF_BR_IRET= 11,   /* return from interrupt */
>> +PERF_BR_FAR_BRANCH  = 12,   /* not generic far branch type */
>> +PERF_BR_MAX,
>> +};
>> +
>>  #define PERF_SAMPLE_BRANCH_PLM_ALL \
>>  (PERF_SAMPLE_BRANCH_USER|\
>>   PERF_SAMPLE_BRANCH_KERNEL|\
>> @@ -999,6 +1024,7 @@ union perf_mem_data_src {
>>   * in_tx: running in a hardware transaction
>>   * abort: aborting a hardware transaction
>>   *cycles: cycles from last branch (or 0 if not supported)
>> + *  type: branch type
>>   */
>>  struct perf_branch_entry {
>>  __u64   from;
>> @@ -1008,7 +1034,8 @@ struct perf_branch_entry {
>>  in_tx:1,/* in transaction */
>>  abort:1,/* transaction abort */
>>  cycles:16,  /* cycle count to last branch */
>> -reserved:44;
>> +type:4, /* branch type */
>> +reserved:40;

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Michael Ellerman]

Peter Zijlstra  writes:

> PPC folks, maddy, does this work for you guys?

It think it works for us, but I have some comments, I'll reply to the original.

cheers

> On Thu, Apr 20, 2017 at 08:07:49PM +0800, Jin Yao wrote:
>> It is often useful to know the branch types while analyzing branch
>> data. For example, a call is very different from a conditional branch.
>> 
>> Currently we have to look it up in binary while the binary may later
>> not be available and even the binary is available but user has to take
>> some time. It is very useful for user to check it directly in perf
>> report.
>> 
>> Perf already has support for disassembling the branch instruction
>> to get the x86 branch type.
>> 
>> To keep consistent on kernel and userspace and make the classification
>> more common, the patch adds the common branch type classification
>> in perf_event.h.
>> 
>> PERF_BR_NONE  : unknown
>> PERF_BR_JCC   : conditional jump
>> PERF_BR_JMP   : jump
>> PERF_BR_IND_JMP   : indirect jump
>> PERF_BR_CALL  : call
>> PERF_BR_IND_CALL  : indirect call
>> PERF_BR_RET   : return
>> PERF_BR_SYSCALL   : syscall
>> PERF_BR_SYSRET: syscall return
>> PERF_BR_IRQ   : hw interrupt/trap/fault
>> PERF_BR_INT   : sw interrupt
>> PERF_BR_IRET  : return from interrupt
>> PERF_BR_FAR_BRANCH: not generic far branch type
>> 
>> The patch also adds a new field type (4 bits) in perf_branch_entry
>> to record the branch type.
>> 
>> Since the disassembling of branch instruction needs some overhead,
>> a new PERF_SAMPLE_BRANCH_TYPE_SAVE is introduced to indicate if it
>> needs to disassemble the branch instruction and record the branch
>> type.
>> 
>> Change log
>> --
>> 
>> v6: Not changed.
>> 
>> v5: Not changed. The v5 patch series just change the userspace.
>> 
>> v4: Comparing to previous version, the major changes are:
>> 
>> 1. Remove the PERF_BR_JCC_FWD/PERF_BR_JCC_BWD, they will be
>>computed later in userspace.
>> 
>> 2. Remove the "cross" field in perf_branch_entry. The cross page
>>computing will be done later in userspace.
>> 
>> Signed-off-by: Jin Yao 
>> ---
>>  include/uapi/linux/perf_event.h   | 29 -
>>  tools/include/uapi/linux/perf_event.h | 29 -
>>  2 files changed, 56 insertions(+), 2 deletions(-)
>> 
>> diff --git a/include/uapi/linux/perf_event.h 
>> b/include/uapi/linux/perf_event.h
>> index d09a9cd..69af012 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -174,6 +174,8 @@ enum perf_branch_sample_type_shift {
>>  PERF_SAMPLE_BRANCH_NO_FLAGS_SHIFT   = 14, /* no flags */
>>  PERF_SAMPLE_BRANCH_NO_CYCLES_SHIFT  = 15, /* no cycles */
>>  
>> +PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT  = 16, /* save branch type */
>> +
>>  PERF_SAMPLE_BRANCH_MAX_SHIFT/* non-ABI */
>>  };
>>  
>> @@ -198,9 +200,32 @@ enum perf_branch_sample_type {
>>  PERF_SAMPLE_BRANCH_NO_FLAGS = 1U << 
>> PERF_SAMPLE_BRANCH_NO_FLAGS_SHIFT,
>>  PERF_SAMPLE_BRANCH_NO_CYCLES= 1U << 
>> PERF_SAMPLE_BRANCH_NO_CYCLES_SHIFT,
>>  
>> +PERF_SAMPLE_BRANCH_TYPE_SAVE=
>> +1U << PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT,
>> +
>>  PERF_SAMPLE_BRANCH_MAX  = 1U << PERF_SAMPLE_BRANCH_MAX_SHIFT,
>>  };
>>  
>> +/*
>> + * Common flow change classification
>> + */
>> +enum {
>> +PERF_BR_NONE= 0,/* unknown */
>> +PERF_BR_JCC = 1,/* conditional jump */
>> +PERF_BR_JMP = 2,/* jump */
>> +PERF_BR_IND_JMP = 3,/* indirect jump */
>> +PERF_BR_CALL= 4,/* call */
>> +PERF_BR_IND_CALL= 5,/* indirect call */
>> +PERF_BR_RET = 6,/* return */
>> +PERF_BR_SYSCALL = 7,/* syscall */
>> +PERF_BR_SYSRET  = 8,/* syscall return */
>> +PERF_BR_IRQ = 9,/* hw interrupt/trap/fault */
>> +PERF_BR_INT = 10,   /* sw interrupt */
>> +PERF_BR_IRET= 11,   /* return from interrupt */
>> +PERF_BR_FAR_BRANCH  = 12,   /* not generic far branch type */
>> +PERF_BR_MAX,
>> +};
>> +
>>  #define PERF_SAMPLE_BRANCH_PLM_ALL \
>>  (PERF_SAMPLE_BRANCH_USER|\
>>   PERF_SAMPLE_BRANCH_KERNEL|\
>> @@ -999,6 +1024,7 @@ union perf_mem_data_src {
>>   * in_tx: running in a hardware transaction
>>   * abort: aborting a hardware transaction
>>   *cycles: cycles from last branch (or 0 if not supported)
>> + *  type: branch type
>>   */
>>  struct perf_branch_entry {
>>  __u64   from;
>> @@ -1008,7 +1034,8 @@ struct perf_branch_entry {
>>  in_tx:1,/* in transaction */
>>  abort:1,/* transaction abort */
>>  cycles:16,  /* cycle count to last branch */
>> -reserved:44;
>> +type:4, /* branch type */
>> +reserved:40;
>>  };
>>  
>>  #endif /* 

Re: [PATCH] hwtracing: coresight: constify attribute_group structures.

[Arvind Yadav]

Hi Mathieu,


On Friday 07 July 2017 08:58 PM, Mathieu Poirier wrote:

On 4 July 2017 at 23:49, Arvind Yadav  wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   text data bss dec hex filename
2573 288 2963157 c55 coresight-etm-perf.o

File size After adding 'const':
textdata bss dec hex filename
2613 224 2963133 c3d coresight-etm-perf.o

Hi Arvind,

Did you find this using an automated tool or simply stumbled on it
while reviewing the code?  In case of the former it is usually a good
idea to specify which tool was used in the change log.

  Automated tools are not able to caught this kind of error.
  I have fixed same changes in zram ( commit - dfc8ed8d6a).
  Minchan Kim suggested me to change all the places where have not
  used const. It's good idea have a tool which can able to detect these
  kind of error. I will try to create a tool.


Thanks,
Mathieu


Signed-off-by: Arvind Yadav 
---
  drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 288a423..e97775d 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -60,7 +60,7 @@ struct etm_event_data {
 NULL,
  };

-static struct attribute_group etm_pmu_format_group = {
+static const struct attribute_group etm_pmu_format_group = {
 .name   = "format",
 .attrs  = etm_config_formats_attr,
  };
--
1.9.1


Thanks,
~arvind

Re: [PATCH] hwtracing: coresight: constify attribute_group structures.

[Arvind Yadav]

Hi Mathieu,


On Friday 07 July 2017 08:58 PM, Mathieu Poirier wrote:

On 4 July 2017 at 23:49, Arvind Yadav  wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
   text data bss dec hex filename
2573 288 2963157 c55 coresight-etm-perf.o

File size After adding 'const':
textdata bss dec hex filename
2613 224 2963133 c3d coresight-etm-perf.o

Hi Arvind,

Did you find this using an automated tool or simply stumbled on it
while reviewing the code?  In case of the former it is usually a good
idea to specify which tool was used in the change log.

  Automated tools are not able to caught this kind of error.
  I have fixed same changes in zram ( commit - dfc8ed8d6a).
  Minchan Kim suggested me to change all the places where have not
  used const. It's good idea have a tool which can able to detect these
  kind of error. I will try to create a tool.


Thanks,
Mathieu


Signed-off-by: Arvind Yadav 
---
  drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 288a423..e97775d 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -60,7 +60,7 @@ struct etm_event_data {
 NULL,
  };

-static struct attribute_group etm_pmu_format_group = {
+static const struct attribute_group etm_pmu_format_group = {
 .name   = "format",
 .attrs  = etm_config_formats_attr,
  };
--
1.9.1


Thanks,
~arvind

[Patch] mqueue: fix netlink sock refcnt and skb refcnt

[Cong Wang]

netlink_sendskb() is problematic, it releases sock refcnt
silently which could cause troubles we can call it multiple
times. info->notify_sock is a good example where we
setup once and use it to send netlink skb's for many times.
It should not hold or release any refcnt, but needs to rely
on netlink_attachskb()/netlink_detachskb() to hold/release
the corresponding refcnt.

Same for the skb attached to this sock, it is allocated once
and used for multiple times, so we should hold its refcnt
in netlink_attachskb().

At last, we need to call netlink_detachskb() to release
both refcnt's after we remove the notification.

Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Manfred Spraul 
Signed-off-by: Cong Wang 
---
 ipc/mqueue.c |  1 +
 net/netlink/af_netlink.c | 25 ++---
 2 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index eb1391b..8b0a0ce 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -683,6 +683,7 @@ static void remove_notification(struct mqueue_inode_info 
*info)
info->notify.sigev_notify == SIGEV_THREAD) {
set_cookie(info->notify_cookie, NOTIFY_REMOVED);
netlink_sendskb(info->notify_sock, info->notify_cookie);
+   netlink_detachskb(info->notify_sock, info->notify_cookie);
}
put_pid(info->notify_owner);
put_user_ns(info->notify_user_ns);
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5acee49..9f2d6ca 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1159,8 +1159,8 @@ static struct sk_buff *netlink_alloc_large_skb(unsigned 
int size,
  * all error checks are performed and memory in the queue is reserved.
  * Return values:
  * < 0: error. skb freed, reference to sock dropped.
- * 0: continue
- * 1: repeat lookup - reference dropped while waiting for socket memory.
+ * 0: continue - skb reference is held.
+ * 1: repeat lookup - sock reference dropped while waiting for socket memory.
  */
 int netlink_attachskb(struct sock *sk, struct sk_buff *skb,
  long *timeo, struct sock *ssk)
@@ -1198,11 +1198,12 @@ int netlink_attachskb(struct sock *sk, struct sk_buff 
*skb,
}
return 1;
}
+   skb_get(skb);
netlink_skb_set_owner_r(skb, sk);
return 0;
 }
 
-static int __netlink_sendskb(struct sock *sk, struct sk_buff *skb)
+int netlink_sendskb(struct sock *sk, struct sk_buff *skb)
 {
int len = skb->len;
 
@@ -1213,14 +1214,6 @@ static int __netlink_sendskb(struct sock *sk, struct 
sk_buff *skb)
return len;
 }
 
-int netlink_sendskb(struct sock *sk, struct sk_buff *skb)
-{
-   int len = __netlink_sendskb(sk, skb);
-
-   sock_put(sk);
-   return len;
-}
-
 void netlink_detachskb(struct sock *sk, struct sk_buff *skb)
 {
kfree_skb(skb);
@@ -1303,7 +1296,9 @@ int netlink_unicast(struct sock *ssk, struct sk_buff *skb,
if (err)
return err;
 
-   return netlink_sendskb(sk, skb);
+   err = netlink_sendskb(sk, skb);
+   netlink_detachskb(sk, skb);
+   return err;
 }
 EXPORT_SYMBOL(netlink_unicast);
 
@@ -1333,7 +1328,7 @@ static int netlink_broadcast_deliver(struct sock *sk, 
struct sk_buff *skb)
if (atomic_read(>sk_rmem_alloc) <= sk->sk_rcvbuf &&
!test_bit(NETLINK_S_CONGESTED, >state)) {
netlink_skb_set_owner_r(skb, sk);
-   __netlink_sendskb(sk, skb);
+   netlink_sendskb(sk, skb);
return atomic_read(>sk_rmem_alloc) > (sk->sk_rcvbuf >> 1);
}
return -1;
@@ -2183,7 +2178,7 @@ static int netlink_dump(struct sock *sk)
if (sk_filter(sk, skb))
kfree_skb(skb);
else
-   __netlink_sendskb(sk, skb);
+   netlink_sendskb(sk, skb);
return 0;
}
 
@@ -2198,7 +2193,7 @@ static int netlink_dump(struct sock *sk)
if (sk_filter(sk, skb))
kfree_skb(skb);
else
-   __netlink_sendskb(sk, skb);
+   netlink_sendskb(sk, skb);
 
if (cb->done)
cb->done(cb);
-- 
2.5.5

[Patch] mqueue: fix netlink sock refcnt and skb refcnt

[Cong Wang]

netlink_sendskb() is problematic, it releases sock refcnt
silently which could cause troubles we can call it multiple
times. info->notify_sock is a good example where we
setup once and use it to send netlink skb's for many times.
It should not hold or release any refcnt, but needs to rely
on netlink_attachskb()/netlink_detachskb() to hold/release
the corresponding refcnt.

Same for the skb attached to this sock, it is allocated once
and used for multiple times, so we should hold its refcnt
in netlink_attachskb().

At last, we need to call netlink_detachskb() to release
both refcnt's after we remove the notification.

Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Manfred Spraul 
Signed-off-by: Cong Wang 
---
 ipc/mqueue.c |  1 +
 net/netlink/af_netlink.c | 25 ++---
 2 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index eb1391b..8b0a0ce 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -683,6 +683,7 @@ static void remove_notification(struct mqueue_inode_info 
*info)
info->notify.sigev_notify == SIGEV_THREAD) {
set_cookie(info->notify_cookie, NOTIFY_REMOVED);
netlink_sendskb(info->notify_sock, info->notify_cookie);
+   netlink_detachskb(info->notify_sock, info->notify_cookie);
}
put_pid(info->notify_owner);
put_user_ns(info->notify_user_ns);
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5acee49..9f2d6ca 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1159,8 +1159,8 @@ static struct sk_buff *netlink_alloc_large_skb(unsigned 
int size,
  * all error checks are performed and memory in the queue is reserved.
  * Return values:
  * < 0: error. skb freed, reference to sock dropped.
- * 0: continue
- * 1: repeat lookup - reference dropped while waiting for socket memory.
+ * 0: continue - skb reference is held.
+ * 1: repeat lookup - sock reference dropped while waiting for socket memory.
  */
 int netlink_attachskb(struct sock *sk, struct sk_buff *skb,
  long *timeo, struct sock *ssk)
@@ -1198,11 +1198,12 @@ int netlink_attachskb(struct sock *sk, struct sk_buff 
*skb,
}
return 1;
}
+   skb_get(skb);
netlink_skb_set_owner_r(skb, sk);
return 0;
 }
 
-static int __netlink_sendskb(struct sock *sk, struct sk_buff *skb)
+int netlink_sendskb(struct sock *sk, struct sk_buff *skb)
 {
int len = skb->len;
 
@@ -1213,14 +1214,6 @@ static int __netlink_sendskb(struct sock *sk, struct 
sk_buff *skb)
return len;
 }
 
-int netlink_sendskb(struct sock *sk, struct sk_buff *skb)
-{
-   int len = __netlink_sendskb(sk, skb);
-
-   sock_put(sk);
-   return len;
-}
-
 void netlink_detachskb(struct sock *sk, struct sk_buff *skb)
 {
kfree_skb(skb);
@@ -1303,7 +1296,9 @@ int netlink_unicast(struct sock *ssk, struct sk_buff *skb,
if (err)
return err;
 
-   return netlink_sendskb(sk, skb);
+   err = netlink_sendskb(sk, skb);
+   netlink_detachskb(sk, skb);
+   return err;
 }
 EXPORT_SYMBOL(netlink_unicast);
 
@@ -1333,7 +1328,7 @@ static int netlink_broadcast_deliver(struct sock *sk, 
struct sk_buff *skb)
if (atomic_read(>sk_rmem_alloc) <= sk->sk_rcvbuf &&
!test_bit(NETLINK_S_CONGESTED, >state)) {
netlink_skb_set_owner_r(skb, sk);
-   __netlink_sendskb(sk, skb);
+   netlink_sendskb(sk, skb);
return atomic_read(>sk_rmem_alloc) > (sk->sk_rcvbuf >> 1);
}
return -1;
@@ -2183,7 +2178,7 @@ static int netlink_dump(struct sock *sk)
if (sk_filter(sk, skb))
kfree_skb(skb);
else
-   __netlink_sendskb(sk, skb);
+   netlink_sendskb(sk, skb);
return 0;
}
 
@@ -2198,7 +2193,7 @@ static int netlink_dump(struct sock *sk)
if (sk_filter(sk, skb))
kfree_skb(skb);
else
-   __netlink_sendskb(sk, skb);
+   netlink_sendskb(sk, skb);
 
if (cb->done)
cb->done(cb);
-- 
2.5.5

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

[Viresh Kumar]

Hi Mitchell,

On 09-07-17, 20:25, Mitchell Tasman wrote:
> Adjust formatting of various statements to keep line length within
> the 80 column limit preferred by the Linux kernel coding style.

We try to follow that most of the time, but the end result should be easily
readable.  If it isn't, then we just ignore the rule.

> Signed-off-by: Mitchell Tasman 
> ---
> Changes in v2: Add back a missing space in a comment
> 
>  drivers/staging/greybus/arche-platform.c | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index eced2d2..eedd239 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -172,15 +172,21 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>   if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) {
>   if (time_before(jiffies,
>   arche_pdata->wake_detect_start +
> - 
> msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
> - 
> arche_platform_set_wake_detect_state(arche_pdata,
> -  
> WD_STATE_IDLE);
> + msecs_to_jiffies(
> + WD_COLDBOOT_PULSE_WIDTH_MS))) {
> + arche_platform_set_wake_detect_state(

We don't break the lines like this in kernel to satisfy the 80 column width
rule. Surely, some places would have similar code, but in general this isn't
recommended. And that's why we never bothered about 80 column rule in this and
below cases.

> + arche_pdata,
> + WD_STATE_IDLE);
>   } else {
> - /* Check we are not in middle of irq thread 
> already */
> + /*
> +  * Check we are not in middle of irq thread
> +  * already
> +  */

Yes, such changes would be fine.

>   if (arche_pdata->wake_detect_state !=
>   WD_STATE_COLDBOOT_START) {
> - 
> arche_platform_set_wake_detect_state(arche_pdata,
> -  
> WD_STATE_COLDBOOT_TRIG);
> + arche_platform_set_wake_detect_state(

Not this.

> + arche_pdata,
> + WD_STATE_COLDBOOT_TRIG);
>   spin_unlock_irqrestore(
>   _pdata->wake_lock,
>   flags);
> @@ -199,8 +205,9 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>* beyond 30msec, then it is coldboot else fallback
>* to standby boot.
>*/
> - arche_platform_set_wake_detect_state(arche_pdata,
> -  
> WD_STATE_BOOT_INIT);
> + arche_platform_set_wake_detect_state(

Not this.

> + arche_pdata,
> + WD_STATE_BOOT_INIT);
>   }
>   }
>  
> @@ -657,12 +664,14 @@ static SIMPLE_DEV_PM_OPS(arche_platform_pm_ops,
>   arche_platform_resume);
>  
>  static const struct of_device_id arche_platform_of_match[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },

This would be fine though.

>   { },
>  };
>  
>  static const struct of_device_id arche_combined_id[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },
>   { .compatible = "usb,2", },
>   { },
>  };

-- 
viresh

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

[Viresh Kumar]

Hi Mitchell,

On 09-07-17, 20:25, Mitchell Tasman wrote:
> Adjust formatting of various statements to keep line length within
> the 80 column limit preferred by the Linux kernel coding style.

We try to follow that most of the time, but the end result should be easily
readable.  If it isn't, then we just ignore the rule.

> Signed-off-by: Mitchell Tasman 
> ---
> Changes in v2: Add back a missing space in a comment
> 
>  drivers/staging/greybus/arche-platform.c | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index eced2d2..eedd239 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -172,15 +172,21 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>   if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) {
>   if (time_before(jiffies,
>   arche_pdata->wake_detect_start +
> - 
> msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
> - 
> arche_platform_set_wake_detect_state(arche_pdata,
> -  
> WD_STATE_IDLE);
> + msecs_to_jiffies(
> + WD_COLDBOOT_PULSE_WIDTH_MS))) {
> + arche_platform_set_wake_detect_state(

We don't break the lines like this in kernel to satisfy the 80 column width
rule. Surely, some places would have similar code, but in general this isn't
recommended. And that's why we never bothered about 80 column rule in this and
below cases.

> + arche_pdata,
> + WD_STATE_IDLE);
>   } else {
> - /* Check we are not in middle of irq thread 
> already */
> + /*
> +  * Check we are not in middle of irq thread
> +  * already
> +  */

Yes, such changes would be fine.

>   if (arche_pdata->wake_detect_state !=
>   WD_STATE_COLDBOOT_START) {
> - 
> arche_platform_set_wake_detect_state(arche_pdata,
> -  
> WD_STATE_COLDBOOT_TRIG);
> + arche_platform_set_wake_detect_state(

Not this.

> + arche_pdata,
> + WD_STATE_COLDBOOT_TRIG);
>   spin_unlock_irqrestore(
>   _pdata->wake_lock,
>   flags);
> @@ -199,8 +205,9 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>* beyond 30msec, then it is coldboot else fallback
>* to standby boot.
>*/
> - arche_platform_set_wake_detect_state(arche_pdata,
> -  
> WD_STATE_BOOT_INIT);
> + arche_platform_set_wake_detect_state(

Not this.

> + arche_pdata,
> + WD_STATE_BOOT_INIT);
>   }
>   }
>  
> @@ -657,12 +664,14 @@ static SIMPLE_DEV_PM_OPS(arche_platform_pm_ops,
>   arche_platform_resume);
>  
>  static const struct of_device_id arche_platform_of_match[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },

This would be fine though.

>   { },
>  };
>  
>  static const struct of_device_id arche_combined_id[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },
>   { .compatible = "usb,2", },
>   { },
>  };

-- 
viresh

linux-next: manual merge of the akpm-current tree with the vfs tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  fs/hugetlbfs/inode.c

between commit:

  4a25220d4e43 ("hugetlbfs: Implement show_options")

from the vfs tree and commit:

  25153b1fbd8a ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory 
error")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/hugetlbfs/inode.c
index 99b3b9836575,52388611635e..
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@@ -851,46 -851,16 +851,56 @@@ static int hugetlbfs_migrate_page(struc
return MIGRATEPAGE_SUCCESS;
  }
  
 +/*
 + * Display the mount options in /proc/mounts.
 + */
 +static int hugetlbfs_show_options(struct seq_file *m, struct dentry *root)
 +{
 +  struct hugetlbfs_sb_info *sbinfo = HUGETLBFS_SB(root->d_sb);
 +  struct hugepage_subpool *spool = sbinfo->spool;
 +  unsigned long hpage_size = huge_page_size(sbinfo->hstate);
 +  unsigned hpage_shift = huge_page_shift(sbinfo->hstate);
 +  char mod;
 +
 +  if (!uid_eq(sbinfo->uid, GLOBAL_ROOT_UID))
 +  seq_printf(m, ",uid=%u",
 + from_kuid_munged(_user_ns, sbinfo->uid));
 +  if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
 +  seq_printf(m, ",gid=%u",
 + from_kgid_munged(_user_ns, sbinfo->gid));
 +  if (sbinfo->mode != 0755)
 +  seq_printf(m, ",mode=%o", sbinfo->mode);
 +  if (sbinfo->max_inodes != -1)
 +  seq_printf(m, ",nr_inodes=%lu", sbinfo->max_inodes);
 +
 +  hpage_size /= 1024;
 +  mod = 'K';
 +  if (hpage_size >= 1024) {
 +  hpage_size /= 1024;
 +  mod = 'M';
 +  }
 +  seq_printf(m, ",pagesize=%lu%c", hpage_size, mod);
 +  if (spool) {
 +  if (spool->max_hpages != -1)
 +  seq_printf(m, ",size=%llu",
 + (unsigned long long)spool->max_hpages << 
hpage_shift);
 +  if (spool->min_hpages != -1)
 +  seq_printf(m, ",min_size=%llu",
 + (unsigned long long)spool->min_hpages << 
hpage_shift);
 +  }
 +  return 0;
 +}
 +
+ static int hugetlbfs_error_remove_page(struct address_space *mapping,
+   struct page *page)
+ {
+   struct inode *inode = mapping->host;
+ 
+   remove_huge_page(page);
+   hugetlb_fix_reserve_counts(inode);
+   return 0;
+ }
+ 
  static int hugetlbfs_statfs(struct dentry *dentry, struct kstatfs *buf)
  {
struct hugetlbfs_sb_info *sbinfo = HUGETLBFS_SB(dentry->d_sb);

linux-next: manual merge of the akpm-current tree with the vfs tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  fs/hugetlbfs/inode.c

between commit:

  4a25220d4e43 ("hugetlbfs: Implement show_options")

from the vfs tree and commit:

  25153b1fbd8a ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory 
error")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/hugetlbfs/inode.c
index 99b3b9836575,52388611635e..
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@@ -851,46 -851,16 +851,56 @@@ static int hugetlbfs_migrate_page(struc
return MIGRATEPAGE_SUCCESS;
  }
  
 +/*
 + * Display the mount options in /proc/mounts.
 + */
 +static int hugetlbfs_show_options(struct seq_file *m, struct dentry *root)
 +{
 +  struct hugetlbfs_sb_info *sbinfo = HUGETLBFS_SB(root->d_sb);
 +  struct hugepage_subpool *spool = sbinfo->spool;
 +  unsigned long hpage_size = huge_page_size(sbinfo->hstate);
 +  unsigned hpage_shift = huge_page_shift(sbinfo->hstate);
 +  char mod;
 +
 +  if (!uid_eq(sbinfo->uid, GLOBAL_ROOT_UID))
 +  seq_printf(m, ",uid=%u",
 + from_kuid_munged(_user_ns, sbinfo->uid));
 +  if (!gid_eq(sbinfo->gid, GLOBAL_ROOT_GID))
 +  seq_printf(m, ",gid=%u",
 + from_kgid_munged(_user_ns, sbinfo->gid));
 +  if (sbinfo->mode != 0755)
 +  seq_printf(m, ",mode=%o", sbinfo->mode);
 +  if (sbinfo->max_inodes != -1)
 +  seq_printf(m, ",nr_inodes=%lu", sbinfo->max_inodes);
 +
 +  hpage_size /= 1024;
 +  mod = 'K';
 +  if (hpage_size >= 1024) {
 +  hpage_size /= 1024;
 +  mod = 'M';
 +  }
 +  seq_printf(m, ",pagesize=%lu%c", hpage_size, mod);
 +  if (spool) {
 +  if (spool->max_hpages != -1)
 +  seq_printf(m, ",size=%llu",
 + (unsigned long long)spool->max_hpages << 
hpage_shift);
 +  if (spool->min_hpages != -1)
 +  seq_printf(m, ",min_size=%llu",
 + (unsigned long long)spool->min_hpages << 
hpage_shift);
 +  }
 +  return 0;
 +}
 +
+ static int hugetlbfs_error_remove_page(struct address_space *mapping,
+   struct page *page)
+ {
+   struct inode *inode = mapping->host;
+ 
+   remove_huge_page(page);
+   hugetlb_fix_reserve_counts(inode);
+   return 0;
+ }
+ 
  static int hugetlbfs_statfs(struct dentry *dentry, struct kstatfs *buf)
  {
struct hugetlbfs_sb_info *sbinfo = HUGETLBFS_SB(dentry->d_sb);

[PATCH] autofs: Revert wait_queue_t => wait_queue_entry_t rename

[Florian Fainelli]

This reverts commit ac6424b981bce1c4bc55675c6ce11bfe1bbfa64f "("sched/wait:
Rename wait_queue_t => wait_queue_entry_t") as far as the autofs user API
structures are concerned since that would break user space build against such
kernel headers.

Fixes: ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
Signed-off-by: Florian Fainelli 
---
 include/uapi/linux/auto_fs.h  | 4 ++--
 include/uapi/linux/auto_fs4.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/auto_fs.h b/include/uapi/linux/auto_fs.h
index 1953f8d6063b..aa63451ef20a 100644
--- a/include/uapi/linux/auto_fs.h
+++ b/include/uapi/linux/auto_fs.h
@@ -26,7 +26,7 @@
 #define AUTOFS_MIN_PROTO_VERSION   AUTOFS_PROTO_VERSION
 
 /*
- * The wait_queue_entry_token (autofs_wqt_t) is part of a structure which is 
passed
+ * The wait_queue_token (autofs_wqt_t) is part of a structure which is passed
  * back to the kernel via ioctl from userspace. On architectures where 32- and
  * 64-bit userspace binaries can be executed it's important that the size of
  * autofs_wqt_t stays constant between 32- and 64-bit Linux kernels so that we
@@ -49,7 +49,7 @@ struct autofs_packet_hdr {
 
 struct autofs_packet_missing {
struct autofs_packet_hdr hdr;
-   autofs_wqt_t wait_queue_entry_token;
+   autofs_wqt_t wait_queue_token;
int len;
char name[NAME_MAX+1];
 }; 
diff --git a/include/uapi/linux/auto_fs4.h b/include/uapi/linux/auto_fs4.h
index 65b72d0222e7..7c6da423d54e 100644
--- a/include/uapi/linux/auto_fs4.h
+++ b/include/uapi/linux/auto_fs4.h
@@ -108,7 +108,7 @@ enum autofs_notify {
 /* v4 multi expire (via pipe) */
 struct autofs_packet_expire_multi {
struct autofs_packet_hdr hdr;
-   autofs_wqt_t wait_queue_entry_token;
+   autofs_wqt_t wait_queue_token;
int len;
char name[NAME_MAX+1];
 };
@@ -123,7 +123,7 @@ union autofs_packet_union {
 /* autofs v5 common packet struct */
 struct autofs_v5_packet {
struct autofs_packet_hdr hdr;
-   autofs_wqt_t wait_queue_entry_token;
+   autofs_wqt_t wait_queue_token;
__u32 dev;
__u64 ino;
__u32 uid;
-- 
2.11.0

[PATCH] autofs: Revert wait_queue_t => wait_queue_entry_t rename

[Florian Fainelli]

This reverts commit ac6424b981bce1c4bc55675c6ce11bfe1bbfa64f "("sched/wait:
Rename wait_queue_t => wait_queue_entry_t") as far as the autofs user API
structures are concerned since that would break user space build against such
kernel headers.

Fixes: ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
Signed-off-by: Florian Fainelli 
---
 include/uapi/linux/auto_fs.h  | 4 ++--
 include/uapi/linux/auto_fs4.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/auto_fs.h b/include/uapi/linux/auto_fs.h
index 1953f8d6063b..aa63451ef20a 100644
--- a/include/uapi/linux/auto_fs.h
+++ b/include/uapi/linux/auto_fs.h
@@ -26,7 +26,7 @@
 #define AUTOFS_MIN_PROTO_VERSION   AUTOFS_PROTO_VERSION
 
 /*
- * The wait_queue_entry_token (autofs_wqt_t) is part of a structure which is 
passed
+ * The wait_queue_token (autofs_wqt_t) is part of a structure which is passed
  * back to the kernel via ioctl from userspace. On architectures where 32- and
  * 64-bit userspace binaries can be executed it's important that the size of
  * autofs_wqt_t stays constant between 32- and 64-bit Linux kernels so that we
@@ -49,7 +49,7 @@ struct autofs_packet_hdr {
 
 struct autofs_packet_missing {
struct autofs_packet_hdr hdr;
-   autofs_wqt_t wait_queue_entry_token;
+   autofs_wqt_t wait_queue_token;
int len;
char name[NAME_MAX+1];
 }; 
diff --git a/include/uapi/linux/auto_fs4.h b/include/uapi/linux/auto_fs4.h
index 65b72d0222e7..7c6da423d54e 100644
--- a/include/uapi/linux/auto_fs4.h
+++ b/include/uapi/linux/auto_fs4.h
@@ -108,7 +108,7 @@ enum autofs_notify {
 /* v4 multi expire (via pipe) */
 struct autofs_packet_expire_multi {
struct autofs_packet_hdr hdr;
-   autofs_wqt_t wait_queue_entry_token;
+   autofs_wqt_t wait_queue_token;
int len;
char name[NAME_MAX+1];
 };
@@ -123,7 +123,7 @@ union autofs_packet_union {
 /* autofs v5 common packet struct */
 struct autofs_v5_packet {
struct autofs_packet_hdr hdr;
-   autofs_wqt_t wait_queue_entry_token;
+   autofs_wqt_t wait_queue_token;
__u32 dev;
__u64 ino;
__u32 uid;
-- 
2.11.0

[no subject]

[Sistem Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama: 
Username: 
sandi: 
Konfirmasi sandi: 
E-mail: 
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:45677qeddf...nw.na.website Admin..id...9876mm.
2017 Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

[no subject]

[Sistem Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama: 
Username: 
sandi: 
Konfirmasi sandi: 
E-mail: 
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:45677qeddf...nw.na.website Admin..id...9876mm.
2017 Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

Re: [PATCH] cifs: Clean up unused variables in smb2pdu.c

[Steve French]

merged into cifs-2.6.git for-next

On Sun, Jul 9, 2017 at 5:45 AM, Christos Gkekas  wrote:
> There are multiple unused variables struct TCP_Server_Info *server
> defined in many methods in smb2pdu.c. They should be removed and related
> logic simplified.
>
> Signed-off-by: Christos Gkekas 
> ---
>  fs/cifs/smb2pdu.c | 35 +++
>  1 file changed, 7 insertions(+), 28 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 4938e8b..ee59592 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -1167,15 +1167,12 @@ SMB2_tcon(const unsigned int xid, struct cifs_ses 
> *ses, const char *tree,
> int rc = 0;
> int resp_buftype;
> int unc_path_len;
> -   struct TCP_Server_Info *server;
> __le16 *unc_path = NULL;
> int flags = 0;
>
> cifs_dbg(FYI, "TCON\n");
>
> -   if ((ses->server) && tree)
> -   server = ses->server;
> -   else
> +   if (!(ses->server) || !tree)
> return -EIO;
>
> unc_path = kmalloc(MAX_SHARENAME_LENGTH * 2, GFP_KERNEL);
> @@ -1294,15 +1291,12 @@ SMB2_tdis(const unsigned int xid, struct cifs_tcon 
> *tcon)
>  {
> struct smb2_tree_disconnect_req *req; /* response is trivial */
> int rc = 0;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> int flags = 0;
>
> cifs_dbg(FYI, "Tree Disconnect\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> if ((tcon->need_reconnect) || (tcon->ses->need_reconnect))
> @@ -1794,7 +1788,6 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
> struct smb2_ioctl_req *req;
> struct smb2_ioctl_rsp *rsp;
> struct smb2_sync_hdr *shdr;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses;
> struct kvec iov[2];
> struct kvec rsp_iov;
> @@ -1817,9 +1810,7 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
> else
> return -EIO;
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_IOCTL, tcon, (void **) );
> @@ -1977,7 +1968,6 @@ SMB2_close(const unsigned int xid, struct cifs_tcon 
> *tcon,
>  {
> struct smb2_close_req *req;
> struct smb2_close_rsp *rsp;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> struct kvec iov[1];
> struct kvec rsp_iov;
> @@ -1987,9 +1977,7 @@ SMB2_close(const unsigned int xid, struct cifs_tcon 
> *tcon,
>
> cifs_dbg(FYI, "Close\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_CLOSE, tcon, (void **) );
> @@ -2091,15 +2079,12 @@ query_info(const unsigned int xid, struct cifs_tcon 
> *tcon,
> struct kvec rsp_iov;
> int rc = 0;
> int resp_buftype;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> int flags = 0;
>
> cifs_dbg(FYI, "Query Info\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_QUERY_INFO, tcon, (void **) );
> @@ -2311,7 +2296,6 @@ SMB2_flush(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
>u64 volatile_fid)
>  {
> struct smb2_flush_req *req;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> struct kvec iov[1];
> struct kvec rsp_iov;
> @@ -2321,9 +2305,7 @@ SMB2_flush(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
>
> cifs_dbg(FYI, "Flush\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_FLUSH, tcon, (void **) );
> @@ -3010,13 +2992,10 @@ send_set_info(const unsigned int xid, struct 
> cifs_tcon *tcon,
> int rc = 0;
> int resp_buftype;
> unsigned int i;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> int flags = 0;
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> if (!num)
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More 

Re: [PATCH] cifs: Clean up unused variables in smb2pdu.c

[Steve French]

merged into cifs-2.6.git for-next

On Sun, Jul 9, 2017 at 5:45 AM, Christos Gkekas  wrote:
> There are multiple unused variables struct TCP_Server_Info *server
> defined in many methods in smb2pdu.c. They should be removed and related
> logic simplified.
>
> Signed-off-by: Christos Gkekas 
> ---
>  fs/cifs/smb2pdu.c | 35 +++
>  1 file changed, 7 insertions(+), 28 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 4938e8b..ee59592 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -1167,15 +1167,12 @@ SMB2_tcon(const unsigned int xid, struct cifs_ses 
> *ses, const char *tree,
> int rc = 0;
> int resp_buftype;
> int unc_path_len;
> -   struct TCP_Server_Info *server;
> __le16 *unc_path = NULL;
> int flags = 0;
>
> cifs_dbg(FYI, "TCON\n");
>
> -   if ((ses->server) && tree)
> -   server = ses->server;
> -   else
> +   if (!(ses->server) || !tree)
> return -EIO;
>
> unc_path = kmalloc(MAX_SHARENAME_LENGTH * 2, GFP_KERNEL);
> @@ -1294,15 +1291,12 @@ SMB2_tdis(const unsigned int xid, struct cifs_tcon 
> *tcon)
>  {
> struct smb2_tree_disconnect_req *req; /* response is trivial */
> int rc = 0;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> int flags = 0;
>
> cifs_dbg(FYI, "Tree Disconnect\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> if ((tcon->need_reconnect) || (tcon->ses->need_reconnect))
> @@ -1794,7 +1788,6 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
> struct smb2_ioctl_req *req;
> struct smb2_ioctl_rsp *rsp;
> struct smb2_sync_hdr *shdr;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses;
> struct kvec iov[2];
> struct kvec rsp_iov;
> @@ -1817,9 +1810,7 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
> else
> return -EIO;
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_IOCTL, tcon, (void **) );
> @@ -1977,7 +1968,6 @@ SMB2_close(const unsigned int xid, struct cifs_tcon 
> *tcon,
>  {
> struct smb2_close_req *req;
> struct smb2_close_rsp *rsp;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> struct kvec iov[1];
> struct kvec rsp_iov;
> @@ -1987,9 +1977,7 @@ SMB2_close(const unsigned int xid, struct cifs_tcon 
> *tcon,
>
> cifs_dbg(FYI, "Close\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_CLOSE, tcon, (void **) );
> @@ -2091,15 +2079,12 @@ query_info(const unsigned int xid, struct cifs_tcon 
> *tcon,
> struct kvec rsp_iov;
> int rc = 0;
> int resp_buftype;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> int flags = 0;
>
> cifs_dbg(FYI, "Query Info\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_QUERY_INFO, tcon, (void **) );
> @@ -2311,7 +2296,6 @@ SMB2_flush(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
>u64 volatile_fid)
>  {
> struct smb2_flush_req *req;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> struct kvec iov[1];
> struct kvec rsp_iov;
> @@ -2321,9 +2305,7 @@ SMB2_flush(const unsigned int xid, struct cifs_tcon 
> *tcon, u64 persistent_fid,
>
> cifs_dbg(FYI, "Flush\n");
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> rc = small_smb2_init(SMB2_FLUSH, tcon, (void **) );
> @@ -3010,13 +2992,10 @@ send_set_info(const unsigned int xid, struct 
> cifs_tcon *tcon,
> int rc = 0;
> int resp_buftype;
> unsigned int i;
> -   struct TCP_Server_Info *server;
> struct cifs_ses *ses = tcon->ses;
> int flags = 0;
>
> -   if (ses && (ses->server))
> -   server = ses->server;
> -   else
> +   if (!ses || !(ses->server))
> return -EIO;
>
> if (!num)
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  

Re: [PATCH 4/5] powernv:idle: Move initialization of sibling pacas to pnv_alloc_idle_core_states

[Michael Ellerman]

Nicholas Piggin  writes:
> On Fri, 7 Jul 2017 20:34:16 +0530
> Gautham R Shenoy  wrote:
>> On Fri, Jul 07, 2017 at 01:16:09AM +1000, Nicholas Piggin wrote:
>> > 
>> > Speaking of which... core_idle_state and thread_sibling_pacas are
>> > allocated with kmalloc_node... What happens if we take an SLB miss
>> > in the idle wakeup code on these guys? Nothing good I think. Perhaps
>> > we should put them into the pacas or somewhere in bolted memory.  
>> 
>> Yes, though the SLB miss hasn't yet been encountered in practise so
>> far!
>
> Considering it's a node-affine allocation, it may actually be possible
> to hit in practice on very large memory systems in practice.

You can boot with disable_1tb_segments on the kernel command line to
increase the change of hitting it.

cheers

Re: [PATCH 4/5] powernv:idle: Move initialization of sibling pacas to pnv_alloc_idle_core_states

[Michael Ellerman]

Nicholas Piggin  writes:
> On Fri, 7 Jul 2017 20:34:16 +0530
> Gautham R Shenoy  wrote:
>> On Fri, Jul 07, 2017 at 01:16:09AM +1000, Nicholas Piggin wrote:
>> > 
>> > Speaking of which... core_idle_state and thread_sibling_pacas are
>> > allocated with kmalloc_node... What happens if we take an SLB miss
>> > in the idle wakeup code on these guys? Nothing good I think. Perhaps
>> > we should put them into the pacas or somewhere in bolted memory.  
>> 
>> Yes, though the SLB miss hasn't yet been encountered in practise so
>> far!
>
> Considering it's a node-affine allocation, it may actually be possible
> to hit in practice on very large memory systems in practice.

You can boot with disable_1tb_segments on the kernel command line to
increase the change of hitting it.

cheers

Re: [PATCH] ARM: owl: smp: Drop owl_secondary_boot()

[Florian Fainelli]

On 07/09/2017 02:55 PM, Andreas Färber wrote:
> Am 06.07.2017 um 19:17 schrieb Andreas Färber:
>> Am 05.07.2017 um 04:36 schrieb Florian Fainelli:
>>> On July 4, 2017 4:32:18 PM PDT, "Andreas Färber"  wrote:
 -  writel(virt_to_phys(owl_secondary_startup),
 +  writel(virt_to_phys(secondary_startup),
   timer_base_addr + OWL_CPU1_ADDR + (cpu - 1) * 4);
>>>
>>> This is a kernel symbol so please use __pa_symbol() here, also you might 
>>> want to build with CONFIG_DEBUG_VIRTUAL and see if you get other warnings 
>>> about using virt_to_phys() in the owl platform code (I did not check if 
>>> there are other uses)
> 
> Florian, I don't spot any build or runtime warning for this
> virt_to_phys() with CONFIG_DEBUG_VIRTUAL=y on Guitar/S500:

You would only see run time warnings, not build time warnings for this,
but in fact, no, see below.

> 
> [0.062765] CPU: Testing write buffer coherency: ok
> [0.063468] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [0.100856] Setting up static identity map for 0x10 - 0x100060
> [0.120864] Hierarchical SRCU implementation.
> [0.161092] smp: Bringing up secondary CPUs ...
> [0.291654] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
> [0.46] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
> [0.552798] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
> [0.553074] smp: Brought up 1 node, 4 CPUs
> [0.553388] SMP: Total of 4 processors activated (1629.38 BogoMIPS).
> [0.553477] CPU: All CPU(s) started in SVC mode.
> 
> I've tested that __pa_symbol() works as well, but I'd like to understand
> this for commit message and future testing. Am I missing other options?

After re-checking the implementation you would get a warning only if you
were using virt_to_phys() against a part of the kernel that is not in
the linear map, similarly you would get a warning if __pa_symbol() was
used against symbols outside of the kernel image, this is obviously not
the case here. You should use __pa_symbol() just for correctness, no
warning would be produced, sorry for misleading you with that.
-- 
Florian

Re: [PATCH] ARM: owl: smp: Drop owl_secondary_boot()

[Florian Fainelli]

On 07/09/2017 02:55 PM, Andreas Färber wrote:
> Am 06.07.2017 um 19:17 schrieb Andreas Färber:
>> Am 05.07.2017 um 04:36 schrieb Florian Fainelli:
>>> On July 4, 2017 4:32:18 PM PDT, "Andreas Färber"  wrote:
 -  writel(virt_to_phys(owl_secondary_startup),
 +  writel(virt_to_phys(secondary_startup),
   timer_base_addr + OWL_CPU1_ADDR + (cpu - 1) * 4);
>>>
>>> This is a kernel symbol so please use __pa_symbol() here, also you might 
>>> want to build with CONFIG_DEBUG_VIRTUAL and see if you get other warnings 
>>> about using virt_to_phys() in the owl platform code (I did not check if 
>>> there are other uses)
> 
> Florian, I don't spot any build or runtime warning for this
> virt_to_phys() with CONFIG_DEBUG_VIRTUAL=y on Guitar/S500:

You would only see run time warnings, not build time warnings for this,
but in fact, no, see below.

> 
> [0.062765] CPU: Testing write buffer coherency: ok
> [0.063468] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [0.100856] Setting up static identity map for 0x10 - 0x100060
> [0.120864] Hierarchical SRCU implementation.
> [0.161092] smp: Bringing up secondary CPUs ...
> [0.291654] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
> [0.46] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
> [0.552798] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
> [0.553074] smp: Brought up 1 node, 4 CPUs
> [0.553388] SMP: Total of 4 processors activated (1629.38 BogoMIPS).
> [0.553477] CPU: All CPU(s) started in SVC mode.
> 
> I've tested that __pa_symbol() works as well, but I'd like to understand
> this for commit message and future testing. Am I missing other options?

After re-checking the implementation you would get a warning only if you
were using virt_to_phys() against a part of the kernel that is not in
the linear map, similarly you would get a warning if __pa_symbol() was
used against symbols outside of the kernel image, this is obviously not
the case here. You should use __pa_symbol() just for correctness, no
warning would be produced, sorry for misleading you with that.
-- 
Florian

Re: [GIT PULL] scheduler changes for v4.13

[Florian Fainelli]

On 07/03/2017 01:39 AM, Ingo Molnar wrote:
> Linus,
> 
> Please pull the latest sched-core-for-linus git tree from:
> 
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> sched-core-for-linus
> 
># HEAD: 72298e5c92c50edd8cb7cfda4519483ce65fa166 sched/cputime: Refactor 
> the cputime_adjust() code
> 
> The main changes in this cycle were:
> 
>  - Add the SYSTEM_SCHEDULING bootup state to move various scheduler debug 
> checks 
>earlier into the bootup. This turns silent and sporadically deadly bugs 
> into
>nice, deterministic splats. Fix some of the splats that triggered.
>(Thomas Gleixner)
> 
>  - A round of restructuring and refactoring of the load-balancing and 
> topology 
>code (Peter Zijlstra)
> 
>  - Another round of consolidating ~20 of incremental scheduler code history: 
> this 
>time in terms of wait-queue nomenclature. (I didn't get much feedback on 
> these 
>renaming patches, and we can still easily change any names I might have 
>misplaced, so if anyone hates a new name, please holler and I'll fix it.)
>(Ingo Molnar)

This commit ac6424b981bce1c4bc55675c6ce11bfe1bbfa64f ("sched/wait:
Rename wait_queue_t => wait_queue_entry_t") ends up renaming the
autofs_packet_missing, autofs_packet_expire_multi and autofs_v5_packet
member previously named wait_queue_entry to wait_queue_entry_token. Was
it intentional to force an user space build breakage when building
against v4.13-rc headers for autofs headers?

Thanks
-- 
Florian

Re: [GIT PULL] scheduler changes for v4.13

[Florian Fainelli]

On 07/03/2017 01:39 AM, Ingo Molnar wrote:
> Linus,
> 
> Please pull the latest sched-core-for-linus git tree from:
> 
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> sched-core-for-linus
> 
># HEAD: 72298e5c92c50edd8cb7cfda4519483ce65fa166 sched/cputime: Refactor 
> the cputime_adjust() code
> 
> The main changes in this cycle were:
> 
>  - Add the SYSTEM_SCHEDULING bootup state to move various scheduler debug 
> checks 
>earlier into the bootup. This turns silent and sporadically deadly bugs 
> into
>nice, deterministic splats. Fix some of the splats that triggered.
>(Thomas Gleixner)
> 
>  - A round of restructuring and refactoring of the load-balancing and 
> topology 
>code (Peter Zijlstra)
> 
>  - Another round of consolidating ~20 of incremental scheduler code history: 
> this 
>time in terms of wait-queue nomenclature. (I didn't get much feedback on 
> these 
>renaming patches, and we can still easily change any names I might have 
>misplaced, so if anyone hates a new name, please holler and I'll fix it.)
>(Ingo Molnar)

This commit ac6424b981bce1c4bc55675c6ce11bfe1bbfa64f ("sched/wait:
Rename wait_queue_t => wait_queue_entry_t") ends up renaming the
autofs_packet_missing, autofs_packet_expire_multi and autofs_v5_packet
member previously named wait_queue_entry to wait_queue_entry_token. Was
it intentional to force an user space build breakage when building
against v4.13-rc headers for autofs headers?

Thanks
-- 
Florian

[no subject]

[системы администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки ©2017

спасибо
системы администратор

[no subject]

[системы администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет 
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки ©2017

спасибо
системы администратор

Re: [PATCH v3 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX

[Rob Herring]

On Thu, Jul 06, 2017 at 02:20:21PM +0200, Pierre-Yves MORDRET wrote:
> This patch adds an optional property needed for STM32 DMA controller
> addressed via STM32 DMAMUX.
> 
> Signed-off-by: M'boumba Cedric Madianga 
> Signed-off-by: Pierre-Yves MORDRET 
> ---
>  Version history:
> v3:
> * None
> v2:
> * Typo fix
> ---
> ---
>  Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH v3 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX

[Rob Herring]

On Thu, Jul 06, 2017 at 02:20:21PM +0200, Pierre-Yves MORDRET wrote:
> This patch adds an optional property needed for STM32 DMA controller
> addressed via STM32 DMAMUX.
> 
> Signed-off-by: M'boumba Cedric Madianga 
> Signed-off-by: Pierre-Yves MORDRET 
> ---
>  Version history:
> v3:
> * None
> v2:
> * Typo fix
> ---
> ---
>  Documentation/devicetree/bindings/dma/stm32-dma.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

linux-next: manual merge of the rtc tree with Linus' tree

[Stephen Rothwell]

Hi Alexandre,

Today's linux-next merge of the rtc tree got a conflict in:

  tools/testing/selftests/timers/Makefile

between commit:

  767392565a3e ("kselftests: timers: Add test for frequency step")

from Linus' tree and commit:

  c96396f0780e ("tools: timer: add rtctest_setdate")

from the rtc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/timers/Makefile
index 5801bbefbe89,54481f17518a..
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@@ -8,8 -8,8 +8,8 @@@ TEST_GEN_PROGS = posix_timers nanoslee
 inconsistency-check raw_skew threadtest rtctest
  
  TEST_GEN_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex adjtick 
change_skew \
 -skew_consistency clocksource-switch leap-a-day \
 +skew_consistency clocksource-switch freq-step leap-a-day \
- leapcrash set-tai set-2038 set-tz
+ leapcrash set-tai set-2038 set-tz rtctest_setdate
  
  
  include ../lib.mk

linux-next: manual merge of the rtc tree with Linus' tree

[Stephen Rothwell]

Hi Alexandre,

Today's linux-next merge of the rtc tree got a conflict in:

  tools/testing/selftests/timers/Makefile

between commit:

  767392565a3e ("kselftests: timers: Add test for frequency step")

from Linus' tree and commit:

  c96396f0780e ("tools: timer: add rtctest_setdate")

from the rtc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/timers/Makefile
index 5801bbefbe89,54481f17518a..
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@@ -8,8 -8,8 +8,8 @@@ TEST_GEN_PROGS = posix_timers nanoslee
 inconsistency-check raw_skew threadtest rtctest
  
  TEST_GEN_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex adjtick 
change_skew \
 -skew_consistency clocksource-switch leap-a-day \
 +skew_consistency clocksource-switch freq-step leap-a-day \
- leapcrash set-tai set-2038 set-tz
+ leapcrash set-tai set-2038 set-tz rtctest_setdate
  
  
  include ../lib.mk

Re: [PATCH v3 1/5] dt-bindings: Document the STM32 DMAMUX bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 02:20:19PM +0200, Pierre-Yves MORDRET wrote:
> This patch adds the documentation of device tree bindings for the STM32
> DMAMUX.
> 
> Signed-off-by: M'boumba Cedric Madianga 
> Signed-off-by: Pierre-Yves MORDRET 
> ---
>  Version history:
> v3:
> * change compatible to st,stm32h7-dmamux to be mode Soc specific
> * add verbosity in dma-cells
> v2:
> * Move clock bindings from optional to mandatory one
> * Drop channelID bindings as managed dynamically from now on by
>   DMAMUX driver.
> ---
> ---
>  .../devicetree/bindings/dma/stm32-dmamux.txt   | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt

Acked-by: Rob Herring 

Re: [PATCH v3 1/5] dt-bindings: Document the STM32 DMAMUX bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 02:20:19PM +0200, Pierre-Yves MORDRET wrote:
> This patch adds the documentation of device tree bindings for the STM32
> DMAMUX.
> 
> Signed-off-by: M'boumba Cedric Madianga 
> Signed-off-by: Pierre-Yves MORDRET 
> ---
>  Version history:
> v3:
> * change compatible to st,stm32h7-dmamux to be mode Soc specific
> * add verbosity in dma-cells
> v2:
> * Move clock bindings from optional to mandatory one
> * Drop channelID bindings as managed dynamically from now on by
>   DMAMUX driver.
> ---
> ---
>  .../devicetree/bindings/dma/stm32-dmamux.txt   | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt

Acked-by: Rob Herring 

Re: [PATCH v7 1/3] media: adv748x: Add adv7481, adv7482 bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 12:01:15PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Create device tree bindings documentation for the ADV748x.
> The ADV748x supports both the ADV7481 and ADV7482 chips which
> provide analogue decoding and HDMI receiving capabilities
> 
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Laurent Pinchart 
> 
> ---
> v6:
>  - Clean up description and remove redundant text regarding optional
>nodes
> 
> v6.1:
>  - Fix commit title
> 
>  Documentation/devicetree/bindings/media/i2c/adv748x.txt | 95 ++-
>  1 file changed, 95 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt

Acked-by: Rob Herring 

Re: [PATCH v7 1/3] media: adv748x: Add adv7481, adv7482 bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 12:01:15PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Create device tree bindings documentation for the ADV748x.
> The ADV748x supports both the ADV7481 and ADV7482 chips which
> provide analogue decoding and HDMI receiving capabilities
> 
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Laurent Pinchart 
> 
> ---
> v6:
>  - Clean up description and remove redundant text regarding optional
>nodes
> 
> v6.1:
>  - Fix commit title
> 
>  Documentation/devicetree/bindings/media/i2c/adv748x.txt | 95 ++-
>  1 file changed, 95 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/adv748x.txt

Acked-by: Rob Herring 

Re: [PATCH 2/2] dt-bindings: media: Add Amlogic Meson AO-CEC bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 12:27:50PM +0200, Neil Armstrong wrote:
> The Amlogic SoCs embeds a standalone CEC Controller, this patch adds this
> device bindings.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/media/meson-ao-cec.txt | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/meson-ao-cec.txt

Acked-by: Rob Herring 

Re: [PATCH 2/2] dt-bindings: media: Add Amlogic Meson AO-CEC bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 12:27:50PM +0200, Neil Armstrong wrote:
> The Amlogic SoCs embeds a standalone CEC Controller, this patch adds this
> device bindings.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/media/meson-ao-cec.txt | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/meson-ao-cec.txt

Acked-by: Rob Herring 

Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 12:24:23PM +0200, Neil Armstrong wrote:
> On the first revision of the bindings, only the gates + resets were known
> in the AO Clock HW, but more registers used to configures AO clock are known
> to be spread among the AO register space.
> This patch adds these registers to the Ao Clock bindings with direct access
> and shared extcon access.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt | 11 
> +--
>  1 file changed, 9 insertions(+), 2 deletions(-)

This looks like the binding might be too specific with a reg list of 
single registers, and you should define a system controller node 
instead. Depends on what else is in the "A0" block.

Acked-by: Rob Herring 

Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 12:24:23PM +0200, Neil Armstrong wrote:
> On the first revision of the bindings, only the gates + resets were known
> in the AO Clock HW, but more registers used to configures AO clock are known
> to be spread among the AO register space.
> This patch adds these registers to the Ao Clock bindings with direct access
> and shared extcon access.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt | 11 
> +--
>  1 file changed, 9 insertions(+), 2 deletions(-)

This looks like the binding might be too specific with a reg list of 
single registers, and you should define a system controller node 
instead. Depends on what else is in the "A0" block.

Acked-by: Rob Herring 

Re: [PATCH 3/3] dt-bindings: i2c: eeprom: document "mac-offset" binding

[Rob Herring]

On Thu, Jul 06, 2017 at 01:16:57PM +0300, Claudiu Beznea wrote:
> Document "mac-offset" binding that will be used by at24 EEPROM driver.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> index a50dc01..3dd267c 100644
> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -35,10 +35,13 @@ Optional properties:
>  
>- read-only: this parameterless property disables writes to the eeprom
>  
> +  - mac-offset: offset in EEPROM where MAC address starts
> +

This doesn't scale if you have multiple things you need the offset to, 
and we already have a binding for this. Use the nvmem binding.

Rob

Re: [PATCH 3/3] dt-bindings: i2c: eeprom: document "mac-offset" binding

[Rob Herring]

On Thu, Jul 06, 2017 at 01:16:57PM +0300, Claudiu Beznea wrote:
> Document "mac-offset" binding that will be used by at24 EEPROM driver.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> index a50dc01..3dd267c 100644
> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -35,10 +35,13 @@ Optional properties:
>  
>- read-only: this parameterless property disables writes to the eeprom
>  
> +  - mac-offset: offset in EEPROM where MAC address starts
> +

This doesn't scale if you have multiple things you need the offset to, 
and we already have a binding for this. Use the nvmem binding.

Rob

Re: [PATCH 1/3] dt-bindings: i2c: eeprom: document all at24 bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 01:16:55PM +0300, Claudiu Beznea wrote:
> Document all at24 memories specific bindings.

This will probably conflict with Javier's series "eeprom: at24: Add OF 
device ID table".

Rob

Re: [PATCH 1/3] dt-bindings: i2c: eeprom: document all at24 bindings

[Rob Herring]

On Thu, Jul 06, 2017 at 01:16:55PM +0300, Claudiu Beznea wrote:
> Document all at24 memories specific bindings.

This will probably conflict with Javier's series "eeprom: at24: Add OF 
device ID table".

Rob

Re: [PATCH V4 6/6] iommu/arm-smmu: Add support for qcom,msm8996-smmu-v2 clocks

[Rob Herring]

On Thu, Jul 06, 2017 at 03:07:05PM +0530, Vivek Gautam wrote:
> qcom,msm8996-smmu-v2 is an arm,smmu-v2 implementation with
> specific clock and power requirements. This smmu core is used
> with multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
> 
> Signed-off-by: Vivek Gautam 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 18 ++
>  drivers/iommu/arm-smmu.c | 13 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 00331752d355..5d8e79775fae 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -17,6 +17,7 @@ conditions.
>  "arm,mmu-401"
>  "arm,mmu-500"
>  "cavium,smmu-v2"
> +"qcom,msm8996-smmu-v2"
>  
>depending on the particular implementation and/or the
>version of the architecture implemented.
> @@ -74,11 +75,16 @@ conditions.
>  - clock-names:Should be "tcu" and "iface" for "arm,mmu-400",
>"arm,mmu-401" and "arm,mmu-500"
>  
> +  Should be "bus", and "iface" for "qcom,msm8996-smmu-v2"
> +  implementation.
> +
>"tcu" clock is required for smmu's register access using 
> the
>programming interface and ptw for downstream bus access. 
> This
>clock is also used for access to the TBU connected to the
>master locally. Sometimes however, TBU is clocked along 
> with
>the master.
> +  "bus" clock for "qcom,msm8996-smmu-v2" is requierd for 
> downstream

s/requierd/required/

> +  bus access and for the smmu ptw.
>  
>"iface" clock is required to access the TCU's programming
>interface, apart from the "tcu" clock.
> @@ -161,3 +167,15 @@ conditions.
>  iommu-map = <0  0 0x400>;
>  ...
>  };
> +
> + /* Qcom's arm,smmu-v2 implementation for msm8996 */
> + smmu4: iommu {
> + compatible = "qcom,msm8996-smmu-v2";

No registers?

> + ...
> + #iommu-cells = <1>;
> + power-domains = < MDSS_GDSC>;
> +
> + clocks = < SMMU_MDP_AXI_CLK>,
> +  < SMMU_MDP_AHB_CLK>;
> + clock-names = "bus", "iface";
> + };

Re: [PATCH V4 6/6] iommu/arm-smmu: Add support for qcom,msm8996-smmu-v2 clocks

[Rob Herring]

On Thu, Jul 06, 2017 at 03:07:05PM +0530, Vivek Gautam wrote:
> qcom,msm8996-smmu-v2 is an arm,smmu-v2 implementation with
> specific clock and power requirements. This smmu core is used
> with multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
> 
> Signed-off-by: Vivek Gautam 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 18 ++
>  drivers/iommu/arm-smmu.c | 13 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 00331752d355..5d8e79775fae 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -17,6 +17,7 @@ conditions.
>  "arm,mmu-401"
>  "arm,mmu-500"
>  "cavium,smmu-v2"
> +"qcom,msm8996-smmu-v2"
>  
>depending on the particular implementation and/or the
>version of the architecture implemented.
> @@ -74,11 +75,16 @@ conditions.
>  - clock-names:Should be "tcu" and "iface" for "arm,mmu-400",
>"arm,mmu-401" and "arm,mmu-500"
>  
> +  Should be "bus", and "iface" for "qcom,msm8996-smmu-v2"
> +  implementation.
> +
>"tcu" clock is required for smmu's register access using 
> the
>programming interface and ptw for downstream bus access. 
> This
>clock is also used for access to the TBU connected to the
>master locally. Sometimes however, TBU is clocked along 
> with
>the master.
> +  "bus" clock for "qcom,msm8996-smmu-v2" is requierd for 
> downstream

s/requierd/required/

> +  bus access and for the smmu ptw.
>  
>"iface" clock is required to access the TCU's programming
>interface, apart from the "tcu" clock.
> @@ -161,3 +167,15 @@ conditions.
>  iommu-map = <0  0 0x400>;
>  ...
>  };
> +
> + /* Qcom's arm,smmu-v2 implementation for msm8996 */
> + smmu4: iommu {
> + compatible = "qcom,msm8996-smmu-v2";

No registers?

> + ...
> + #iommu-cells = <1>;
> + power-domains = < MDSS_GDSC>;
> +
> + clocks = < SMMU_MDP_AXI_CLK>,
> +  < SMMU_MDP_AHB_CLK>;
> + clock-names = "bus", "iface";
> + };

Re: [lkp-robot] [EDAC] 5729ee3edf: kmsg.EDAC_sbridge:Failed_to_register_device_with_error

[Borislav Petkov]

On Mon, Jul 10, 2017 at 10:42:17AM +0800, kernel test robot wrote:
> commit: 5729ee3edf50e4627ab216a170a4748a2d62dd12 ("EDAC: Remove EDAC_MM_EDAC")
> https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git edac-for-4.12-stub

So this is an old branch, lemme kill it.

> in testcase: unixbench
> with following parameters:
> 
>   runtime: 300s
>   nr_task: 1
>   test: pipe
>   cpufreq_governor: performance
> 
> test-description: UnixBench is the original BYTE UNIX benchmark suite aims to 
> test performance of Unix-like system.
> test-url: https://github.com/kdlucas/byte-unixbench
> 
> 
> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 
> 64G memory
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> 
> kern  :err   : [   32.919091] EDAC sbridge: Couldn't find mci handler
> kern  :err   : [   32.919092] EDAC sbridge: Couldn't find mci handler
> kern  :err   : [   32.919095] EDAC sbridge: Failed to register device with 
> error -22.

AFAIR, we talked about this already. You need to disable CONFIG_EDAC_GHES
temporarily as it registers before the sbridge module.

kern  :info  : [   26.382523] ghes_edac: This EDAC driver relies on BIOS to 
enumerate memory and get error reports.
kern  :info  : [   26.392439] ghes_edac: Unfortunately, not all BIOSes reflect 
the memory layout correctly.
kern  :info  : [   26.401574] ghes_edac: So, the end result of using this 
driver varies from vendor to vendor.
kern  :info  : [   26.411001] ghes_edac: If you find incorrect reports, please 
contact your hardware vendor
kern  :info  : [   26.420137] ghes_edac: to correct its BIOS.
kern  :info  : [   26.424812] ghes_edac: This system has 8 DIMM sockets.
kern  :info  : [   26.430737] EDAC MC0: Giving out device to module ghes_edac.c 
controller ghes_edac: DEV ghes (INTERRUPT)
kern  :info  : [   26.441401] EDAC MC1: Giving out device to module ghes_edac.c 
controller ghes_edac: DEV ghes (INTERRUPT)
kern  :info  : [   26.452619] GHES: APEI firmware first mode is enabled by APEI 
bit and WHEA _OSC.

We're working on fixing this properly but the fix is not ready yet.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [lkp-robot] [EDAC] 5729ee3edf: kmsg.EDAC_sbridge:Failed_to_register_device_with_error

[Borislav Petkov]

On Mon, Jul 10, 2017 at 10:42:17AM +0800, kernel test robot wrote:
> commit: 5729ee3edf50e4627ab216a170a4748a2d62dd12 ("EDAC: Remove EDAC_MM_EDAC")
> https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git edac-for-4.12-stub

So this is an old branch, lemme kill it.

> in testcase: unixbench
> with following parameters:
> 
>   runtime: 300s
>   nr_task: 1
>   test: pipe
>   cpufreq_governor: performance
> 
> test-description: UnixBench is the original BYTE UNIX benchmark suite aims to 
> test performance of Unix-like system.
> test-url: https://github.com/kdlucas/byte-unixbench
> 
> 
> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 
> 64G memory
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> 
> kern  :err   : [   32.919091] EDAC sbridge: Couldn't find mci handler
> kern  :err   : [   32.919092] EDAC sbridge: Couldn't find mci handler
> kern  :err   : [   32.919095] EDAC sbridge: Failed to register device with 
> error -22.

AFAIR, we talked about this already. You need to disable CONFIG_EDAC_GHES
temporarily as it registers before the sbridge module.

kern  :info  : [   26.382523] ghes_edac: This EDAC driver relies on BIOS to 
enumerate memory and get error reports.
kern  :info  : [   26.392439] ghes_edac: Unfortunately, not all BIOSes reflect 
the memory layout correctly.
kern  :info  : [   26.401574] ghes_edac: So, the end result of using this 
driver varies from vendor to vendor.
kern  :info  : [   26.411001] ghes_edac: If you find incorrect reports, please 
contact your hardware vendor
kern  :info  : [   26.420137] ghes_edac: to correct its BIOS.
kern  :info  : [   26.424812] ghes_edac: This system has 8 DIMM sockets.
kern  :info  : [   26.430737] EDAC MC0: Giving out device to module ghes_edac.c 
controller ghes_edac: DEV ghes (INTERRUPT)
kern  :info  : [   26.441401] EDAC MC1: Giving out device to module ghes_edac.c 
controller ghes_edac: DEV ghes (INTERRUPT)
kern  :info  : [   26.452619] GHES: APEI firmware first mode is enabled by APEI 
bit and WHEA _OSC.

We're working on fixing this properly but the fix is not ready yet.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH V4 5/6] iommu/arm-smmu: Add support for MMU40x/500 clocks

[Rob Herring]

On Thu, Jul 06, 2017 at 03:07:04PM +0530, Vivek Gautam wrote:
> From: Sricharan R 
> 
> The MMU400x/500 is the implementation of the SMMUv2
> arch specification. It is split in to two blocks
> TBU, TCU. TBU caches the page table, instantiated
> for each master locally, clocked by the TBUn_clk.
> TCU manages the address translation with PTW and has
> the programming interface as well, clocked using the
> TCU_CLK. The TBU can also be sharing the same clock
> domain as TCU, in which case both are clocked using
> the TCU_CLK.

No TBU clock below. When is it shared or not? If that's an integration 
option then the binding should always have a TBU clock with the same 
parent as the TCU_CLK.

> This defines the clock bindings for the same and adds
> the clock names to compatible data.
> 
> Signed-off-by: Sricharan R 
> [vivek: clock rework and cleanup]
> Signed-off-by: Vivek Gautam 
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 24 
> ++
>  drivers/iommu/arm-smmu.c   | 12 ++-
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 8a6ffce12af5..00331752d355 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -71,6 +71,26 @@ conditions.
>or using stream matching with #iommu-cells = <2>, and
>may be ignored if present in such cases.
>  
> +- clock-names:Should be "tcu" and "iface" for "arm,mmu-400",
> +  "arm,mmu-401" and "arm,mmu-500"
> +
> +  "tcu" clock is required for smmu's register access using 
> the
> +  programming interface and ptw for downstream bus access. 
> This
> +  clock is also used for access to the TBU connected to the
> +  master locally. Sometimes however, TBU is clocked along 
> with
> +  the master.
> +
> +  "iface" clock is required to access the TCU's programming
> +  interface, apart from the "tcu" clock.
> +
> +- clocks: Phandles for respective clocks described by clock-names.
> +
> +- power-domains:  Phandles to SMMU's power domain specifier. This is
> +  required even if SMMU belongs to the master's power
> +  domain, as the SMMU will have to be enabled and
> +  accessed before master gets enabled and linked to its
> +  SMMU.
> +
>  ** Deprecated properties:
>  
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> @@ -95,6 +115,10 @@ conditions.
>   <0 36 4>,
>   <0 37 4>;
>  #iommu-cells = <1>;
> +clocks = < GCC_SMMU_CFG_CLK>,
> + < GCC_APSS_TCU_CLK>;
> +
> + clock-names = "iface", "tcu";
>  };
>  
>  /* device with two stream IDs, 0 and 7 */
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 75567d9698ab..7bb09280fa11 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1947,9 +1947,19 @@ struct arm_smmu_match_data {
>  ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
>  ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
>  ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU);
> -ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
>  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
>  
> +static const char * const arm_mmu500_clks[] = {
> + "tcu", "iface",
> +};
> +
> +static const struct arm_smmu_match_data arm_mmu500 = {
> + .version = ARM_SMMU_V2,
> + .model = ARM_MMU500,
> + .clks = arm_mmu500_clks,
> + .num_clks = ARRAY_SIZE(arm_mmu500_clks),
> +};
> +
>  static const struct of_device_id arm_smmu_of_match[] = {
>   { .compatible = "arm,smmu-v1", .data = _generic_v1 },
>   { .compatible = "arm,smmu-v2", .data = _generic_v2 },
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH V4 5/6] iommu/arm-smmu: Add support for MMU40x/500 clocks

[Rob Herring]

On Thu, Jul 06, 2017 at 03:07:04PM +0530, Vivek Gautam wrote:
> From: Sricharan R 
> 
> The MMU400x/500 is the implementation of the SMMUv2
> arch specification. It is split in to two blocks
> TBU, TCU. TBU caches the page table, instantiated
> for each master locally, clocked by the TBUn_clk.
> TCU manages the address translation with PTW and has
> the programming interface as well, clocked using the
> TCU_CLK. The TBU can also be sharing the same clock
> domain as TCU, in which case both are clocked using
> the TCU_CLK.

No TBU clock below. When is it shared or not? If that's an integration 
option then the binding should always have a TBU clock with the same 
parent as the TCU_CLK.

> This defines the clock bindings for the same and adds
> the clock names to compatible data.
> 
> Signed-off-by: Sricharan R 
> [vivek: clock rework and cleanup]
> Signed-off-by: Vivek Gautam 
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt | 24 
> ++
>  drivers/iommu/arm-smmu.c   | 12 ++-
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 8a6ffce12af5..00331752d355 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -71,6 +71,26 @@ conditions.
>or using stream matching with #iommu-cells = <2>, and
>may be ignored if present in such cases.
>  
> +- clock-names:Should be "tcu" and "iface" for "arm,mmu-400",
> +  "arm,mmu-401" and "arm,mmu-500"
> +
> +  "tcu" clock is required for smmu's register access using 
> the
> +  programming interface and ptw for downstream bus access. 
> This
> +  clock is also used for access to the TBU connected to the
> +  master locally. Sometimes however, TBU is clocked along 
> with
> +  the master.
> +
> +  "iface" clock is required to access the TCU's programming
> +  interface, apart from the "tcu" clock.
> +
> +- clocks: Phandles for respective clocks described by clock-names.
> +
> +- power-domains:  Phandles to SMMU's power domain specifier. This is
> +  required even if SMMU belongs to the master's power
> +  domain, as the SMMU will have to be enabled and
> +  accessed before master gets enabled and linked to its
> +  SMMU.
> +
>  ** Deprecated properties:
>  
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> @@ -95,6 +115,10 @@ conditions.
>   <0 36 4>,
>   <0 37 4>;
>  #iommu-cells = <1>;
> +clocks = < GCC_SMMU_CFG_CLK>,
> + < GCC_APSS_TCU_CLK>;
> +
> + clock-names = "iface", "tcu";
>  };
>  
>  /* device with two stream IDs, 0 and 7 */
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 75567d9698ab..7bb09280fa11 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1947,9 +1947,19 @@ struct arm_smmu_match_data {
>  ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
>  ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
>  ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU);
> -ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
>  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
>  
> +static const char * const arm_mmu500_clks[] = {
> + "tcu", "iface",
> +};
> +
> +static const struct arm_smmu_match_data arm_mmu500 = {
> + .version = ARM_SMMU_V2,
> + .model = ARM_MMU500,
> + .clks = arm_mmu500_clks,
> + .num_clks = ARRAY_SIZE(arm_mmu500_clks),
> +};
> +
>  static const struct of_device_id arm_smmu_of_match[] = {
>   { .compatible = "arm,smmu-v1", .data = _generic_v1 },
>   { .compatible = "arm,smmu-v2", .data = _generic_v2 },
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

[PATCH] usb: gadget: fusb300_udc: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable declaration
and assignment.

These issues were detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/gadget/udc/fusb300_udc.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index e0c1b00..8738f03 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -659,22 +659,16 @@ static void fusb300_rdfifo(struct fusb300_ep *ep,
 
 static u8 fusb300_get_epnstall(struct fusb300 *fusb300, u8 ep)
 {
-   u8 value;
u32 reg = ioread32(fusb300->reg + FUSB300_OFFSET_EPSET0(ep));
 
-   value = reg & FUSB300_EPSET0_STL;
-
-   return value;
+   return reg & FUSB300_EPSET0_STL;
 }
 
 static u8 fusb300_get_cxstall(struct fusb300 *fusb300)
 {
-   u8 value;
u32 reg = ioread32(fusb300->reg + FUSB300_OFFSET_CSR);
 
-   value = (reg & FUSB300_CSR_STL) >> 1;
-
-   return value;
+   return (reg & FUSB300_CSR_STL) >> 1;
 }
 
 static void request_error(struct fusb300 *fusb300)
-- 
2.5.0

[PATCH] usb: gadget: fusb300_udc: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable declaration
and assignment.

These issues were detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/gadget/udc/fusb300_udc.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/udc/fusb300_udc.c 
b/drivers/usb/gadget/udc/fusb300_udc.c
index e0c1b00..8738f03 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -659,22 +659,16 @@ static void fusb300_rdfifo(struct fusb300_ep *ep,
 
 static u8 fusb300_get_epnstall(struct fusb300 *fusb300, u8 ep)
 {
-   u8 value;
u32 reg = ioread32(fusb300->reg + FUSB300_OFFSET_EPSET0(ep));
 
-   value = reg & FUSB300_EPSET0_STL;
-
-   return value;
+   return reg & FUSB300_EPSET0_STL;
 }
 
 static u8 fusb300_get_cxstall(struct fusb300 *fusb300)
 {
-   u8 value;
u32 reg = ioread32(fusb300->reg + FUSB300_OFFSET_CSR);
 
-   value = (reg & FUSB300_CSR_STL) >> 1;
-
-   return value;
+   return (reg & FUSB300_CSR_STL) >> 1;
 }
 
 static void request_error(struct fusb300 *fusb300)
-- 
2.5.0

[PATCH] usb: misc: sisusbvga: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable declaration
and assignment.

These issues were detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index 440d7fe..30774e0 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -610,13 +610,11 @@ static int sisusb_write_memio_byte(struct sisusb_usb_data 
*sisusb, int type,
u32 addr, u8 data)
 {
struct sisusb_packet packet;
-   int ret;
 
packet.header  = (1 << (addr & 3)) | (type << 6);
packet.address = addr & ~3;
packet.data= data << ((addr & 3) << 3);
-   ret = sisusb_send_packet(sisusb, 10, );
-   return ret;
+   return sisusb_send_packet(sisusb, 10, );
 }
 
 static int sisusb_write_memio_word(struct sisusb_usb_data *sisusb, int type,
@@ -1333,13 +1331,11 @@ static int sisusb_write_pci_config(struct 
sisusb_usb_data *sisusb,
int regnum, u32 data)
 {
struct sisusb_packet packet;
-   int ret;
 
packet.header = 0x008f;
packet.address = regnum | 0x1;
packet.data = data;
-   ret = sisusb_send_packet(sisusb, 10, );
-   return ret;
+   return sisusb_send_packet(sisusb, 10, );
 }
 
 static int sisusb_read_pci_config(struct sisusb_usb_data *sisusb,
@@ -2982,14 +2978,11 @@ static long sisusb_ioctl(struct file *file, unsigned 
int cmd, unsigned long arg)
 static long sisusb_compat_ioctl(struct file *f, unsigned int cmd,
unsigned long arg)
 {
-   long retval;
-
switch (cmd) {
case SISUSB_GET_CONFIG_SIZE:
case SISUSB_GET_CONFIG:
case SISUSB_COMMAND:
-   retval = sisusb_ioctl(f, cmd, arg);
-   return retval;
+   return sisusb_ioctl(f, cmd, arg);
 
default:
return -ENOIOCTLCMD;
-- 
2.5.0

[PATCH] usb: misc: sisusbvga: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable declaration
and assignment.

These issues were detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index 440d7fe..30774e0 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -610,13 +610,11 @@ static int sisusb_write_memio_byte(struct sisusb_usb_data 
*sisusb, int type,
u32 addr, u8 data)
 {
struct sisusb_packet packet;
-   int ret;
 
packet.header  = (1 << (addr & 3)) | (type << 6);
packet.address = addr & ~3;
packet.data= data << ((addr & 3) << 3);
-   ret = sisusb_send_packet(sisusb, 10, );
-   return ret;
+   return sisusb_send_packet(sisusb, 10, );
 }
 
 static int sisusb_write_memio_word(struct sisusb_usb_data *sisusb, int type,
@@ -1333,13 +1331,11 @@ static int sisusb_write_pci_config(struct 
sisusb_usb_data *sisusb,
int regnum, u32 data)
 {
struct sisusb_packet packet;
-   int ret;
 
packet.header = 0x008f;
packet.address = regnum | 0x1;
packet.data = data;
-   ret = sisusb_send_packet(sisusb, 10, );
-   return ret;
+   return sisusb_send_packet(sisusb, 10, );
 }
 
 static int sisusb_read_pci_config(struct sisusb_usb_data *sisusb,
@@ -2982,14 +2978,11 @@ static long sisusb_ioctl(struct file *file, unsigned 
int cmd, unsigned long arg)
 static long sisusb_compat_ioctl(struct file *f, unsigned int cmd,
unsigned long arg)
 {
-   long retval;
-
switch (cmd) {
case SISUSB_GET_CONFIG_SIZE:
case SISUSB_GET_CONFIG:
case SISUSB_COMMAND:
-   retval = sisusb_ioctl(f, cmd, arg);
-   return retval;
+   return sisusb_ioctl(f, cmd, arg);
 
default:
return -ENOIOCTLCMD;
-- 
2.5.0

linux-next: please clean up the clockevents tree

[Stephen Rothwell]

Hi Daniel,

Please clean up the clockevents tree
(git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next)
as all its commits have been merged into other tree(s) as different
commits (so all it is doing is adding lots of conflicts :-().

-- 
Cheers,
Stephen Rothwell

linux-next: please clean up the clockevents tree

[Stephen Rothwell]

Hi Daniel,

Please clean up the clockevents tree
(git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next)
as all its commits have been merged into other tree(s) as different
commits (so all it is doing is adding lots of conflicts :-().

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the spi tree

[Stephen Rothwell]

Hi Mark,

After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/spi/spi-imx.c: In function 'spi_imx_setupxfer':
drivers/spi/spi-imx.c:1007:16: error: 'config' undeclared (first use in this 
function)
   mask = (1 << config.bpw) - 1;
^

Caused by commit

  a0cc330240c9 ("spi: imx: dynamic burst length adjust for PIO mode")

interacting with commit

  d52345b6cf8e ("spi: imx: put struct spi_imx_config members into driver 
private struct")

from Linus' tree.

I am not sure why this has only shown up now.

Since it is the only thing left in the spi tree, I have just dropped
that tree for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the spi tree

[Stephen Rothwell]

Hi Mark,

After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/spi/spi-imx.c: In function 'spi_imx_setupxfer':
drivers/spi/spi-imx.c:1007:16: error: 'config' undeclared (first use in this 
function)
   mask = (1 << config.bpw) - 1;
^

Caused by commit

  a0cc330240c9 ("spi: imx: dynamic burst length adjust for PIO mode")

interacting with commit

  d52345b6cf8e ("spi: imx: put struct spi_imx_config members into driver 
private struct")

from Linus' tree.

I am not sure why this has only shown up now.

Since it is the only thing left in the spi tree, I have just dropped
that tree for today.

-- 
Cheers,
Stephen Rothwell

[PATCH] usb: gadget: udc-xilinx: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable assignment.

This issue was detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/gadget/udc/udc-xilinx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
b/drivers/usb/gadget/udc/udc-xilinx.c
index de207a9..552389d 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -1217,14 +1217,13 @@ static const struct usb_ep_ops xusb_ep_ops = {
 static int xudc_get_frame(struct usb_gadget *gadget)
 {
struct xusb_udc *udc;
-   int frame;
 
if (!gadget)
return -ENODEV;
 
udc = to_udc(gadget);
-   frame = udc->read_fn(udc->addr + XUSB_FRAMENUM_OFFSET);
-   return frame;
+
+   return udc->read_fn(udc->addr + XUSB_FRAMENUM_OFFSET);
 }
 
 /**
-- 
2.5.0

[PATCH] usb: gadget: udc-xilinx: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable assignment.

This issue was detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/gadget/udc/udc-xilinx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
b/drivers/usb/gadget/udc/udc-xilinx.c
index de207a9..552389d 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -1217,14 +1217,13 @@ static const struct usb_ep_ops xusb_ep_ops = {
 static int xudc_get_frame(struct usb_gadget *gadget)
 {
struct xusb_udc *udc;
-   int frame;
 
if (!gadget)
return -ENODEV;
 
udc = to_udc(gadget);
-   frame = udc->read_fn(udc->addr + XUSB_FRAMENUM_OFFSET);
-   return frame;
+
+   return udc->read_fn(udc->addr + XUSB_FRAMENUM_OFFSET);
 }
 
 /**
-- 
2.5.0

[RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

[Gary Lin]

A new section, secdata, in the setup header is introduced to store the
distro-specific security version which is designed to help the
bootloader to warn the user when loading a less secure or vulnerable
kernel. The secdata section can be presented as the following:

struct sec_hdr {
__u16 header_length;
__u32 distro_version;
__u16 security_version;
} __attribute__((packed));
char *signer;

It consists of a fixed size structure and a null-terminated string.
"header_length" is the size of "struct sec_hdr" and can be used as the
offset to "signer". It also can be a kind of the "header version" to
detect if any new member is introduced.

The kernel packager of the distribution can put the distro name in
"signer" and the distro version in "distro_version". When a severe
vulnerability is fixed, the packager increases "security_version" in
the kernel build afterward. The bootloader can maintain a list of the
security versions of the current kernels and only allows the kernel with
a higher or equal security version to boot. If the user is going to boot
a kernel with a lower security version, a warning should show to prevent
the user from loading a vulnerable kernel accidentally.

Enabling UEFI Secure Boot is recommended when using the security version
or the attacker may alter the security version stealthily.

(For more details: https://github.com/lcp/shim/wiki/Security-Version)

v2:
- Decrease the size of secdata_offset to 2 bytes since the setup header
  is limited to around 32KB.
- Restructure the secdata section. The signer is now a null-terminated
  string. The type of distro_version changes to u32 in case the distro
  uses a long version.
- Modify the Kconfig names and add help.
- Remove the signer name hack in build.c.

Cc: Ard Biesheuvel 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Joey Lee 
Signed-off-by: Gary Lin 
---
 arch/x86/Kconfig  | 28 
 arch/x86/boot/header.S| 14 +-
 arch/x86/boot/setup.ld|  1 +
 arch/x86/boot/tools/build.c   |  1 -
 arch/x86/include/uapi/asm/bootparam.h |  1 +
 5 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 316152f72bb9..043ff86828a6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1828,6 +1828,34 @@ config EFI_MIXED
 
   If unsure, say N.
 
+config SIGNER_NAME
+   string "Signer name"
+   default ""
+   ---help---
+  This option specifies who signs or releases this kernel.
+
+config DISTRO_VERSION
+   int "Distribution version"
+   default 0
+   range 0 4294967295
+   ---help---
+ This option specifies the distribution version which this
+ kernel belongs to.
+
+config SECURITY_VERSION
+   int "Security version"
+   default 0
+   range 0 65535
+   ---help---
+  The security version is the version defined by the distribution
+  to indicate the severe security fixes. The bootloader can maintain
+  a list of the security versions of the current kernels. After
+  fixing a severe vulnerability in the kernel, the distribution can
+  increase the security version to notify the bootloader to update
+  the list. When booting a kernel with a lower security version,
+  the bootloader warns the user to avoid loading a vulnerable kernel
+  accidentally.
+
 config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 2ed8f0c25def..c62e0baf2d89 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -300,7 +300,7 @@ _start:
# Part 2 of the header, from the old setup.S
 
.ascii  "HdrS"  # header signature
-   .word   0x020d  # header version number (>= 0x0105)
+   .word   0x020e  # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
 realmode_swtch:.word   0, 0# default_switch, SETUPSEG
@@ -551,6 +551,7 @@ pref_address:   .quad LOAD_PHYSICAL_ADDR
# preferred load addr
 
 init_size: .long INIT_SIZE # kernel initialization size
 handover_offset:   .long 0 # Filled in by build.c
+secdata_offset:.word secdata_start
 
 # End of setup header #
 
@@ -628,3 +629,14 @@ die:
 setup_corrupt:
.byte   7
.string "No setup signature found...\n"
+
+   .section ".secdata", "a"
+secdata_start:
+header_length:
+   .word   signer - secdata_start
+distro_version:
+   .long   CONFIG_DISTRO_VERSION

[RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

[Gary Lin]

A new section, secdata, in the setup header is introduced to store the
distro-specific security version which is designed to help the
bootloader to warn the user when loading a less secure or vulnerable
kernel. The secdata section can be presented as the following:

struct sec_hdr {
__u16 header_length;
__u32 distro_version;
__u16 security_version;
} __attribute__((packed));
char *signer;

It consists of a fixed size structure and a null-terminated string.
"header_length" is the size of "struct sec_hdr" and can be used as the
offset to "signer". It also can be a kind of the "header version" to
detect if any new member is introduced.

The kernel packager of the distribution can put the distro name in
"signer" and the distro version in "distro_version". When a severe
vulnerability is fixed, the packager increases "security_version" in
the kernel build afterward. The bootloader can maintain a list of the
security versions of the current kernels and only allows the kernel with
a higher or equal security version to boot. If the user is going to boot
a kernel with a lower security version, a warning should show to prevent
the user from loading a vulnerable kernel accidentally.

Enabling UEFI Secure Boot is recommended when using the security version
or the attacker may alter the security version stealthily.

(For more details: https://github.com/lcp/shim/wiki/Security-Version)

v2:
- Decrease the size of secdata_offset to 2 bytes since the setup header
  is limited to around 32KB.
- Restructure the secdata section. The signer is now a null-terminated
  string. The type of distro_version changes to u32 in case the distro
  uses a long version.
- Modify the Kconfig names and add help.
- Remove the signer name hack in build.c.

Cc: Ard Biesheuvel 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Joey Lee 
Signed-off-by: Gary Lin 
---
 arch/x86/Kconfig  | 28 
 arch/x86/boot/header.S| 14 +-
 arch/x86/boot/setup.ld|  1 +
 arch/x86/boot/tools/build.c   |  1 -
 arch/x86/include/uapi/asm/bootparam.h |  1 +
 5 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 316152f72bb9..043ff86828a6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1828,6 +1828,34 @@ config EFI_MIXED
 
   If unsure, say N.
 
+config SIGNER_NAME
+   string "Signer name"
+   default ""
+   ---help---
+  This option specifies who signs or releases this kernel.
+
+config DISTRO_VERSION
+   int "Distribution version"
+   default 0
+   range 0 4294967295
+   ---help---
+ This option specifies the distribution version which this
+ kernel belongs to.
+
+config SECURITY_VERSION
+   int "Security version"
+   default 0
+   range 0 65535
+   ---help---
+  The security version is the version defined by the distribution
+  to indicate the severe security fixes. The bootloader can maintain
+  a list of the security versions of the current kernels. After
+  fixing a severe vulnerability in the kernel, the distribution can
+  increase the security version to notify the bootloader to update
+  the list. When booting a kernel with a lower security version,
+  the bootloader warns the user to avoid loading a vulnerable kernel
+  accidentally.
+
 config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 2ed8f0c25def..c62e0baf2d89 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -300,7 +300,7 @@ _start:
# Part 2 of the header, from the old setup.S
 
.ascii  "HdrS"  # header signature
-   .word   0x020d  # header version number (>= 0x0105)
+   .word   0x020e  # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
 realmode_swtch:.word   0, 0# default_switch, SETUPSEG
@@ -551,6 +551,7 @@ pref_address:   .quad LOAD_PHYSICAL_ADDR
# preferred load addr
 
 init_size: .long INIT_SIZE # kernel initialization size
 handover_offset:   .long 0 # Filled in by build.c
+secdata_offset:.word secdata_start
 
 # End of setup header #
 
@@ -628,3 +629,14 @@ die:
 setup_corrupt:
.byte   7
.string "No setup signature found...\n"
+
+   .section ".secdata", "a"
+secdata_start:
+header_length:
+   .word   signer - secdata_start
+distro_version:
+   .long   CONFIG_DISTRO_VERSION
+security_version:
+   .word   CONFIG_SECURITY_VERSION
+signer:
+   .string CONFIG_SIGNER_NAME
diff --git 

[PATCH] usb: misc: ftdi-elan: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable declaration
and assignment.

This issue was detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/misc/ftdi-elan.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 8291499..c45904f 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -305,9 +305,9 @@ static int ftdi_elan_command_engine(struct usb_ftdi *ftdi);
 static int ftdi_elan_respond_engine(struct usb_ftdi *ftdi);
 static int ftdi_elan_hcd_init(struct usb_ftdi *ftdi)
 {
-   int result;
if (ftdi->platform_dev.dev.parent)
return -EBUSY;
+
ftdi_elan_get_kref(ftdi);
ftdi->platform_data.potpg = 100;
ftdi->platform_data.reset = NULL;
@@ -324,8 +324,8 @@ static int ftdi_elan_hcd_init(struct usb_ftdi *ftdi)
request_module("u132_hcd");
dev_info(>udev->dev, "registering '%s'\n",
 ftdi->platform_dev.name);
-   result = platform_device_register(>platform_dev);
-   return result;
+
+   return platform_device_register(>platform_dev);
 }
 
 static void ftdi_elan_abandon_completions(struct usb_ftdi *ftdi)
-- 
2.5.0

[PATCH] usb: misc: ftdi-elan: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable declaration
and assignment.

This issue was detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/misc/ftdi-elan.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 8291499..c45904f 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -305,9 +305,9 @@ static int ftdi_elan_command_engine(struct usb_ftdi *ftdi);
 static int ftdi_elan_respond_engine(struct usb_ftdi *ftdi);
 static int ftdi_elan_hcd_init(struct usb_ftdi *ftdi)
 {
-   int result;
if (ftdi->platform_dev.dev.parent)
return -EBUSY;
+
ftdi_elan_get_kref(ftdi);
ftdi->platform_data.potpg = 100;
ftdi->platform_data.reset = NULL;
@@ -324,8 +324,8 @@ static int ftdi_elan_hcd_init(struct usb_ftdi *ftdi)
request_module("u132_hcd");
dev_info(>udev->dev, "registering '%s'\n",
 ftdi->platform_dev.name);
-   result = platform_device_register(>platform_dev);
-   return result;
+
+   return platform_device_register(>platform_dev);
 }
 
 static void ftdi_elan_abandon_completions(struct usb_ftdi *ftdi)
-- 
2.5.0

[PATCH 2/2] ioc3-eth: use netdev_pub instead of handrolling alignment

[Jason A. Donenfeld]

It's safer to use the generic library function for this, rather than
reinventing it here with hard-coded alignment values.

Signed-off-by: Jason A. Donenfeld 
---
 drivers/net/ethernet/sgi/ioc3-eth.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c 
b/drivers/net/ethernet/sgi/ioc3-eth.c
index b607936e1b3e..514eca163ea5 100644
--- a/drivers/net/ethernet/sgi/ioc3-eth.c
+++ b/drivers/net/ethernet/sgi/ioc3-eth.c
@@ -86,31 +86,26 @@ struct ioc3_private {
int tx_ci;  /* TX consumer index */
int tx_pi;  /* TX producer index */
int txqlen;
u32 emcr, ehar_h, ehar_l;
spinlock_t ioc3_lock;
struct mii_if_info mii;
 
struct pci_dev *pdev;
 
/* Members used by autonegotiation  */
struct timer_list ioc3_timer;
 };
 
-static inline struct net_device *priv_netdev(struct ioc3_private *dev)
-{
-   return (void *)dev - ((sizeof(struct net_device) + 31) & ~31);
-}
-
 static int ioc3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
 static void ioc3_set_multicast_list(struct net_device *dev);
 static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev);
 static void ioc3_timeout(struct net_device *dev);
 static inline unsigned int ioc3_hash(const unsigned char *addr);
 static inline void ioc3_stop(struct ioc3_private *ip);
 static void ioc3_init(struct net_device *dev);
 
 static const char ioc3_str[] = "IOC3 Ethernet";
 static const struct ethtool_ops ioc3_ethtool_ops;
 
 /* We use this to acquire receive skb's that we can DMA directly into. */
 
@@ -417,39 +412,39 @@ static void ioc3_get_eaddr_nic(struct ioc3_private *ip)
printk("Failed to read MAC address\n");
return;
}
 
/* Read Memory.  */
nic_write_byte(ioc3, 0xf0);
nic_write_byte(ioc3, 0x00);
nic_write_byte(ioc3, 0x00);
 
for (i = 13; i >= 0; i--)
nic[i] = nic_read_byte(ioc3);
 
for (i = 2; i < 8; i++)
-   priv_netdev(ip)->dev_addr[i - 2] = nic[i];
+   netdev_pub(ip)->dev_addr[i - 2] = nic[i];
 }
 
 /*
  * Ok, this is hosed by design.  It's necessary to know what machine the
  * NIC is in in order to know how to read the NIC address.  We also have
  * to know if it's a PCI card or a NIC in on the node board ...
  */
 static void ioc3_get_eaddr(struct ioc3_private *ip)
 {
ioc3_get_eaddr_nic(ip);
 
-   printk("Ethernet address is %pM.\n", priv_netdev(ip)->dev_addr);
+   printk("Ethernet address is %pM.\n", netdev_pub(ip)->dev_addr);
 }
 
 static void __ioc3_set_mac_address(struct net_device *dev)
 {
struct ioc3_private *ip = netdev_priv(dev);
struct ioc3 *ioc3 = ip->regs;
 
ioc3_w_emar_h((dev->dev_addr[5] <<  8) | dev->dev_addr[4]);
ioc3_w_emar_l((dev->dev_addr[3] << 24) | (dev->dev_addr[2] << 16) |
  (dev->dev_addr[1] <<  8) | dev->dev_addr[0]);
 }
 
 static int ioc3_set_mac_address(struct net_device *dev, void *addr)
@@ -780,27 +775,27 @@ static void ioc3_timer(unsigned long data)
add_timer(>ioc3_timer);
 }
 
 /*
  * Try to find a PHY.  There is no apparent relation between the MII addresses
  * in the SGI documentation and what we find in reality, so we simply probe
  * for the PHY.  It seems IOC3 PHYs usually live on address 31.  One of my
  * onboard IOC3s has the special oddity that probing doesn't seem to find it
  * yet the interface seems to work fine, so if probing fails we for now will
  * simply default to PHY 31 instead of bailing out.
  */
 static int ioc3_mii_init(struct ioc3_private *ip)
 {
-   struct net_device *dev = priv_netdev(ip);
+   struct net_device *dev = netdev_pub(ip);
int i, found = 0, res = 0;
int ioc3_phy_workaround = 1;
u16 word;
 
for (i = 0; i < 32; i++) {
word = ioc3_mdio_read(dev, i, MII_PHYSID1);
 
if (word != 0x && word != 0x) {
found = 1;
break;  /* Found a PHY  */
}
}
 
-- 
2.13.2

[PATCH 2/2] ioc3-eth: use netdev_pub instead of handrolling alignment

[Jason A. Donenfeld]

It's safer to use the generic library function for this, rather than
reinventing it here with hard-coded alignment values.

Signed-off-by: Jason A. Donenfeld 
---
 drivers/net/ethernet/sgi/ioc3-eth.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c 
b/drivers/net/ethernet/sgi/ioc3-eth.c
index b607936e1b3e..514eca163ea5 100644
--- a/drivers/net/ethernet/sgi/ioc3-eth.c
+++ b/drivers/net/ethernet/sgi/ioc3-eth.c
@@ -86,31 +86,26 @@ struct ioc3_private {
int tx_ci;  /* TX consumer index */
int tx_pi;  /* TX producer index */
int txqlen;
u32 emcr, ehar_h, ehar_l;
spinlock_t ioc3_lock;
struct mii_if_info mii;
 
struct pci_dev *pdev;
 
/* Members used by autonegotiation  */
struct timer_list ioc3_timer;
 };
 
-static inline struct net_device *priv_netdev(struct ioc3_private *dev)
-{
-   return (void *)dev - ((sizeof(struct net_device) + 31) & ~31);
-}
-
 static int ioc3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
 static void ioc3_set_multicast_list(struct net_device *dev);
 static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev);
 static void ioc3_timeout(struct net_device *dev);
 static inline unsigned int ioc3_hash(const unsigned char *addr);
 static inline void ioc3_stop(struct ioc3_private *ip);
 static void ioc3_init(struct net_device *dev);
 
 static const char ioc3_str[] = "IOC3 Ethernet";
 static const struct ethtool_ops ioc3_ethtool_ops;
 
 /* We use this to acquire receive skb's that we can DMA directly into. */
 
@@ -417,39 +412,39 @@ static void ioc3_get_eaddr_nic(struct ioc3_private *ip)
printk("Failed to read MAC address\n");
return;
}
 
/* Read Memory.  */
nic_write_byte(ioc3, 0xf0);
nic_write_byte(ioc3, 0x00);
nic_write_byte(ioc3, 0x00);
 
for (i = 13; i >= 0; i--)
nic[i] = nic_read_byte(ioc3);
 
for (i = 2; i < 8; i++)
-   priv_netdev(ip)->dev_addr[i - 2] = nic[i];
+   netdev_pub(ip)->dev_addr[i - 2] = nic[i];
 }
 
 /*
  * Ok, this is hosed by design.  It's necessary to know what machine the
  * NIC is in in order to know how to read the NIC address.  We also have
  * to know if it's a PCI card or a NIC in on the node board ...
  */
 static void ioc3_get_eaddr(struct ioc3_private *ip)
 {
ioc3_get_eaddr_nic(ip);
 
-   printk("Ethernet address is %pM.\n", priv_netdev(ip)->dev_addr);
+   printk("Ethernet address is %pM.\n", netdev_pub(ip)->dev_addr);
 }
 
 static void __ioc3_set_mac_address(struct net_device *dev)
 {
struct ioc3_private *ip = netdev_priv(dev);
struct ioc3 *ioc3 = ip->regs;
 
ioc3_w_emar_h((dev->dev_addr[5] <<  8) | dev->dev_addr[4]);
ioc3_w_emar_l((dev->dev_addr[3] << 24) | (dev->dev_addr[2] << 16) |
  (dev->dev_addr[1] <<  8) | dev->dev_addr[0]);
 }
 
 static int ioc3_set_mac_address(struct net_device *dev, void *addr)
@@ -780,27 +775,27 @@ static void ioc3_timer(unsigned long data)
add_timer(>ioc3_timer);
 }
 
 /*
  * Try to find a PHY.  There is no apparent relation between the MII addresses
  * in the SGI documentation and what we find in reality, so we simply probe
  * for the PHY.  It seems IOC3 PHYs usually live on address 31.  One of my
  * onboard IOC3s has the special oddity that probing doesn't seem to find it
  * yet the interface seems to work fine, so if probing fails we for now will
  * simply default to PHY 31 instead of bailing out.
  */
 static int ioc3_mii_init(struct ioc3_private *ip)
 {
-   struct net_device *dev = priv_netdev(ip);
+   struct net_device *dev = netdev_pub(ip);
int i, found = 0, res = 0;
int ioc3_phy_workaround = 1;
u16 word;
 
for (i = 0; i < 32; i++) {
word = ioc3_mdio_read(dev, i, MII_PHYSID1);
 
if (word != 0x && word != 0x) {
found = 1;
break;  /* Found a PHY  */
}
}
 
-- 
2.13.2

[PATCH 1/2] netdevice: add netdev_pub helper function

[Jason A. Donenfeld]

Being able to utilize this makes code a lot simpler and cleaner. It's
easier in many cases for drivers to pass around their private data
structure, while occationally needing to dip into net_device, rather
than the other way around, which results in tons of calls to netdev_priv
in the top of every single function, which makes everything confusing
and less clear. Additionally, this enables a "correct" way of doing such
a thing, instead of having drivers attempt to reinvent the wheel and
screw it up.

Signed-off-by: Jason A. Donenfeld 
---
 include/linux/netdevice.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 779b23595596..83d58504e5c4 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2030,26 +2030,37 @@ void dev_net_set(struct net_device *dev, struct net 
*net)
 }
 
 /**
  * netdev_priv - access network device private data
  * @dev: network device
  *
  * Get network device private data
  */
 static inline void *netdev_priv(const struct net_device *dev)
 {
return (char *)dev + ALIGN(sizeof(struct net_device), NETDEV_ALIGN);
 }
 
+/**
+ * netdev_pub - access network device from private pointer
+ * @priv: private data pointer of network device
+ *
+ * Get network device from a network device private data pointer
+ */
+static inline struct net_device *netdev_pub(void *priv)
+{
+   return (struct net_device *)((char *)priv - ALIGN(sizeof(struct 
net_device), NETDEV_ALIGN));
+}
+
 /* Set the sysfs physical device reference for the network logical device
  * if set prior to registration will cause a symlink during initialization.
  */
 #define SET_NETDEV_DEV(net, pdev)  ((net)->dev.parent = (pdev))
 
 /* Set the sysfs device type for the network logical device to allow
  * fine-grained identification of different network device types. For
  * example Ethernet, Wireless LAN, Bluetooth, WiMAX etc.
  */
 #define SET_NETDEV_DEVTYPE(net, devtype)   ((net)->dev.type = (devtype))
 
 /* Default NAPI poll() weight
  * Device drivers are strongly advised to not use bigger value
-- 
2.13.2

[PATCH 1/2] netdevice: add netdev_pub helper function

[Jason A. Donenfeld]

Being able to utilize this makes code a lot simpler and cleaner. It's
easier in many cases for drivers to pass around their private data
structure, while occationally needing to dip into net_device, rather
than the other way around, which results in tons of calls to netdev_priv
in the top of every single function, which makes everything confusing
and less clear. Additionally, this enables a "correct" way of doing such
a thing, instead of having drivers attempt to reinvent the wheel and
screw it up.

Signed-off-by: Jason A. Donenfeld 
---
 include/linux/netdevice.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 779b23595596..83d58504e5c4 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2030,26 +2030,37 @@ void dev_net_set(struct net_device *dev, struct net 
*net)
 }
 
 /**
  * netdev_priv - access network device private data
  * @dev: network device
  *
  * Get network device private data
  */
 static inline void *netdev_priv(const struct net_device *dev)
 {
return (char *)dev + ALIGN(sizeof(struct net_device), NETDEV_ALIGN);
 }
 
+/**
+ * netdev_pub - access network device from private pointer
+ * @priv: private data pointer of network device
+ *
+ * Get network device from a network device private data pointer
+ */
+static inline struct net_device *netdev_pub(void *priv)
+{
+   return (struct net_device *)((char *)priv - ALIGN(sizeof(struct 
net_device), NETDEV_ALIGN));
+}
+
 /* Set the sysfs physical device reference for the network logical device
  * if set prior to registration will cause a symlink during initialization.
  */
 #define SET_NETDEV_DEV(net, pdev)  ((net)->dev.parent = (pdev))
 
 /* Set the sysfs device type for the network logical device to allow
  * fine-grained identification of different network device types. For
  * example Ethernet, Wireless LAN, Bluetooth, WiMAX etc.
  */
 #define SET_NETDEV_DEVTYPE(net, devtype)   ((net)->dev.type = (devtype))
 
 /* Default NAPI poll() weight
  * Device drivers are strongly advised to not use bigger value
-- 
2.13.2

[PATCH] usb: gadget: fsl_udc_core: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable assignment.

This issue was detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 6f2f71c..bf8ff5e 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1642,8 +1642,7 @@ static int process_ep_req(struct fsl_udc *udc, int pipe,
} else if (hc32_to_cpu(curr_td->size_ioc_sts)
& DTD_STATUS_ACTIVE) {
VDBG("Request not complete");
-   status = REQ_UNCOMPLETE;
-   return status;
+   return REQ_UNCOMPLETE;
} else if (remaining_length) {
if (direction) {
VDBG("Transmit dTD remaining length not zero");
-- 
2.5.0

[PATCH] usb: gadget: fsl_udc_core: compress return logic into one line

[Gustavo A. R. Silva]

Simplify return logic to avoid unnecessary variable assignment.

This issue was detected using Coccinelle and the following
semantic patch:

@@
local idexpression ret;
expression e;
@@

-ret =
+return
 e;
-return ret;

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 6f2f71c..bf8ff5e 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1642,8 +1642,7 @@ static int process_ep_req(struct fsl_udc *udc, int pipe,
} else if (hc32_to_cpu(curr_td->size_ioc_sts)
& DTD_STATUS_ACTIVE) {
VDBG("Request not complete");
-   status = REQ_UNCOMPLETE;
-   return status;
+   return REQ_UNCOMPLETE;
} else if (remaining_length) {
if (direction) {
VDBG("Transmit dTD remaining length not zero");
-- 
2.5.0

Re: [RFC v5 32/38] powerpc: capture the violated protection key on fault

[Anshuman Khandual]

On 07/06/2017 02:52 AM, Ram Pai wrote:
> Capture the protection key that got violated in paca.
> This value will be used by used to inform the signal
> handler.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/paca.h   |1 +
>  arch/powerpc/kernel/asm-offsets.c |1 +
>  arch/powerpc/mm/fault.c   |3 +++
>  3 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index c8bd1fc..0c06188 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -94,6 +94,7 @@ struct paca_struct {
>   u64 dscr_default;   /* per-CPU default DSCR */
>  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
>   u64 paca_amr;   /* value of amr at exception */
> + u16 paca_pkey;  /* exception causing pkey */
>  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
>  
>  #ifdef CONFIG_PPC_STD_MMU_64
> diff --git a/arch/powerpc/kernel/asm-offsets.c 
> b/arch/powerpc/kernel/asm-offsets.c
> index 17f5d8a..7dff862 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -244,6 +244,7 @@ int main(void)
>  
>  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
>   OFFSET(PACA_AMR, paca_struct, paca_amr);
> + OFFSET(PACA_PKEY, paca_struct, paca_pkey);
>  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
>  
>   OFFSET(ACCOUNT_STARTTIME, paca_struct, accounting.starttime);
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index a6710f5..c8674a7 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -265,6 +265,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>   if (error_code & DSISR_KEYFAULT) {
>   code = SEGV_PKUERR;
>   get_paca()->paca_amr = read_amr();
> + get_paca()->paca_pkey = get_pte_pkey(current->mm, address);
>   goto bad_area_nosemaphore;
>   }
>  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> @@ -290,6 +291,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>  
>   perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>  
> +

Stray empty line addition here.

>   /*
>* We want to do this outside mmap_sem, because reading code around nip
>* can result in fault, which will cause a deadlock when called with
> @@ -453,6 +455,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>   if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
>   is_exec, 0)) {
>   get_paca()->paca_amr = read_amr();
> + get_paca()->paca_pkey = vma_pkey(vma);

Why not get_pte_pkey() here as well ? IIUC both these function would
give us the same pkey, then why is the difference when we process a
page fault for real protection key violation in HW compared to cross
checking of VMA protection key in SW for regular page faults.

Re: [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper

[Anshuman Khandual]

On 07/06/2017 02:52 AM, Ram Pai wrote:
> get_pte_pkey() helper returns the pkey associated with
> a address corresponding to a given mm_struct.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 
>  arch/powerpc/mm/hash_utils_64.c   |   28 
> +
>  2 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
> b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> index f7a6ed3..369f9ff 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> @@ -450,6 +450,11 @@ extern int hash_page(unsigned long ea, unsigned long 
> access, unsigned long trap,
>  int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long 
> vsid,
>pte_t *ptep, unsigned long trap, unsigned long flags,
>int ssize, unsigned int shift, unsigned int mmu_psize);
> +
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address);
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  extern int __hash_page_thp(unsigned long ea, unsigned long access,
>  unsigned long vsid, pmd_t *pmdp, unsigned long trap,
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 1e74529..591990c 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1573,6 +1573,34 @@ void hash_preload(struct mm_struct *mm, unsigned long 
> ea,
>   local_irq_restore(flags);
>  }
>  
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +/*
> + * return the protection key associated with the given address
> + * and the mm_struct.
> + */
> +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address)
> +{
> + pte_t *ptep;
> + u16 pkey = 0;
> + unsigned long flags;
> +
> + if (REGION_ID(address) == VMALLOC_REGION_ID)
> + mm = _mm;

IIUC, protection keys are only applicable for user space. This
function is getting used to populate siginfo structure. Then how
can we ever request this for any address in VMALLOC region.

> +
> + if (!mm || !mm->pgd)
> + return 0;

Is this really required at this stage ?

Re: [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper

[Anshuman Khandual]

On 07/06/2017 02:52 AM, Ram Pai wrote:
> get_pte_pkey() helper returns the pkey associated with
> a address corresponding to a given mm_struct.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 
>  arch/powerpc/mm/hash_utils_64.c   |   28 
> +
>  2 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
> b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> index f7a6ed3..369f9ff 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> @@ -450,6 +450,11 @@ extern int hash_page(unsigned long ea, unsigned long 
> access, unsigned long trap,
>  int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long 
> vsid,
>pte_t *ptep, unsigned long trap, unsigned long flags,
>int ssize, unsigned int shift, unsigned int mmu_psize);
> +
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address);
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  extern int __hash_page_thp(unsigned long ea, unsigned long access,
>  unsigned long vsid, pmd_t *pmdp, unsigned long trap,
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 1e74529..591990c 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1573,6 +1573,34 @@ void hash_preload(struct mm_struct *mm, unsigned long 
> ea,
>   local_irq_restore(flags);
>  }
>  
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +/*
> + * return the protection key associated with the given address
> + * and the mm_struct.
> + */
> +u16 get_pte_pkey(struct mm_struct *mm, unsigned long address)
> +{
> + pte_t *ptep;
> + u16 pkey = 0;
> + unsigned long flags;
> +
> + if (REGION_ID(address) == VMALLOC_REGION_ID)
> + mm = _mm;

IIUC, protection keys are only applicable for user space. This
function is getting used to populate siginfo structure. Then how
can we ever request this for any address in VMALLOC region.

> +
> + if (!mm || !mm->pgd)
> + return 0;

Is this really required at this stage ?

Re: [RFC v5 32/38] powerpc: capture the violated protection key on fault

[Anshuman Khandual]

On 07/06/2017 02:52 AM, Ram Pai wrote:
> Capture the protection key that got violated in paca.
> This value will be used by used to inform the signal
> handler.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/paca.h   |1 +
>  arch/powerpc/kernel/asm-offsets.c |1 +
>  arch/powerpc/mm/fault.c   |3 +++
>  3 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index c8bd1fc..0c06188 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -94,6 +94,7 @@ struct paca_struct {
>   u64 dscr_default;   /* per-CPU default DSCR */
>  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
>   u64 paca_amr;   /* value of amr at exception */
> + u16 paca_pkey;  /* exception causing pkey */
>  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
>  
>  #ifdef CONFIG_PPC_STD_MMU_64
> diff --git a/arch/powerpc/kernel/asm-offsets.c 
> b/arch/powerpc/kernel/asm-offsets.c
> index 17f5d8a..7dff862 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -244,6 +244,7 @@ int main(void)
>  
>  #ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
>   OFFSET(PACA_AMR, paca_struct, paca_amr);
> + OFFSET(PACA_PKEY, paca_struct, paca_pkey);
>  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
>  
>   OFFSET(ACCOUNT_STARTTIME, paca_struct, accounting.starttime);
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index a6710f5..c8674a7 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -265,6 +265,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>   if (error_code & DSISR_KEYFAULT) {
>   code = SEGV_PKUERR;
>   get_paca()->paca_amr = read_amr();
> + get_paca()->paca_pkey = get_pte_pkey(current->mm, address);
>   goto bad_area_nosemaphore;
>   }
>  #endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> @@ -290,6 +291,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>  
>   perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>  
> +

Stray empty line addition here.

>   /*
>* We want to do this outside mmap_sem, because reading code around nip
>* can result in fault, which will cause a deadlock when called with
> @@ -453,6 +455,7 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>   if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
>   is_exec, 0)) {
>   get_paca()->paca_amr = read_amr();
> + get_paca()->paca_pkey = vma_pkey(vma);

Why not get_pte_pkey() here as well ? IIUC both these function would
give us the same pkey, then why is the difference when we process a
page fault for real protection key violation in HW compared to cross
checking of VMA protection key in SW for regular page faults.

Re: [RFC v5 33/38] powerpc: Deliver SEGV signal on pkey violation

[Anshuman Khandual]

On 07/06/2017 02:52 AM, Ram Pai wrote:
> The value of the AMR register at the time of exception
> is made available in gp_regs[PT_AMR] of the siginfo.
> 
> The value of the pkey, whose protection got violated,
> is made available in si_pkey field of the siginfo structure.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/uapi/asm/ptrace.h |3 ++-
>  arch/powerpc/kernel/signal_32.c|5 +
>  arch/powerpc/kernel/signal_64.c|4 
>  arch/powerpc/kernel/traps.c|   14 ++
>  4 files changed, 25 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/include/uapi/asm/ptrace.h 
> b/arch/powerpc/include/uapi/asm/ptrace.h
> index 8036b38..7ec2428 100644
> --- a/arch/powerpc/include/uapi/asm/ptrace.h
> +++ b/arch/powerpc/include/uapi/asm/ptrace.h
> @@ -108,8 +108,9 @@ struct pt_regs {
>  #define PT_DAR   41
>  #define PT_DSISR 42
>  #define PT_RESULT 43
> -#define PT_DSCR 44
>  #define PT_REGS_COUNT 44
> +#define PT_DSCR 44
> +#define PT_AMR   45

Why PT_DSCR was moved down ? This change is redundant here.

Re: [RFC v5 33/38] powerpc: Deliver SEGV signal on pkey violation

[Anshuman Khandual]

On 07/06/2017 02:52 AM, Ram Pai wrote:
> The value of the AMR register at the time of exception
> is made available in gp_regs[PT_AMR] of the siginfo.
> 
> The value of the pkey, whose protection got violated,
> is made available in si_pkey field of the siginfo structure.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/uapi/asm/ptrace.h |3 ++-
>  arch/powerpc/kernel/signal_32.c|5 +
>  arch/powerpc/kernel/signal_64.c|4 
>  arch/powerpc/kernel/traps.c|   14 ++
>  4 files changed, 25 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/include/uapi/asm/ptrace.h 
> b/arch/powerpc/include/uapi/asm/ptrace.h
> index 8036b38..7ec2428 100644
> --- a/arch/powerpc/include/uapi/asm/ptrace.h
> +++ b/arch/powerpc/include/uapi/asm/ptrace.h
> @@ -108,8 +108,9 @@ struct pt_regs {
>  #define PT_DAR   41
>  #define PT_DSISR 42
>  #define PT_RESULT 43
> -#define PT_DSCR 44
>  #define PT_REGS_COUNT 44
> +#define PT_DSCR 44
> +#define PT_AMR   45

Why PT_DSCR was moved down ? This change is redundant here.