Re: [PATCH] mm/memcg: avoid page count check for zone device

[Michal Hocko]

On Thu 14-09-17 15:00:11, jgli...@redhat.com wrote:
> From: Jérôme Glisse 
> 
> Fix for 4.14, zone device page always have an elevated refcount
> of one and thus page count sanity check in uncharge_page() is
> inappropriate for them.
> 
> Signed-off-by: Jérôme Glisse 
> Reported-by: Evgeny Baskakov 
> Cc: Andrew Morton 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Vladimir Davydov 

Acked-by: Michal Hocko 

Side note. Wouldn't it be better to re-organize the check a bit? It is
true that this is VM_BUG so it is not usually compiled in but when it
preferably checks for unlikely cases first while the ref count will be
0 in the prevailing cases. So can we have
VM_BUG_ON_PAGE(page_count(page) && !is_zone_device_page(page) &&
!PageHWPoison(page), page);

I would simply fold this nano optimization into the patch as you are
touching it already. Not sure it is worth a separate commit.

> ---
>  mm/memcontrol.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 15af3da5af02..d51d3e1f49c9 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5648,7 +5648,8 @@ static void uncharge_batch(const struct uncharge_gather 
> *ug)
>  static void uncharge_page(struct page *page, struct uncharge_gather *ug)
>  {
>   VM_BUG_ON_PAGE(PageLRU(page), page);
> - VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page);
> + VM_BUG_ON_PAGE(!PageHWPoison(page) && !is_zone_device_page(page) &&
> + page_count(page), page);
>  
>   if (!page->mem_cgroup)
>   return;
> -- 
> 2.13.5

-- 
Michal Hocko
SUSE Labs

Re: + include-linux-sched-mmh-uninline-mmdrop_async-etc.patch added to -mm tree

[Michal Hocko]

On Thu 14-09-17 13:19:38, Andrew Morton wrote:
> From: Andrew Morton 
> Subject: include/linux/sched/mm.h: uninline mmdrop_async(), etc
> 
> mmdrop_async() is only used in fork.c.  Move that and its support
> functions into fork.c, uninline it all.

Is this really an improvement? Why do we want to discourage more code
paths to use mmdrop_async? It sounds like a useful api and it has been
removed only because it lost its own user in oom code. Now that we have
a user I would just keep it where it was before.

> Cc: Ingo Molnar 
> Cc: Michal Hocko 
> Cc: Peter Zijlstra 
> Cc: Oleg Nesterov 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/sched/mm.h |   24 -
>  kernel/fork.c|  455 +++--
>  2 files changed, 241 insertions(+), 238 deletions(-)
> 
> diff -puN 
> include/linux/sched/mm.h~include-linux-sched-mmh-uninline-mmdrop_async-etc 
> include/linux/sched/mm.h
> --- 
> a/include/linux/sched/mm.h~include-linux-sched-mmh-uninline-mmdrop_async-etc
> +++ a/include/linux/sched/mm.h
> @@ -10,7 +10,7 @@
>  /*
>   * Routines for handling mm_structs
>   */
> -extern struct mm_struct * mm_alloc(void);
> +extern struct mm_struct *mm_alloc(void);
>  
>  /**
>   * mmgrab() - Pin a &struct mm_struct.
> @@ -34,27 +34,7 @@ static inline void mmgrab(struct mm_stru
>   atomic_inc(&mm->mm_count);
>  }
>  
> -/* mmdrop drops the mm and the page tables */
> -extern void __mmdrop(struct mm_struct *);
> -static inline void mmdrop(struct mm_struct *mm)
> -{
> - if (unlikely(atomic_dec_and_test(&mm->mm_count)))
> - __mmdrop(mm);
> -}
> -
> -static inline void mmdrop_async_fn(struct work_struct *work)
> -{
> - struct mm_struct *mm = container_of(work, struct mm_struct, 
> async_put_work);
> - __mmdrop(mm);
> -}
> -
> -static inline void mmdrop_async(struct mm_struct *mm)
> -{
> - if (unlikely(atomic_dec_and_test(&mm->mm_count))) {
> - INIT_WORK(&mm->async_put_work, mmdrop_async_fn);
> - schedule_work(&mm->async_put_work);
> - }
> -}
> +extern void mmdrop(struct mm_struct *mm);
>  
>  /**
>   * mmget() - Pin the address space associated with a &struct mm_struct.
> diff -puN kernel/fork.c~include-linux-sched-mmh-uninline-mmdrop_async-etc 
> kernel/fork.c
> --- a/kernel/fork.c~include-linux-sched-mmh-uninline-mmdrop_async-etc
> +++ a/kernel/fork.c
> @@ -77,6 +77,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -386,6 +387,244 @@ void free_task(struct task_struct *tsk)
>  }
>  EXPORT_SYMBOL(free_task);
>  
> +#ifdef CONFIG_MMU
> +static __latent_entropy int dup_mmap(struct mm_struct *mm,
> + struct mm_struct *oldmm)
> +{
> + struct vm_area_struct *mpnt, *tmp, *prev, **pprev;
> + struct rb_node **rb_link, *rb_parent;
> + int retval;
> + unsigned long charge;
> + LIST_HEAD(uf);
> +
> + uprobe_start_dup_mmap();
> + if (down_write_killable(&oldmm->mmap_sem)) {
> + retval = -EINTR;
> + goto fail_uprobe_end;
> + }
> + flush_cache_dup_mm(oldmm);
> + uprobe_dup_mmap(oldmm, mm);
> + /*
> +  * Not linked in yet - no deadlock potential:
> +  */
> + down_write_nested(&mm->mmap_sem, SINGLE_DEPTH_NESTING);
> +
> + /* No ordering required: file already has been exposed. */
> + RCU_INIT_POINTER(mm->exe_file, get_mm_exe_file(oldmm));
> +
> + mm->total_vm = oldmm->total_vm;
> + mm->data_vm = oldmm->data_vm;
> + mm->exec_vm = oldmm->exec_vm;
> + mm->stack_vm = oldmm->stack_vm;
> +
> + rb_link = &mm->mm_rb.rb_node;
> + rb_parent = NULL;
> + pprev = &mm->mmap;
> + retval = ksm_fork(mm, oldmm);
> + if (retval)
> + goto out;
> + retval = khugepaged_fork(mm, oldmm);
> + if (retval)
> + goto out;
> +
> + prev = NULL;
> + for (mpnt = oldmm->mmap; mpnt; mpnt = mpnt->vm_next) {
> + struct file *file;
> +
> + if (mpnt->vm_flags & VM_DONTCOPY) {
> + vm_stat_account(mm, mpnt->vm_flags, -vma_pages(mpnt));
> + continue;
> + }
> + charge = 0;
> + if (mpnt->vm_flags & VM_ACCOUNT) {
> + unsigned long len = vma_pages(mpnt);
> +
> + if (security_vm_enough_memory_mm(oldmm, len)) /* sic */
> + goto fail_nomem;
> + charge = len;
> + }
> + tmp = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
> + if (!tmp)
> + goto fail_nomem;
> + *tmp = *mpnt;
> + INIT_LIST_HEAD(&tmp->anon_vma_chain);
> + retval = vma_dup_policy(mpnt, tmp);
> + if (retval)
> + goto fail_nomem_policy;
> + tmp->vm_mm = mm;
> + retval = dup_userfaultfd(tmp, &uf);
> + if (retval)
> + goto fail_nomem

Re: [PATCH 2/3] ARM: dts: at91: usb_a9g20: fix rtc node

[Nicolas Ferre]

On 15/09/2017 at 04:00, Alexandre Belloni wrote:
> The rv3029 compatible is missing its vendor string, add it.
> Also fix the node name to be a proper generic name.
> 
> Signed-off-by: Alexandre Belloni 

Acked-by: Nicolas Ferre 

> ---
>  arch/arm/boot/dts/usb_a9g20_common.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/usb_a9g20_common.dtsi 
> b/arch/arm/boot/dts/usb_a9g20_common.dtsi
> index 088c2c3685ab..81c3fe0465d9 100644
> --- a/arch/arm/boot/dts/usb_a9g20_common.dtsi
> +++ b/arch/arm/boot/dts/usb_a9g20_common.dtsi
> @@ -20,8 +20,8 @@
>   };
>  
>   i2c-gpio-0 {
> - rv3029c2@56 {
> - compatible = "rv3029c2";
> + rtc@56 {
> + compatible = "microcrystal,rv3029";
>   reg = <0x56>;
>   };
>   };
> 


-- 
Nicolas Ferre

Re: BUG: Sporadic crashes with current Linus tree

[Thomas Gleixner]

On Thu, 14 Sep 2017, Andy Lutomirski wrote:
> On Thu, Sep 14, 2017 at 9:00 AM, Thomas Gleixner  wrote:
> > On Thu, 14 Sep 2017, Andy Lutomirski wrote:
> >> On Thu, Sep 14, 2017 at 12:38 AM, Thomas Gleixner  
> >> wrote:
> >> > Hi!
> >> >
> >> > I've seen the following crash sporadically with commit 46c1e79fee:
> >> >
> >> > Have not seen that with 3882a734c19b, though I saw the PCID warnings on
> >> > that machine.
> >> >
> >> > I have no idea how to reproduce so bisecting is pretty much pointless. 
> >> > Any
> >> > idea what to do?
> >>
> >> Does tools/testing/selftests/x86/sigreturn_64 reproduce it?
> >
> > Will try tomorrow once I figured out how to compile that stuff. Invoking a
> > simple make in that directory fails.
> 
> What's the error?  It works for me.

gcc -m64 -o 
/home/tglx/work/kernel/linus/linux/tools/testing/selftests/x86/sysret_ss_attrs_64
 -O2 -g -std=gnu99 -pthread -Wall  sysret_ss_attrs.c thunks.S -lrt -ldl
/usr/bin/ld: /tmp/cco4vSkU.o: relocation R_X86_64_32S against `.text' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

> >
> > Built it manually and when I run it tells: stack16 is too high
> >
> >> Ugh, weird.  It kind of looks like current->thread.sp0 == NULL.  I
> >> have a patch series that changes a bunch of that code in my git tree,
> >> but that's definitely not in Linus' tree.
> >
> > Right. The stupid thing is that the machine did not throw up all day
> > neither idle nor loaded. Still the same kernel which barfed tonight several
> > times.
> 
> This is weird.  The crashing process is rsyslogd, which should have
> been running for a long time and shouldn't have any strange state.  I
> wonder if this is some kind of memory corruption.  There would have to
> be corruption of thread_struct *and* some kind of issue causing IRET
> to fail, though.
> 
> The attached patch could plausibly give some useful hint.

I'll put it on that machine and hope it will reproduce. Didn't die since
yesterday moring 

Thanks,

tglx

[PATCH] block: move sanity checking ahead of bi_front/back_seg_size updating

[Jianchao Wang]

If the bio_integrity_merge_rq() return false or nr_phys_segments exceeds
the max_segments, the merging fails, but the bi_front/back_seg_size may
have been modified. To avoid it, move the sanity checking ahead.

Signed-off-by: Jianchao Wang 
---
 block/blk-merge.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 99038830..14b6e37 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -553,6 +553,7 @@ static bool req_no_special_merge(struct request *req)
 static int ll_merge_requests_fn(struct request_queue *q, struct request *req,
struct request *next)
 {
+   bool contig;
int total_phys_segments;
unsigned int seg_size =
req->biotail->bi_seg_back_size + next->bio->bi_seg_front_size;
@@ -575,13 +576,9 @@ static int ll_merge_requests_fn(struct request_queue *q, 
struct request *req,
return 0;
 
total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;
-   if (blk_phys_contig_segment(q, req->biotail, next->bio)) {
-   if (req->nr_phys_segments == 1)
-   req->bio->bi_seg_front_size = seg_size;
-   if (next->nr_phys_segments == 1)
-   next->biotail->bi_seg_back_size = seg_size;
+   contig = blk_phys_contig_segment(q, req->biotail, next->bio);
+   if (contig)
total_phys_segments--;
-   }
 
if (total_phys_segments > queue_max_segments(q))
return 0;
@@ -589,6 +586,13 @@ static int ll_merge_requests_fn(struct request_queue *q, 
struct request *req,
if (blk_integrity_merge_rq(q, req, next) == false)
return 0;
 
+   if (contig) {
+   if (req->nr_phys_segments == 1)
+   req->bio->bi_seg_front_size = seg_size;
+   if (next->nr_phys_segments == 1)
+   next->biotail->bi_seg_back_size = seg_size;
+   }
+
/* Merge is OK... */
req->nr_phys_segments = total_phys_segments;
return 1;
-- 
2.7.4

Re: [PATCH] iio: dac: ds4422/ds4424 dac driver

[Linus Walleij]

On Thu, Sep 14, 2017 at 10:24 PM, Ismail Kose
 wrote:

> +struct ds4424_pdata {
> +   const char *vcc_supply_name;

Should not be needed at all, get the supply directly from the device tree.

> +   uint32_t rfs_res[DS4424_MAX_DAC_CHANNELS];
> +   struct iio_map *dac_iio_map;
> +};

Drop this entire platform data file and move all these fields
you still need into struct ds4424_data.

If you have legacy kernels still using platform data, that's too
bad, we will not maintain them upstream and not merge new
board files using platform data normally, use device tree or ACPI
DSTD only please.

Yours,
Linus Walleij

Re: + include-linux-sched-mmh-uninline-mmdrop_async-etc.patch added to -mm tree

[Michal Hocko]

On Fri 15-09-17 09:07:31, Michal Hocko wrote:
> On Thu 14-09-17 13:19:38, Andrew Morton wrote:
> > From: Andrew Morton 
> > Subject: include/linux/sched/mm.h: uninline mmdrop_async(), etc
> > 
> > mmdrop_async() is only used in fork.c.  Move that and its support
> > functions into fork.c, uninline it all.
> 
> Is this really an improvement? Why do we want to discourage more code
> paths to use mmdrop_async? It sounds like a useful api and it has been
> removed only because it lost its own user in oom code. Now that we have
> a user I would just keep it where it was before.

Dohh, I have mixed mmput_async with mmdrop_async. Anyway I still think
that this is universal enough to have it in a header rather than hiding
it in fork.c
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 3/3] powerpc/5200: dts: digsy_mtc.dts: fix rv3029 compatible

[Anatolij Gustschin]

On Fri, 15 Sep 2017 04:00:04 +0200
Alexandre Belloni alexandre.bell...@free-electrons.com wrote:

>The proper compatible for rv3029 is microcrystal,rv3029.
>
>Signed-off-by: Alexandre Belloni 

Acked-by: Anatolij Gustschin 

Re: [PATCH] dt-bindings: RTC: add stericsson,coh901331 bindings

[Linus Walleij]

On Fri, Sep 15, 2017 at 2:19 AM, Alexandre Belloni
 wrote:

> Add device tree bindings for the ST-Ericsson COH 901 331 Real Time Clock
>
> Signed-off-by: Alexandre Belloni 

Oh this was merged so far back in the day that we were even lax
about adding bindings properly. Too bad, sorry about it.

Reviewed-by: Linus Walleij 

Linus Walleij

[PATCH] objtool: Do not retrieve data from empty sections

[Josh Poimboeuf]

From: Petr Vandrovec 

Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:

elf_getdata: can't manipulate null section

As nothing is done with sections that have zero size, just do not
retrieve their data at all.

Signed-off-by: Petr Vandrovec 
Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/elf.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 6e9f980a7d26..99eccd23023d 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
 
-   sec->data = elf_getdata(s, NULL);
-   if (!sec->data) {
-   WARN_ELF("elf_getdata");
-   return -1;
-   }
-
-   if (sec->data->d_off != 0 ||
-   sec->data->d_size != sec->sh.sh_size) {
-   WARN("unexpected data attributes for %s", sec->name);
-   return -1;
+   if (sec->sh.sh_size != 0) {
+   sec->data = elf_getdata(s, NULL);
+   if (!sec->data) {
+   WARN_ELF("elf_getdata");
+   return -1;
+   }
+   if (sec->data->d_off != 0 ||
+   sec->data->d_size != sec->sh.sh_size) {
+   WARN("unexpected data attributes for %s",
+sec->name);
+   return -1;
+   }
}
-
-   sec->len = sec->data->d_size;
+   sec->len = sec->sh.sh_size;
}
 
/* sanity check, one more call to elf_nextscn() should return NULL */
-- 
2.13.5

[PATCH] objtool: Fix object file corruption

[Josh Poimboeuf]

Arnd Bergmann reported that a randconfig build was failing with the
following link error:

  built-in.o: member arch/x86/kernel/time.o in archive is not an object

It turns out the link failed because the time.o file had been corrupted
by objtool:

  nm: arch/x86/kernel/time.o: File format not recognized

In certain rare cases, when a .o file's ORC table is very small, the
.data section size doesn't change because it's page aligned.  Because
all the existing sections haven't changed size, libelf doesn't detect
any section header changes, and so it doesn't update the section header
table properly.  Instead it writes junk in the section header entries
for the new ORC sections.

Make sure libelf properly updates the section header table by setting
the ELF_F_DIRTY flag in the top level elf struct.

Reported-by: Arnd Bergmann 
Fixes: 627fce14809b ("objtool: Add ORC unwind table generation")
Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/elf.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 6e9f980a7d26..780d02af957d 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -561,6 +561,7 @@ int elf_write(struct elf *elf)
struct section *sec;
Elf_Scn *s;
 
+   /* Update section headers for changed sections: */
list_for_each_entry(sec, &elf->sections, list) {
if (sec->changed) {
s = elf_getscn(elf->elf, sec->idx);
@@ -568,13 +569,17 @@ int elf_write(struct elf *elf)
WARN_ELF("elf_getscn");
return -1;
}
-   if (!gelf_update_shdr (s, &sec->sh)) {
+   if (!gelf_update_shdr(s, &sec->sh)) {
WARN_ELF("gelf_update_shdr");
return -1;
}
}
}
 
+   /* Make sure the new section header entries get updated properly. */
+   elf_flagelf(elf->elf, ELF_C_SET, ELF_F_DIRTY);
+
+   /* Write all changes to the file. */
if (elf_update(elf->elf, ELF_C_WRITE) < 0) {
WARN_ELF("elf_update");
return -1;
-- 
2.13.5

Re: [PATCH] nl80211: check for the required netlink attributes presence

[Johannes Berg]

On Wed, 2017-09-13 at 00:21 +0200, Vladis Dronov wrote:
> nl80211_set_rekey_data() does not check if the required attributes
> NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
> NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
> users with CAP_NET_ADMIN privilege and may result in NULL dereference
> and a system crash. Add a check for the required attributes presence.
> This patch is based on the patch by bo Zhang.

Huh. Applied, thanks.

johannes

Re: [PATCH] net: phy: Fix mask value write on gmii2rgmii converter speed register.

[Fahad Kunnathadi]

Hi Andrew,

Thank you for review and comments.

I will review this driver code with any review comments before, and update you 
if I could find any..

Best Regards
Fahad K  

- Original Message -
From: "Andrew Lunn" 
To: "Fahad Kunnathadi" 
Cc: "f fainelli" , net...@vger.kernel.org, "Michal Simek" 
, linux-kernel@vger.kernel.org, "soren brinkmann" 
, linux-arm-ker...@lists.infradead.org
Sent: Thursday, September 14, 2017 8:04:54 PM
Subject: Re: [PATCH] net: phy: Fix mask value write on gmii2rgmii converter 
speed register.

On Thu, Sep 14, 2017 at 12:46:31PM +0530, Fahad Kunnathadi wrote:
> To clear Speed Selection in MDIO control register(0x10),
> ie, clear bits 6 and 13 to zero while keeping other bits same.
> Before AND operation,The Mask value has to be perform with bitwise NOT
> operation (ie, ~ operator)
> 
> This patch clears current speed selection before writing the
> new speed settings to gmii2rgmii converter

Hi Fahad

I expect you will find other issues with this driver. I pointed some
out at the time it is submitted, but the developers went quiet as soon
as it was accepted.

Anyway, please ensure David Miller  gets a copy.

The subject line should be:

[PATCH net] net: phy: Fix mask value write on gmii2rgmii converter speed 
register.

and include a fixes tag:

Fixes: f411a6160bd4 ("net: phy: Add gmiitorgmii converter support")

Reviewed-by: Andrew Lunn 

Andrew

[PATCH] block: consider merge of segments when merge bio into rq

[Jianchao Wang]

When account the nr_phys_segments during merging bios into rq,
only consider segments merging in individual bio but not all
the bios in a rq. This leads to the bigger nr_phys_segments of
rq than the real one when the segments of bios in rq are
contiguous and mergeable. The nr_phys_segments of rq will exceed
max_segmets of q while the sectors of rq maybe far away from
the max_sectors of q.

Consider the segments merge when account nr_phys_segments of rq
during merging bio into rq. Promote the merging of small and
contiguous IO. In addition, it could eliminate the wasting of
scatterlist structure.

Signed-off-by: Jianchao Wang 
---
 block/blk-merge.c | 98 ---
 1 file changed, 64 insertions(+), 34 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 14b6e37..b2f54fd 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -472,54 +472,60 @@ int blk_rq_map_sg(struct request_queue *q, struct request 
*rq,
 }
 EXPORT_SYMBOL(blk_rq_map_sg);
 
-static inline int ll_new_hw_segment(struct request_queue *q,
-   struct request *req,
-   struct bio *bio)
-{
-   int nr_phys_segs = bio_phys_segments(q, bio);
-
-   if (req->nr_phys_segments + nr_phys_segs > queue_max_segments(q))
-   goto no_merge;
-
-   if (blk_integrity_merge_bio(q, req, bio) == false)
-   goto no_merge;
-
-   /*
-* This will form the start of a new hw segment.  Bump both
-* counters.
-*/
-   req->nr_phys_segments += nr_phys_segs;
-   return 1;
-
-no_merge:
-   req_set_nomerge(q, req);
-   return 0;
-}
-
 int ll_back_merge_fn(struct request_queue *q, struct request *req,
 struct bio *bio)
 {
+   unsigned int seg_size;
+   int total_nr_phys_segs;
+   bool contig;
+
if (req_gap_back_merge(req, bio))
return 0;
if (blk_integrity_rq(req) &&
integrity_req_gap_back_merge(req, bio))
return 0;
if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req, blk_rq_pos(req))) {
-   req_set_nomerge(q, req);
-   return 0;
-   }
+   blk_rq_get_max_sectors(req, blk_rq_pos(req)))
+   goto no_merge;
+
if (!bio_flagged(req->biotail, BIO_SEG_VALID))
blk_recount_segments(q, req->biotail);
if (!bio_flagged(bio, BIO_SEG_VALID))
blk_recount_segments(q, bio);
 
-   return ll_new_hw_segment(q, req, bio);
+   if (blk_integrity_merge_bio(q, req, bio) == false)
+   goto no_merge;
+
+   seg_size = req->biotail->bi_seg_back_size + bio->bi_seg_front_size;
+   total_nr_phys_segs = req->nr_phys_segments + bio_phys_segments(q, bio);
+
+   contig = blk_phys_contig_segment(q, req->biotail, bio);
+   if (contig)
+   total_nr_phys_segs--;
+
+   if (unlikely(total_nr_phys_segs > queue_max_segments(q)))
+   goto no_merge;
+
+   if (contig) {
+   if (req->nr_phys_segments == 1)
+   req->bio->bi_seg_front_size = seg_size;
+   if (bio->bi_phys_segments == 1)
+   bio->bi_seg_back_size = seg_size;
+   }
+   req->nr_phys_segments = total_nr_phys_segs;
+   return 1;
+
+no_merge:
+   req_set_nomerge(q, req);
+   return 0;
 }
 
 int ll_front_merge_fn(struct request_queue *q, struct request *req,
  struct bio *bio)
 {
+   unsigned int seg_size;
+   int total_nr_phys_segs;
+   bool contig;
 
if (req_gap_front_merge(req, bio))
return 0;
@@ -527,16 +533,40 @@ int ll_front_merge_fn(struct request_queue *q, struct 
request *req,
integrity_req_gap_front_merge(req, bio))
return 0;
if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req, bio->bi_iter.bi_sector)) {
-   req_set_nomerge(q, req);
-   return 0;
-   }
+   blk_rq_get_max_sectors(req, bio->bi_iter.bi_sector))
+   goto no_merge;
+
if (!bio_flagged(bio, BIO_SEG_VALID))
blk_recount_segments(q, bio);
if (!bio_flagged(req->bio, BIO_SEG_VALID))
blk_recount_segments(q, req->bio);
 
-   return ll_new_hw_segment(q, req, bio);
+   if (blk_integrity_merge_bio(q, req, bio) == false)
+   goto no_merge;
+
+   seg_size = req->bio->bi_seg_front_size + bio->bi_seg_back_size;
+   total_nr_phys_segs = req->nr_phys_segments + bio_phys_segments(q, bio);
+
+   contig = blk_phys_contig_segment(q, bio, req->bio);
+   if (contig)
+   total_nr_phys_segs--;
+
+   if (unlikely(total_nr_phys_segs > queue_max_segments(q)))
+   goto no_merge;
+
+   if (contig) {
+   if (req->nr_phys_segments == 1)
+

[PATCH] dmaengine: edma: Align the memcpy acnt array size with the transfer

[Peter Ujfalusi]

Memory to Memory transfers does not have any special alignment needs
regarding to acnt array size, but if one of the areas are in memory mapped
regions (like PCIe memory), we need to make sure that the acnt array size
is aligned with the mem copy parameters.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 14c52574262c..2f880010297d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1169,11 +1169,24 @@ static struct dma_async_tx_descriptor 
*edma_prep_dma_memcpy(
struct edma_desc *edesc;
struct device *dev = chan->device->dev;
struct edma_chan *echan = to_edma_chan(chan);
-   unsigned int width, pset_len;
+   unsigned int width, pset_len, array_size;
 
if (unlikely(!echan || !len))
return NULL;
 
+   /* Align the array size (acnt block) with the transfer properties */
+   switch (__ffs((src | dest | len))) {
+   case 0:
+   array_size = SZ_32K - 1;
+   break;
+   case 1:
+   array_size = SZ_32K - 2;
+   break;
+   default:
+   array_size = SZ_32K - 4;
+   break;
+   }
+
if (len < SZ_64K) {
/*
 * Transfer size less than 64K can be handled with one paRAM
@@ -1195,7 +1208,7 @@ static struct dma_async_tx_descriptor 
*edma_prep_dma_memcpy(
 * When the full_length is multibple of 32767 one slot can be
 * used to complete the transfer.
 */
-   width = SZ_32K - 1;
+   width = array_size;
pset_len = rounddown(len, width);
/* One slot is enough for lengths multiple of (SZ_32K -1) */
if (unlikely(pset_len == len))
@@ -1243,7 +1256,7 @@ static struct dma_async_tx_descriptor 
*edma_prep_dma_memcpy(
}
dest += pset_len;
src += pset_len;
-   pset_len = width = len % (SZ_32K - 1);
+   pset_len = width = len % array_size;
 
ret = edma_config_pset(chan, &edesc->pset[1], src, dest, 1,
   width, pset_len, DMA_MEM_TO_MEM);
-- 
2.14.1


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH] Revert "PCI: Avoid race while enabling upstream bridges"

[Bjorn Helgaas]

This reverts commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9.

Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon,
gen4:

  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed 
with error -2
  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed 
with error -2
  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed 
with error -2
  iwlwifi :04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
  iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
  ...
  iwlwifi :04:00.0: Failed to load firmware chunk!
  iwlwifi :04:00.0: Could not load the [0] uCode section
  iwlwifi :04:00.0: Failed to start INIT ucode: -110
  iwlwifi :04:00.0: Failed to run INIT ucode: -110

He bisected it to 40f11adc7cd9 ("PCI: Avoid race while enabling upstream
bridges").  Revert that commit to fix the regression.

Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6...@kernel.dk
Fixes: 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges")
Signed-off-by: Bjorn Helgaas 
CC: Srinath Mannam 
CC: Jens Axboe 
CC: Luca Coelho 
CC: Johannes Berg 
CC: Emmanuel Grumbach 
---
 drivers/pci/pci.c |   13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b0002daa50f3..6078dfc11b11 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -52,7 +52,6 @@ static void pci_pme_list_scan(struct work_struct *work);
 static LIST_HEAD(pci_pme_list);
 static DEFINE_MUTEX(pci_pme_list_mutex);
 static DECLARE_DELAYED_WORK(pci_pme_work, pci_pme_list_scan);
-static DEFINE_MUTEX(pci_bridge_mutex);
 
 struct pci_pme_device {
struct list_head list;
@@ -1351,16 +1350,10 @@ static void pci_enable_bridge(struct pci_dev *dev)
if (bridge)
pci_enable_bridge(bridge);
 
-   /*
-* Hold pci_bridge_mutex to prevent a race when enabling two
-* devices below the bridge simultaneously.  The race may cause a
-* PCI_COMMAND_MEMORY update to be lost (see changelog).
-*/
-   mutex_lock(&pci_bridge_mutex);
if (pci_is_enabled(dev)) {
if (!dev->is_busmaster)
pci_set_master(dev);
-   goto end;
+   return;
}
 
retval = pci_enable_device(dev);
@@ -1368,8 +1361,6 @@ static void pci_enable_bridge(struct pci_dev *dev)
dev_err(&dev->dev, "Error enabling bridge (%d), continuing\n",
retval);
pci_set_master(dev);
-end:
-   mutex_unlock(&pci_bridge_mutex);
 }
 
 static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
@@ -1394,7 +1385,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, 
unsigned long flags)
return 0;   /* already enabled */
 
bridge = pci_upstream_bridge(dev);
-   if (bridge && !pci_is_enabled(bridge))
+   if (bridge)
pci_enable_bridge(bridge);
 
/* only skip sriov related */

Re: [Outreachy kernel] [PATCH] gpu: drm: rockchip: Replace dev_* with DRM_DEV_*

[Joe Perches]

On Fri, 2017-09-15 at 08:58 +0200, Julia Lawall wrote:
> 
> On Fri, 15 Sep 2017, Haneen Mohammed wrote:
> 
> > This patch replace instances of dev_info/err/debug with
> > DRM_DEV_INFO/ERROR/WARN respectively inorder to use a drm-formatted
> > specific log messages. Issue corrected with the help of the following
> > Coccinelle script:
[]
> > @@ -935,7 +941,8 @@ static void dw_mipi_dsi_encoder_disable(struct 
> > drm_encoder *encoder)
> > return;
> > 
> > if (clk_prepare_enable(dsi->pclk)) {
> > -   dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
> > +   DRM_DEV_ERROR(dsi->dev,
> > + "%s: Failed to enable pclk\n", __func__);

The uses of "%s: " ... , __func__ with DRM_DEV_ERROR
is redundant and should be removed.

> > @@ -967,7 +974,8 @@ static void dw_mipi_dsi_encoder_enable(struct 
> > drm_encoder *encoder)
> > return;
> > 
> > if (clk_prepare_enable(dsi->pclk)) {
> > -   dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
> > +   DRM_DEV_ERROR(dsi->dev,
> > + "%s: Failed to enable pclk\n", __func__);

etc...

[PATCH v3 2/2] spi: Add ADI driver for Spreadtrum platform

[Baolin Wang]

This patch adds ADI driver based on SPI framework for
Spreadtrum SC9860 platform.

Signed-off-by: Baolin Wang 
---
Changes since v2:
 - Remove the MIT license.

Changes since v1:
 - Add COMPILE_TEST config as dependency.
 - Remove spi_controller_put() function when removing driver.
 - Change to module_init() level.
---
 drivers/spi/Kconfig|6 +
 drivers/spi/Makefile   |1 +
 drivers/spi/spi-sprd-adi.c |  419 
 3 files changed, 426 insertions(+)
 create mode 100644 drivers/spi/spi-sprd-adi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9b31351..fbdced7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -627,6 +627,12 @@ config SPI_SIRF
help
  SPI driver for CSR SiRFprimaII SoCs
 
+config SPI_SPRD_ADI
+   tristate "Spreadtrum ADI controller"
+   depends on ARCH_SPRD || COMPILE_TEST
+   help
+ ADI driver based on SPI for Spreadtrum SoCs.
+
 config SPI_STM32
tristate "STMicroelectronics STM32 SPI controller"
depends on ARCH_STM32 || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index a3ae2b7..de5ae2a 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
 obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
 obj-$(CONFIG_SPI_SH_SCI)   += spi-sh-sci.o
 obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
+obj-$(CONFIG_SPI_SPRD_ADI) += spi-sprd-adi.o
 obj-$(CONFIG_SPI_STM32)+= spi-stm32.o
 obj-$(CONFIG_SPI_ST_SSC4)  += spi-st-ssc4.o
 obj-$(CONFIG_SPI_SUN4I)+= spi-sun4i.o
diff --git a/drivers/spi/spi-sprd-adi.c b/drivers/spi/spi-sprd-adi.c
new file mode 100644
index 000..0d481f8
--- /dev/null
+++ b/drivers/spi/spi-sprd-adi.c
@@ -0,0 +1,419 @@
+/*
+ * Copyright (C) 2017 Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Registers definitions for ADI controller */
+#define REG_ADI_CTRL0  0x4
+#define REG_ADI_CHN_PRIL   0x8
+#define REG_ADI_CHN_PRIH   0xc
+#define REG_ADI_INT_EN 0x10
+#define REG_ADI_INT_RAW0x14
+#define REG_ADI_INT_MASK   0x18
+#define REG_ADI_INT_CLR0x1c
+#define REG_ADI_GSSI_CFG0  0x20
+#define REG_ADI_GSSI_CFG1  0x24
+#define REG_ADI_RD_CMD 0x28
+#define REG_ADI_RD_DATA0x2c
+#define REG_ADI_ARM_FIFO_STS   0x30
+#define REG_ADI_STS0x34
+#define REG_ADI_EVT_FIFO_STS   0x38
+#define REG_ADI_ARM_CMD_STS0x3c
+#define REG_ADI_CHN_EN 0x40
+#define REG_ADI_CHN_ADDR(id)   (0x44 + (id - 2) * 4)
+#define REG_ADI_CHN_EN10x20c
+
+/* Bits definitions for register REG_ADI_GSSI_CFG0 */
+#define BIT_CLK_ALL_ON BIT(30)
+
+/* Bits definitions for register REG_ADI_RD_DATA */
+#define BIT_RD_CMD_BUSYBIT(31)
+#define RD_ADDR_SHIFT  16
+#define RD_VALUE_MASK  GENMASK(15, 0)
+#define RD_ADDR_MASK   GENMASK(30, 16)
+
+/* Bits definitions for register REG_ADI_ARM_FIFO_STS */
+#define BIT_FIFO_FULL  BIT(11)
+#define BIT_FIFO_EMPTY BIT(10)
+
+/*
+ * ADI slave devices include RTC, ADC, regulator, charger, thermal and so on.
+ * The slave devices address offset is always 0x8000 and size is 4K.
+ */
+#define ADI_SLAVE_ADDR_SIZESZ_4K
+#define ADI_SLAVE_OFFSET   0x8000
+
+/* Timeout (ms) for the trylock of hardware spinlocks */
+#define ADI_HWSPINLOCK_TIMEOUT 5000
+/*
+ * ADI controller has 50 channels including 2 software channels
+ * and 48 hardware channels.
+ */
+#define ADI_HW_CHNS50
+
+#define ADI_FIFO_DRAIN_TIMEOUT 1000
+#define ADI_READ_TIMEOUT   2000
+#define REG_ADDR_LOW_MASK  GENMASK(11, 0)
+
+struct sprd_adi {
+   struct spi_controller   *ctlr;
+   struct device   *dev;
+   void __iomem*base;
+   struct hwspinlock   *hwlock;
+   unsigned long   slave_vbase;
+   unsigned long   slave_pbase;
+};
+
+static int sprd_adi_check_paddr(struct sprd_adi *sadi, u32 paddr)
+{
+   if (paddr < sadi->slave_pbase || paddr >
+   (sadi->slave_pbase + ADI_SLAVE_ADDR_SIZE)) {
+   dev_err(sadi->dev,
+   "slave physical address is incorrect, addr = 0x%x\n",
+   paddr);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static unsigned long sprd_adi_to_vaddr(struct sprd_adi *sadi, u32 paddr)
+{
+   return (paddr - sadi->slave_pbase + sadi->slave_vbase);
+}
+
+static

[PATCH v3 1/2] dt-bindings: spi: Add Spreadtrum ADI controller documentation

[Baolin Wang]

This patch adds the binding documentation for Spreadtrum ADI
controller device.

Signed-off-by: Baolin Wang 
---
Changes since v2:
 - Add some documentation to describe how many hardware channels can be
 configured.
 - Remove "SPI framework" from binding file and other small optimization.

Changes since v1:
 - Add more documentation for the 'sprd,hw-channels' property and explain
 why need one hardware spinlock.
---
 .../devicetree/bindings/spi/spi-sprd-adi.txt   |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-sprd-adi.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt 
b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
new file mode 100644
index 000..8de589b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt
@@ -0,0 +1,58 @@
+Spreadtrum ADI controller
+
+ADI is the abbreviation of Anolog-Digital interface, which is used to access
+analog chip (such as PMIC) from digital chip. ADI controller follows the SPI
+framework for its hardware implementation is alike to SPI bus and its timing
+is compatile to SPI timing.
+
+ADI controller has 50 channels including 2 software read/write channels and
+48 hardware channels to access analog chip. For 2 software read/write channels,
+users should set ADI registers to access analog chip. For hardware channels,
+we can configure them to allow other hardware components to use it 
independently,
+which means we can just link one analog chip address to one hardware channel,
+then users can access the mapped analog chip address by this hardware channel
+triggered by hardware components instead of ADI software channels.
+
+Thus we introduce one property named "sprd,hw-channels" to configure hardware
+channels, the first value specifies the hardware channel id which is used to
+transfer data triggered by hardware automatically, and the second value 
specifies
+the analog chip address where user want to access by hardware components.
+
+Since we have multi-subsystems will use unique ADI to access analog chip, when
+one system is reading/writing data by ADI software channels, that should be 
under
+one hardware spinlock protection to prevent other systems from reading/writing
+data by ADI software channels at the same time, or two parallel routine of 
setting
+ADI registers will make ADI controller registers chaos to lead incorrect 
results.
+Then we need one hardware spinlock to synchronize between the multiple 
subsystems.
+
+Required properties:
+- compatible: Should be "sprd,sc9860-adi".
+- reg: Offset and length of ADI-SPI controller register space.
+- hwlocks: Reference to a phandle of a hwlock provider node.
+- hwlock-names: Reference to hwlock name strings defined in the same order
+   as the hwlocks, should be "adi".
+- #address-cells: Number of cells required to define a chip select address
+   on the ADI-SPI bus. Should be set to 1.
+- #size-cells: Size of cells required to define a chip select address size
+   on the ADI-SPI bus. Should be set to 0.
+
+Optional properties:
+- sprd,hw-channels: This is an array of channel values up to 49 channels.
+   The first value specifies the hardware channel id which is used to
+   transfer data triggered by hardware automatically, and the second
+   value specifies the analog chip address where user want to access
+   by hardware components.
+
+SPI slave nodes must be children of the SPI controller node and can contain
+properties described in Documentation/devicetree/bindings/spi/spi-bus.txt.
+
+Example:
+   adi_bus: spi@4003 {
+   compatible = "sprd,sc9860-adi";
+   reg = <0 0x4003 0 0x1>;
+   hwlocks = <&hwlock1 0>;
+   hwlock-names = "adi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   sprd,hw-channels = <30 0x8c20>;
+   };
-- 
1.7.9.5

Re: [GIT PULL] overlayfs update for 4.14

[Miklos Szeredi]

On Thu, Sep 14, 2017 at 01:24:22PM -0700, Linus Torvalds wrote:

> I just don't see any reason why those two "flags" arguments are separate.

Fine.  Here's a patch reverting the new flags and adding O_UPPER.

Thanks,
Miklos
---

From: Miklos Szeredi 
Subject: vfs: d_real: merge flags and open_flags

Remove the second "flags" argument of d_real().  The remaining flags are
now used by:

  - open() to pass the open flags, which lets us decide whether the file
needs to be copied up or not

  - by the VFS when it needs to check if dentry in question is writable
(i.e. pass O_UPPER, which returns upper dentry or NULL)

Signed-off-by: Miklos Szeredi 
---
 Documentation/filesystems/Locking |2 +-
 Documentation/filesystems/vfs.txt |2 +-
 fs/inode.c|2 +-
 fs/namespace.c|2 +-
 fs/open.c |4 ++--
 fs/overlayfs/super.c  |   12 ++--
 include/linux/dcache.h|   17 -
 include/linux/fcntl.h |   11 +++
 include/linux/fs.h|2 +-
 9 files changed, 32 insertions(+), 22 deletions(-)

--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -22,7 +22,7 @@ be able to use diff(1).
struct vfsmount *(*d_automount)(struct path *path);
int (*d_manage)(const struct path *, bool);
struct dentry *(*d_real)(struct dentry *, const struct inode *,
-unsigned int, unsigned int);
+unsigned int);
 
 locking rules:
rename_lock ->d_lockmay block   rcu-walk
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -988,7 +988,7 @@ struct dentry_operations {
struct vfsmount *(*d_automount)(struct path *);
int (*d_manage)(const struct path *, bool);
struct dentry *(*d_real)(struct dentry *, const struct inode *,
-unsigned int, unsigned int);
+unsigned int);
 };
 
   d_revalidate: called when the VFS needs to revalidate a dentry. This
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1578,7 +1578,7 @@ static void update_ovl_inode_times(struc
if (rcu || likely(!(dentry->d_flags & DCACHE_OP_REAL)))
return;
 
-   upperdentry = d_real(dentry, NULL, 0, D_REAL_UPPER);
+   upperdentry = d_real(dentry, NULL, O_UPPER);
 
/*
 * If file is on lower then we can't update atime, so no worries about
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -467,7 +467,7 @@ static inline int may_write_real(struct
return 0;
 
/* File refers to upper, writable layer? */
-   upperdentry = d_real(dentry, NULL, 0, D_REAL_UPPER);
+   upperdentry = d_real(dentry, NULL, O_UPPER);
if (upperdentry && file_inode(file) == d_inode(upperdentry))
return 0;
 
--- a/fs/open.c
+++ b/fs/open.c
@@ -96,7 +96,7 @@ long vfs_truncate(const struct path *pat
 * write access on the upper inode, not on the overlay inode.  For
 * non-overlay filesystems d_real() is an identity function.
 */
-   upperdentry = d_real(path->dentry, NULL, O_WRONLY, 0);
+   upperdentry = d_real(path->dentry, NULL, O_WRONLY);
error = PTR_ERR(upperdentry);
if (IS_ERR(upperdentry))
goto mnt_drop_write_and_out;
@@ -857,7 +857,7 @@ EXPORT_SYMBOL(file_path);
 int vfs_open(const struct path *path, struct file *file,
 const struct cred *cred)
 {
-   struct dentry *dentry = d_real(path->dentry, NULL, file->f_flags, 0);
+   struct dentry *dentry = d_real(path->dentry, NULL, file->f_flags);
 
if (IS_ERR(dentry))
return PTR_ERR(dentry);
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -70,12 +70,12 @@ static int ovl_check_append_only(struct
 
 static struct dentry *ovl_d_real(struct dentry *dentry,
 const struct inode *inode,
-unsigned int open_flags, unsigned int flags)
+unsigned int flags)
 {
struct dentry *real;
int err;
 
-   if (flags & D_REAL_UPPER)
+   if (flags & O_UPPER)
return ovl_dentry_upper(dentry);
 
if (!d_is_reg(dentry)) {
@@ -84,8 +84,8 @@ static struct dentry *ovl_d_real(struct
goto bug;
}
 
-   if (open_flags) {
-   err = ovl_open_maybe_copy_up(dentry, open_flags);
+   if (flags) {
+   err = ovl_open_maybe_copy_up(dentry, flags);
if (err)
return ERR_PTR(err);
}
@@ -93,7 +93,7 @@ static struct dentry *ovl_d_real(struct
real = ovl_dentry_upper(dentry);
if (real && (!inode || inode == d_inode(real))) {
if (!inode) {
-   err = ovl_check_append_only(d_inode(real), open_flags);
+

Re: [PATCH] intel-wmi-thunderbolt: fix some error cases

[Darren Hart]

On Thu, Sep 14, 2017 at 01:41:55AM -0500, Mario Limonciello wrote:
> These were raised by Lukas Wunner as potential DOS attacks against
> the system log by passing bad data to sysfs.
> 
> Signed-off-by: Mario Limonciello 

Queued for review/testing with a minor subject change.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] gpu: drm: rockchip: Replace dev_* with DRM_DEV_*

[Mark yao]

Change the tile to:
drm/rockchip: Replace dev_* with DRM_DEV_*

Thanks.
On 2017年09月15日 14:47, Haneen Mohammed wrote:

This patch replace instances of dev_info/err/debug with
DRM_DEV_INFO/ERROR/WARN respectively inorder to use a drm-formatted
specific log messages. Issue corrected with the help of the following
Coccinelle script:

@r@
@@

(
-dev_info
+DRM_DEV_INFO
|
-dev_err
+DRM_DEV_ERROR
|
-dev_dbg
+DRM_DEV_DEBUG
)

Signed-off-by: Haneen Mohammed 
---
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 26 +++
  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  2 +-
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 90 ++---
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 19 +++---
  drivers/gpu/drm/rockchip/inno_hdmi.c| 14 ++--
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 12 ++--
  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  8 ++-
  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c   | 18 +++--
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 -
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  2 +-
  10 files changed, 125 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 9606121..4d3f6ad 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -88,7 +88,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, 
bool enabled)
if (!analogix_dp_psr_supported(dp->dev))
return;
  
-	dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");

+   DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
  
  	spin_lock_irqsave(&dp->psr_lock, flags);

if (enabled)
@@ -110,7 +110,7 @@ static void analogix_dp_psr_work(struct work_struct *work)
ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
 PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
-   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
return;
}
  
@@ -140,13 +140,13 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
  
  	ret = clk_prepare_enable(dp->pclk);

if (ret < 0) {
-   dev_err(dp->dev, "failed to enable pclk %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
return ret;
}
  
  	ret = rockchip_dp_pre_init(dp);

if (ret < 0) {
-   dev_err(dp->dev, "failed to dp pre init %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to dp pre init %d\n", ret);
clk_disable_unprepare(dp->pclk);
return ret;
}
@@ -211,17 +211,17 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
else
val = dp->data->lcdsel_big;
  
-	dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");

+   DRM_DEV_DEBUG(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
  
  	ret = clk_prepare_enable(dp->grfclk);

if (ret < 0) {
-   dev_err(dp->dev, "failed to enable grfclk %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to enable grfclk %d\n", ret);
return;
}
  
  	ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);

if (ret != 0)
-   dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
  
  	clk_disable_unprepare(dp->grfclk);

  }
@@ -277,7 +277,7 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
  
  	dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");

if (IS_ERR(dp->grf)) {
-   dev_err(dev, "failed to get rockchip,grf property\n");
+   DRM_DEV_ERROR(dev, "failed to get rockchip,grf property\n");
return PTR_ERR(dp->grf);
}
  
@@ -287,31 +287,31 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)

} else if (PTR_ERR(dp->grfclk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
} else if (IS_ERR(dp->grfclk)) {
-   dev_err(dev, "failed to get grf clock\n");
+   DRM_DEV_ERROR(dev, "failed to get grf clock\n");
return PTR_ERR(dp->grfclk);
}
  
  	dp->pclk = devm_clk_get(dev, "pclk");

if (IS_ERR(dp->pclk)) {
-   dev_err(dev, "failed to get pclk property\n");
+   DRM_DEV_ERROR(dev, "failed to get pclk property\n");
return PTR_ERR(dp->pclk);
}
  
  	dp->rst = devm_reset_control_get(dev, "dp");

if (IS_ERR(dp->rst)) {
-   dev_err(dev, "failed to get dp reset control\n");
+   DRM_DEV_ERROR(dev, "failed to get dp reset control\n");
return PTR_ERR(dp->rst);
}
  
  	ret = clk_prep

Re: [PATCH v3] Add driver to force WMI Thunderbolt controller power status

[Lukas Wunner]

On Thu, Sep 14, 2017 at 05:59:19PM +0300, Mika Westerberg wrote:
> On Thu, Sep 14, 2017 at 02:52:27PM +, mario.limoncie...@dell.com wrote:
> > > Looking at drivers/platform/x86/wmi.c:wmi_dev_uevent() it seems that
> > > a modalias consisting of "wmi:" followed by the GUID is sent to udevd.
> > > For udevd to then load the module, I suspect you need to add a
> > > MODULE_DEVICE_TABLE(wmi, ...) to your driver.
> > 
> > Ah, you're looking for this code from the WMI bus driver:
> > https://github.com/torvalds/linux/blob/master/drivers/platform/x86/wmi.c#L724
> > 
> > That happens when the bus is initialized.
> 
> That's right you get the uevent and whatnot but Lucas means that if you
> don't have MODULE_DEVICE_TABLE(wmi, ...) in the driver, udev cannot load
> the module automatically when the device appears.

Digging a bit deeper I notice the wmi drivers seem to solve this by
directly declaring a MODULE_ALIAS(), which is also present in Mario's
driver.  Mario, have you tested if auto-loading works if compiled as
a module?  If so, sorry for the noise.

Thanks,

Lukas

[PATCH 0/9] [media] TM6000: Adjustments for some function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 15 Sep 2017 08:24:56 +0200

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (9):
  Delete seven error messages for a failed memory allocation
  Adjust seven checks for null pointers
  Use common error handling code in tm6000_usb_probe()
  One function call less in tm6000_usb_probe() after error detection
  Delete an unnecessary variable initialisation in tm6000_usb_probe()
  Use common error handling code in tm6000_cards_setup()
  Improve a size determination in dvb_init()
  Use common error handling code in tm6000_start_stream()
  Use common error handling code in tm6000_prepare_isoc()

 drivers/media/usb/tm6000/tm6000-cards.c | 36 -
 drivers/media/usb/tm6000/tm6000-dvb.c   | 24 +++---
 drivers/media/usb/tm6000/tm6000-input.c |  2 +-
 drivers/media/usb/tm6000/tm6000-video.c | 30 +++
 4 files changed, 42 insertions(+), 50 deletions(-)

-- 
2.14.1

[PATCH 1/9] [media] tm6000: Delete seven error messages for a failed memory allocation

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 14 Sep 2017 14:34:39 +0200

Omit extra messages for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-cards.c |  1 -
 drivers/media/usb/tm6000/tm6000-dvb.c   |  5 +
 drivers/media/usb/tm6000/tm6000-video.c | 13 +++--
 3 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index 2537643a1808..817bae8cb6a1 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -1210,4 +1210,3 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
-   printk(KERN_ERR "tm6000" ": out of memory!\n");
usb_put_dev(usbdev);
return -ENOMEM;
}
diff --git a/drivers/media/usb/tm6000/tm6000-dvb.c 
b/drivers/media/usb/tm6000/tm6000-dvb.c
index 097ac321b7e1..61a4e0a52716 100644
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -137,5 +137,4 @@ static int tm6000_start_stream(struct tm6000_core *dev)
usb_free_urb(dvb->bulk_urb);
-   printk(KERN_ERR "tm6000: couldn't allocate transfer buffer!\n");
return -ENOMEM;
}
 
@@ -403,7 +402,5 @@ static int dvb_init(struct tm6000_core *dev)
-   if (!dvb) {
-   printk(KERN_INFO "Cannot allocate memory\n");
+   if (!dvb)
return -ENOMEM;
-   }
 
dev->dvb = dvb;
 
diff --git a/drivers/media/usb/tm6000/tm6000-video.c 
b/drivers/media/usb/tm6000/tm6000-video.c
index ec8c4d2534dc..701494e72edc 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -477,13 +477,9 @@ static int tm6000_alloc_urb_buffers(struct tm6000_core 
*dev)
-   if (!dev->urb_buffer) {
-   tm6000_err("cannot allocate memory for urb buffers\n");
+   if (!dev->urb_buffer)
return -ENOMEM;
-   }
 
dev->urb_dma = kmalloc(sizeof(dma_addr_t *)*num_bufs, GFP_KERNEL);
-   if (!dev->urb_dma) {
-   tm6000_err("cannot allocate memory for urb dma pointers\n");
+   if (!dev->urb_dma)
return -ENOMEM;
-   }
 
for (i = 0; i < num_bufs; i++) {
dev->urb_buffer[i] = usb_alloc_coherent(
@@ -601,12 +597,9 @@ static int tm6000_prepare_isoc(struct tm6000_core *dev)
-   if (!dev->isoc_ctl.urb) {
-   tm6000_err("cannot alloc memory for usb buffers\n");
+   if (!dev->isoc_ctl.urb)
return -ENOMEM;
-   }
 
dev->isoc_ctl.transfer_buffer = kmalloc(sizeof(void *)*num_bufs,
   GFP_KERNEL);
if (!dev->isoc_ctl.transfer_buffer) {
-   tm6000_err("cannot allocate memory for usbtransfer\n");
kfree(dev->isoc_ctl.urb);
return -ENOMEM;
}
-- 
2.14.1

[PATCH 2/9] [media] tm6000: Adjust seven checks for null pointers

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 14 Sep 2017 14:51:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script “checkpatch.pl” pointed information out like the following.

Comparison to NULL could be written …

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-cards.c | 2 +-
 drivers/media/usb/tm6000/tm6000-dvb.c   | 6 +++---
 drivers/media/usb/tm6000/tm6000-input.c | 2 +-
 drivers/media/usb/tm6000/tm6000-video.c | 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index 817bae8cb6a1..ef37fb1f05e4 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -1206,7 +1206,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
 
/* Create and initialize dev struct */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
-   if (dev == NULL) {
+   if (!dev) {
usb_put_dev(usbdev);
return -ENOMEM;
}
diff --git a/drivers/media/usb/tm6000/tm6000-dvb.c 
b/drivers/media/usb/tm6000/tm6000-dvb.c
index 61a4e0a52716..2bc584f75f87 100644
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -123,7 +123,7 @@ static int tm6000_start_stream(struct tm6000_core *dev)
}
 
dvb->bulk_urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (dvb->bulk_urb == NULL)
+   if (!dvb->bulk_urb)
return -ENOMEM;
 
pipe = usb_rcvbulkpipe(dev->udev, 
dev->bulk_in.endp->desc.bEndpointAddress
@@ -133,7 +133,7 @@ static int tm6000_start_stream(struct tm6000_core *dev)
size = size * 15; /* 512 x 8 or 12 or 15 */
 
dvb->bulk_urb->transfer_buffer = kzalloc(size, GFP_KERNEL);
-   if (dvb->bulk_urb->transfer_buffer == NULL) {
+   if (!dvb->bulk_urb->transfer_buffer) {
usb_free_urb(dvb->bulk_urb);
return -ENOMEM;
}
@@ -360,7 +360,7 @@ static void unregister_dvb(struct tm6000_core *dev)
 {
struct tm6000_dvb *dvb = dev->dvb;
 
-   if (dvb->bulk_urb != NULL) {
+   if (dvb->bulk_urb) {
struct urb *bulk_urb = dvb->bulk_urb;
 
kfree(bulk_urb->transfer_buffer);
diff --git a/drivers/media/usb/tm6000/tm6000-input.c 
b/drivers/media/usb/tm6000/tm6000-input.c
index 91889ad9cdd7..397990afe00b 100644
--- a/drivers/media/usb/tm6000/tm6000-input.c
+++ b/drivers/media/usb/tm6000/tm6000-input.c
@@ -352,7 +352,7 @@ static int __tm6000_ir_int_start(struct rc_dev *rc)
dprintk(1, "IR max size: %d\n", size);
 
ir->int_urb->transfer_buffer = kzalloc(size, GFP_ATOMIC);
-   if (ir->int_urb->transfer_buffer == NULL) {
+   if (!ir->int_urb->transfer_buffer) {
usb_free_urb(ir->int_urb);
return err;
}
diff --git a/drivers/media/usb/tm6000/tm6000-video.c 
b/drivers/media/usb/tm6000/tm6000-video.c
index 701494e72edc..0d45f35e1697 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -470,7 +470,7 @@ static int tm6000_alloc_urb_buffers(struct tm6000_core *dev)
int num_bufs = TM6000_NUM_URB_BUF;
int i;
 
-   if (dev->urb_buffer != NULL)
+   if (dev->urb_buffer)
return 0;
 
dev->urb_buffer = kmalloc(sizeof(void *)*num_bufs, GFP_KERNEL);
@@ -503,7 +503,7 @@ static int tm6000_free_urb_buffers(struct tm6000_core *dev)
 {
int i;
 
-   if (dev->urb_buffer == NULL)
+   if (!dev->urb_buffer)
return 0;
 
for (i = 0; i < TM6000_NUM_URB_BUF; i++) {
-- 
2.14.1

Re: [PATCH] net: phy: Fix mask value write on gmii2rgmii converter speed register.

[Michal Simek]

On 14.9.2017 16:34, Andrew Lunn wrote:
> On Thu, Sep 14, 2017 at 12:46:31PM +0530, Fahad Kunnathadi wrote:
>> To clear Speed Selection in MDIO control register(0x10),
>> ie, clear bits 6 and 13 to zero while keeping other bits same.
>> Before AND operation,The Mask value has to be perform with bitwise NOT
>> operation (ie, ~ operator)
>>
>> This patch clears current speed selection before writing the
>> new speed settings to gmii2rgmii converter
> 
> Hi Fahad
> 
> I expect you will find other issues with this driver. I pointed some
> out at the time it is submitted, but the developers went quiet as soon
> as it was accepted.

Can you please point me to that email?
I will create ticket about it in our system to get them resolved.

Thanks,
Michal

[PATCH v5 1/2] media:imx274 device tree binding file

[Leon Luo]

The binding file for imx274 CMOS sensor V4l2 driver

Signed-off-by: Leon Luo 
---
v5:
 - add 'port' and 'endpoint' information
v4:
 - no changes
v3:
 - remove redundant properties and references
 - document 'reg' property
v2:
 - no changes
---
 .../devicetree/bindings/media/i2c/imx274.txt   | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/imx274.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/imx274.txt 
b/Documentation/devicetree/bindings/media/i2c/imx274.txt
new file mode 100644
index ..80f2e89568e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imx274.txt
@@ -0,0 +1,33 @@
+* Sony 1/2.5-Inch 8.51Mp CMOS Digital Image Sensor
+
+The Sony imx274 is a 1/2.5-inch CMOS active pixel digital image sensor with
+an active array size of 3864H x 2202V. It is programmable through I2C
+interface. The I2C address is fixed to 0x1a as per sensor data sheet.
+Image data is sent through MIPI CSI-2, which is configured as 4 lanes
+at 1440 Mbps.
+
+
+Required Properties:
+- compatible: value should be "sony,imx274" for imx274 sensor
+- reg: I2C bus address of the device
+
+Optional Properties:
+- reset-gpios: Sensor reset GPIO
+
+The imx274 device node should contain one 'port' child node with
+an 'endpoint' subnode. For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   sensor@1a {
+   compatible = "sony,imx274";
+   reg = <0x1a>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reset-gpios = <&gpio_sensor 0 0>;
+   port {
+   sensor_out: endpoint {
+   remote-endpoint = <&csiss_in>;
+   };
+   };
+   };
-- 
2.14.0.rc1

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

[Thomas Gleixner]

On Fri, 15 Sep 2017, kernel test robot wrote:
> [0.035023] CPU: Intel Common KVM processor (family: 0xf, model: 0x6, 
> stepping: 0x1)
> [0.042302] Performance Events: unsupported Netburst CPU model 6 no PMU 
> driver, software events only.

Cute. So there is no supported PMU, but for some unknown reason the lockup
detector can create an event, otherwise the perf availaibility check in
lockup_detector_init() would fail 

Peter???

> [0.051650] BUG: unable to handle kernel NULL pointer dereference at 
> 0208
> [0.052000] IP: perf_event_release_kernel+0x14/0x1ed
> [0.052000] PGD 0 P4D 0 
> [0.052000] Oops:  [#1]
> [0.052000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.13.0-11828-gd57108d 
> #1
> [0.052000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.9.3-20161025_171302-gandalf 04/01/2014
> [0.052000] task: 88001e532000 task.stack: c9008000
> [0.052000] RIP: 0010:perf_event_release_kernel+0x14/0x1ed
> [0.052000] RSP: :c900be38 EFLAGS: 00010292
> [0.052000] RAX: 0001 RBX:  RCX: 
> 0313fa45
> [0.052000] RDX: 0001 RSI: 828265e0 RDI: 
> 
> [0.052000] RBP: c900beb8 R08: c900bdc8 R09: 
> 
> [0.052000] R10: 88001e532000 R11: c900bd68 R12: 
> 
> [0.052000] R13:  R14:  R15: 
> 
> [0.052000] FS:  () GS:8262f000() 
> knlGS:
> [0.052000] CS:  0010 DS:  ES:  CR0: 80050033
> [0.052000] CR2: 0208 CR3: 02618000 CR4: 
> 06b0
> [0.052000] Call Trace:
> [0.052000]  ? trace_hardirqs_on_caller+0x162/0x198
> [0.052000]  hardlockup_detector_perf_cleanup+0x20/0x2d
> [0.052000]  __lockup_detector_cleanup+0x2c/0x2e
> [0.052000]  softlockup_update_smpboot_threads+0x48/0x4a
> [0.052000]  softlockup_reconfigure_threads+0x21/0x5a
> [0.052000]  lockup_detector_init+0x75/0x83
> [0.052000]  kernel_init_freeable+0x67/0xf0
> [0.052000]  ? rest_init+0x13a/0x13a
> [0.052000]  kernel_init+0xe/0xf8
> [0.052000]  ret_from_fork+0x2a/0x40
> [0.052000] Code: df e8 0c b2 ff ff 4c 89 e7 e8 89 13 bd 00 41 5b 5b 41 5c 
> 41 5d c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 58 <48> 
> 83 bf 08 02 00 00 00 75 14 f6 87 8c 00 00 00 03 0f 84 9b 01 
> [0.052000] RIP: perf_event_release_kernel+0x14/0x1ed RSP: c900be38
> [0.052000] CR2: 0208
> [0.052000] ---[ end trace ed0d2c92e47d08db ]---
> [0.052000] Kernel panic - not syncing: Fatal exception

[PATCH v5 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

[Leon Luo]

The imx274 is a Sony CMOS image sensor that has 1/2.5 image size.
It supports up to 3840x2160 (4K) 60fps, 1080p 120fps. The interface
is 4-lane MIPI CSI-2 running at 1.44Gbps each.

This driver has been tested on Xilinx ZCU102 platform with a Leopard
LI-IMX274MIPI-FMC camera board.

Support for the following features:
-Resolutions: 3840x2160, 1920x1080, 1280x720
-Frame rate: 3840x2160 : 5 – 60fps
1920x1080 : 5 – 120fps
1280x720 : 5 – 120fps
-Exposure time: 16 – (frame interval) micro-seconds
-Gain: 1x - 180x
-VFLIP: enable/disabledrivers/media/i2c/imx274.c
-Test pattern: 12 test patterns

Signed-off-by: Leon Luo 
Tested-by: Sören Brinkmann 
---
v5:
 - no changes
v4:
 - use 32-bit data type to avoid __divdi3 compile error for i386
 - clean up OR together error codes
v3:
 - clean up header files
 - use struct directly instead of alias #define
 - use v4l2_ctrl_s_ctrl instead of v4l2_s_ctrl
 - revise debug output
 - move static helpers closer to their call site
 - don't OR toegether error codes
 - use closest valid gain value instead of erroring out
 - assigne lock to the control handler and omit explicit locking
 - acquire mutex lock for imx274_get_fmt
 - remove format->pad check in imx274_set_fmt since the pad is always 0
 - pass struct v4l2_ctrl pointer in gain/exposure/vlip/test pattern controls
 - remove priv->ctrls.vflip->val = val in imx274_set_vflip()
 - remove priv->ctrls.test_pattern->val = val in imx274_set_test_pattern()
 - remove empty open/close callbacks
 - remove empty core ops
 - add more error labels in probe
 - use v4l2_async_unregister_subdev instead of v4l2_device_unregister_subdev
 - use dynamic debug
 - split start_stream to two steps: imx274_mode_regs() and imx274_start_stream()
   frame rate & exposure can be updated
   between imx274_mode_regs() & imx274_start_stream()

v2:
 - Fix Kconfig to not remove existing options
---
 drivers/media/i2c/Kconfig  |7 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx274.c | 1808 
 3 files changed, 1816 insertions(+)
 create mode 100644 drivers/media/i2c/imx274.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 94153895fcd4..ad2e70a02363 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -547,6 +547,13 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX274
+   tristate "Sony IMX274 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a V4L2 sensor-level driver for the Sony IMX274
+ CMOS image sensor.
+
 config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c843c181dfb9..f8d57e453936 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -92,5 +92,6 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
new file mode 100644
index ..66cbfa81c030
--- /dev/null
+++ b/drivers/media/i2c/imx274.c
@@ -0,0 +1,1808 @@
+/*
+ * imx274.c - IMX274 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2017, Leopard Imaging, Inc.
+ *
+ * Leon Luo 
+ * Edwin Zou 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * See "SHR, SVR Setting" in datasheet
+ */
+#define IMX274_DEFAULT_FRAME_LENGTH(4550)
+#define IMX274_MAX_FRAME_LENGTH(0x000f)
+
+/*
+ * See "Frame Rate Adjustment" in datasheet
+ */
+#define IMX274_PIXCLK_CONST1   (7200)
+#define IMX274_PIXCLK_CONST2   (100)
+
+/*
+ * The input gain is shifted by IMX274_GAIN_SHIFT to get
+ * decimal number. The real gain is
+ * (float)input_gain_value / (1 << IMX274_GAIN_SHIFT)
+ */
+#define IMX274_GAIN_SHIFT  (8)
+#define IMX274_GAIN_SHIFT_MASK ((1 << IMX274_GAIN_SHIFT) - 1)
+
+/*
+ * See "Analog Gain" a

[PATCH 3/9] [media] tm6000: Use common error handling code in tm6000_usb_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 14 Sep 2017 16:00:47 +0200

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

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-cards.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index ef37fb1f05e4..e18632056976 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -1200,15 +1200,15 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
nr = find_first_zero_bit(&tm6000_devused, TM6000_MAXBOARDS);
if (nr >= TM6000_MAXBOARDS) {
printk(KERN_ERR "tm6000: Supports only %i tm60xx boards.\n", 
TM6000_MAXBOARDS);
-   usb_put_dev(usbdev);
-   return -ENOMEM;
+   rc = -ENOMEM;
+   goto put_device;
}
 
/* Create and initialize dev struct */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
-   usb_put_dev(usbdev);
-   return -ENOMEM;
+   rc = -ENOMEM;
+   goto put_device;
}
spin_lock_init(&dev->slock);
mutex_init(&dev->usb_lock);
@@ -1331,9 +1331,10 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
printk(KERN_ERR "tm6000: Error %d while registering\n", rc);
 
clear_bit(nr, &tm6000_devused);
-   usb_put_dev(usbdev);
 
kfree(dev);
+put_device:
+   usb_put_dev(usbdev);
return rc;
 }
 
-- 
2.14.1

[PATCH 4/9] [media] tm6000: One function call less in tm6000_usb_probe() after error detection

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 14 Sep 2017 16:11:55 +0200

* Adjust jump targets so that the function "kfree" will be always called
  with a non-null pointer.

* Delete an initialisation for the local variable "dev"
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-cards.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index e18632056976..77347541904d 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -1184,7 +1184,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
const struct usb_device_id *id)
 {
struct usb_device *usbdev;
-   struct tm6000_core *dev = NULL;
+   struct tm6000_core *dev;
int i, rc = 0;
int nr = 0;
char *speed;
@@ -1194,7 +1194,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
/* Selects the proper interface */
rc = usb_set_interface(usbdev, 0, 1);
if (rc < 0)
-   goto err;
+   goto report_failure;
 
/* Check to see next free device and mark as used */
nr = find_first_zero_bit(&tm6000_devused, TM6000_MAXBOARDS);
@@ -1312,8 +1312,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
if (!dev->isoc_in.endp) {
printk(KERN_ERR "tm6000: probing error: no IN ISOC 
endpoint!\n");
rc = -ENODEV;
-
-   goto err;
+   goto free_device;
}
 
/* save our data pointer in this interface device */
@@ -1323,16 +1322,16 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
 
rc = tm6000_init_dev(dev);
if (rc < 0)
-   goto err;
+   goto free_device;
 
return 0;
 
-err:
+free_device:
+   kfree(dev);
+report_failure:
printk(KERN_ERR "tm6000: Error %d while registering\n", rc);
 
clear_bit(nr, &tm6000_devused);
-
-   kfree(dev);
 put_device:
usb_put_dev(usbdev);
return rc;
-- 
2.14.1

[PATCH 5/9] [media] tm6000: Delete an unnecessary variable initialisation in tm6000_usb_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 14 Sep 2017 16:13:56 +0200

The local variable "rc" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-cards.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index 77347541904d..72dd6b80394f 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -1185,7 +1185,7 @@ static int tm6000_usb_probe(struct usb_interface 
*interface,
 {
struct usb_device *usbdev;
struct tm6000_core *dev;
-   int i, rc = 0;
+   int i, rc;
int nr = 0;
char *speed;
 
-- 
2.14.1

[PATCH] arm64: dts: move berlin SoC files from marvell dir to synaptics dir

[Jisheng Zhang]

Move and update device tree files as part of transition from Marvell
berlin to Synaptics berlin.

The changes are to:
 * rename dts/marvell/berlin4ct.dtsi to synaptics/berlin4ct.dtsi, and
   update SoC to be "syna,berlin"
 * rename dts/marvell/berlin4ct-stb.dts to synaptics/berlin4ct-stb.dts
   and update board name string.
 * rename dts/marvell/berlin4ct-dmp.dts to synaptics/berlin4ct-dmp.dts
   and update board name string.
 * Update dts/marvell/Makefile not to build berlin dtbs

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/boot/dts/marvell/Makefile | 4 
 arch/arm64/boot/dts/synaptics/Makefile   | 7 +++
 arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts | 7 ---
 arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts | 7 ---
 arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi| 5 +++--
 5 files changed, 18 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm64/boot/dts/synaptics/Makefile
 rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts (90%)
 rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts (90%)
 rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi (98%)

diff --git a/arch/arm64/boot/dts/marvell/Makefile 
b/arch/arm64/boot/dts/marvell/Makefile
index 6cff81eeaae2..28f94a95c2fc 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -1,7 +1,3 @@
-# Berlin SoC Family
-dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
-dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
-
 # Mvebu SoC Family
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
diff --git a/arch/arm64/boot/dts/synaptics/Makefile 
b/arch/arm64/boot/dts/synaptics/Makefile
new file mode 100644
index ..e2e81dd476ad
--- /dev/null
+++ b/arch/arm64/boot/dts/synaptics/Makefile
@@ -0,0 +1,7 @@
+# Berlin SoC Family
+dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
+dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts 
b/arch/arm64/boot/dts/synaptics/berlin4ct-dmp.dts
similarity index 90%
rename from arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
rename to arch/arm64/boot/dts/synaptics/berlin4ct-dmp.dts
index fae6c6924705..8c6bef792d34 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
+++ b/arch/arm64/boot/dts/synaptics/berlin4ct-dmp.dts
@@ -1,7 +1,8 @@
 /*
+ * Copyright (C) 2017 Synaptics Incorporated
  * Copyright (C) 2015 Marvell Technology Group Ltd.
  *
- * Author: Jisheng Zhang 
+ * Author: Jisheng Zhang 
  *
  * This file is dual-licensed: you can use it either under the terms
  * of the GPLv2 or the X11 license, at your option. Note that this dual
@@ -47,8 +48,8 @@
 #include "berlin4ct.dtsi"
 
 / {
-   model = "Marvell BG4CT DMP board";
-   compatible = "marvell,berlin4ct-dmp", "marvell,berlin4ct", 
"marvell,berlin";
+   model = "Synaptics BG4CT DMP board";
+   compatible = "syna,berlin4ct-dmp", "marvell,berlin4ct-dmp", 
"marvell,berlin4ct", "marvell,berlin";
 
chosen {
stdout-path = "serial0:115200n8";
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
b/arch/arm64/boot/dts/synaptics/berlin4ct-stb.dts
similarity index 90%
rename from arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
rename to arch/arm64/boot/dts/synaptics/berlin4ct-stb.dts
index d47edad13e68..ef18bf2d3542 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
+++ b/arch/arm64/boot/dts/synaptics/berlin4ct-stb.dts
@@ -1,7 +1,8 @@
 /*
+ * Copyright (C) 2017 Synaptics Incorporated
  * Copyright (C) 2015 Marvell Technology Group Ltd.
  *
- * Author: Jisheng Zhang 
+ * Author: Jisheng Zhang 
  *
  * This file is dual-licensed: you can use it either under the terms
  * of the GPLv2 or the X11 license, at your option. Note that this dual
@@ -47,8 +48,8 @@
 #include "berlin4ct.dtsi"
 
 / {
-   model = "Marvell BG4CT STB board";
-   compatible = "marvell,berlin4ct-stb", "marvell,berlin4ct", 
"marvell,berlin";
+   model = "Synaptics BG4CT STB board";
+   compatible = "syna,berlin4ct-stb", "marvell,berlin4ct-stb", 
"marvell,berlin4ct", "marvell,berlin";
 
chosen {
stdout-path = "serial0:115200n8";
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
b/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
similarity index 98%
rename from arch/arm64/boot/dts/marvell/berlin4ct.dtsi
rename to arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
index d6b800fd26d0..642ea37a25ae 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
+++ b/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
@@ -1,7 +1,8 @@
 /*
+ * Copyright (C) 2017 Synaptics Incorporated
  * Copyright (C) 2015 Marvell Technology Group Ltd.
  *
- * Author: Jisheng Zhang 
+ * Author: Jisheng Zhang 
  *
  * This file is dual-licensed: you can use it either under the terms
  * of the

[PATCH 6/9] [media] tm6000: Use common error handling code in tm6000_cards_setup()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 14 Sep 2017 16:26:42 +0200

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

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-cards.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index 72dd6b80394f..502e0b38b7f1 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -872,15 +872,14 @@ int tm6000_cards_setup(struct tm6000_core *dev)
for (i = 0; i < 2; i++) {
rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev->gpio.tuner_reset, 0x00);
-   if (rc < 0) {
-   printk(KERN_ERR "Error %i doing tuner reset\n", 
rc);
-   return rc;
-   }
+   if (rc < 0)
+   goto report_failure;
 
msleep(10); /* Just to be conservative */
rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev->gpio.tuner_reset, 0x01);
if (rc < 0) {
+report_failure:
printk(KERN_ERR "Error %i doing tuner reset\n", 
rc);
return rc;
}
-- 
2.14.1

[PATCH] MAINTAINERS: Marvell berlin is now Synaptics berlin

[Jisheng Zhang]

Now that the dts files are moved to the new location, update the berlin
entry in the MAINTAINERS.

Signed-off-by: Jisheng Zhang 
---
 MAINTAINERS | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 209306019483..d0854bc98f24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1530,15 +1530,6 @@ ARM/MAGICIAN MACHINE SUPPORT
 M: Philipp Zabel 
 S: Maintained
 
-ARM/Marvell Berlin SoC support
-M: Jisheng Zhang 
-M: Sebastian Hesselbarth 
-L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: arch/arm/mach-berlin/
-F: arch/arm/boot/dts/berlin*
-F: arch/arm64/boot/dts/marvell/berlin*
-
 ARM/Marvell Dove/MV78xx0/Orion SOC support
 M: Jason Cooper 
 M: Andrew Lunn 
@@ -1933,6 +1924,15 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/mcoquelin/stm32.git
 N: stm32
 F: drivers/clocksource/armv7m_systick.c
 
+ARM/Synaptics Berlin SoC support
+M: Jisheng Zhang 
+M: Sebastian Hesselbarth 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-berlin/
+F: arch/arm/boot/dts/berlin*
+F: arch/arm64/boot/dts/synaptics/berlin*
+
 ARM/TANGO ARCHITECTURE
 M: Marc Gonzalez 
 L: linux-arm-ker...@lists.infradead.org
-- 
2.14.1

[PATCH 7/9] [media] tm6000: Improve a size determination in dvb_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 15 Sep 2017 07:33:24 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-dvb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/tm6000/tm6000-dvb.c 
b/drivers/media/usb/tm6000/tm6000-dvb.c
index 2bc584f75f87..855874134fcf 100644
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -398,7 +398,7 @@ static int dvb_init(struct tm6000_core *dev)
return 0;
}
 
-   dvb = kzalloc(sizeof(struct tm6000_dvb), GFP_KERNEL);
+   dvb = kzalloc(sizeof(*dvb), GFP_KERNEL);
if (!dvb)
return -ENOMEM;
 
-- 
2.14.1

[PATCH 8/9] [media] tm6000: Use common error handling code in tm6000_start_stream()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 15 Sep 2017 07:47:41 +0200

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

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-dvb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-dvb.c 
b/drivers/media/usb/tm6000/tm6000-dvb.c
index 855874134fcf..b45e54d5cab9 100644
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -134,8 +134,8 @@ static int tm6000_start_stream(struct tm6000_core *dev)
 
dvb->bulk_urb->transfer_buffer = kzalloc(size, GFP_KERNEL);
if (!dvb->bulk_urb->transfer_buffer) {
-   usb_free_urb(dvb->bulk_urb);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto free_urb;
}
 
usb_fill_bulk_urb(dvb->bulk_urb, dev->udev, pipe,
@@ -160,11 +160,14 @@ static int tm6000_start_stream(struct tm6000_core *dev)
ret);
 
kfree(dvb->bulk_urb->transfer_buffer);
-   usb_free_urb(dvb->bulk_urb);
-   return ret;
+   goto free_urb;
}
 
return 0;
+
+free_urb:
+   usb_free_urb(dvb->bulk_urb);
+   return ret;
 }
 
 static void tm6000_stop_stream(struct tm6000_core *dev)
-- 
2.14.1

Re: [PATCH] mtd: spi-nor: stm32-quadspi: avoid unintialized return code

[Ludovic BARRE]

On 09/14/2017 11:38 PM, Arnd Bergmann wrote:

On Thu, Sep 14, 2017 at 6:55 PM, Ludovic BARRE  wrote:



On 09/14/2017 05:24 PM, Geert Uytterhoeven wrote:


Hi Ludovic,

On Thu, Sep 14, 2017 at 5:13 PM, Ludovic BARRE 
wrote:


On 09/14/2017 03:38 PM, Geert Uytterhoeven wrote:

hi Arnd, Geert

sorry, I was forgot this thread while my holidays

Geert: what do you mean like "similar bugs in the future" in "If you
initialized ret at the beginning, you lose the ability to catch newly
introduced similar bugs in the future."



If you pre-initialize ret at the top, you loose the ability of the
compiler
to detect at compile-time if ret is never written to later. It will just
return
-EINVAL at runtime.

With my version, if the code is modified later and another "return ret" is
added, the compiler will detect if there's a code path that forgets
to assign a value to ret.


Ok, it's clear for me.
I favor geert's solution.
Arnd what do you think ?


I usually follow the same rule that Geert explained (and quote
https://rusty.ozlabs.org/?p=232 when I do so). In this case, there
did not seem to be much value as the variable is not used
afterwards, and I kept the 'single return statement' guideline.

In the end, either version seems totally fine to me here, so
please use Geert's if you prefer that.


thank Arnd for your answer, great link :-)
we take geert's patch.

Geert: I will acked your patch.

thanks everybody


 Arnd

[PATCH 9/9] [media] tm6000: Use common error handling code in tm6000_prepare_isoc()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 15 Sep 2017 08:02:33 +0200

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

Signed-off-by: Markus Elfring 
---
 drivers/media/usb/tm6000/tm6000-video.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-video.c 
b/drivers/media/usb/tm6000/tm6000-video.c
index 0d45f35e1697..bfdeb41ed3a1 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -602,7 +602,5 @@ static int tm6000_prepare_isoc(struct tm6000_core *dev)
-   if (!dev->isoc_ctl.transfer_buffer) {
-   kfree(dev->isoc_ctl.urb);
-   return -ENOMEM;
-   }
+   if (!dev->isoc_ctl.transfer_buffer)
+   goto free_urb;
 
dprintk(dev, V4L2_DEBUG_QUEUE, "Allocating %d x %d packets (%d bytes) 
of %d bytes each to handle %u size\n",
max_packets, num_bufs, sb_size,
@@ -616,7 +614,6 @@ static int tm6000_prepare_isoc(struct tm6000_core *dev)
tm6000_free_urb_buffers(dev);
-   kfree(dev->isoc_ctl.urb);
kfree(dev->isoc_ctl.transfer_buffer);
-   return -ENOMEM;
+   goto free_urb;
}
 
/* allocate urbs and transfer buffers */
@@ -646,6 +643,10 @@ static int tm6000_prepare_isoc(struct tm6000_core *dev)
}
 
return 0;
+
+free_urb:
+   kfree(dev->isoc_ctl.urb);
+   return -ENOMEM;
 }
 
 static int tm6000_start_thread(struct tm6000_core *dev)
-- 
2.14.1

Re: [PATCH] crypto: s5p-sss: Add HASH support for Exynos

[Krzysztof Kozlowski]

On Fri, Sep 15, 2017 at 8:10 AM, Krzysztof Kozlowski  wrote:
> On Wed, Sep 13, 2017 at 4:24 PM, Kamil Konieczny
>  wrote:
>> Hi Krzysztof,
>>
>> On 13.09.2017 15:18, Krzysztof Kozlowski wrote:
>>> On Wed, Sep 13, 2017 at 2:44 PM, Kamil Konieczny
>>>  wrote:
 Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW.
 It uses the crypto framework asynchronous hash api.
 It is based on omap-sham.c driver.
 S5P has some HW differencies and is not implemented.

 Modifications in s5p-sss:

 - Add hash supporting structures and functions.

 - Modify irq handler to handle both aes and hash signals.

 - Disable HASH in probe if Exynos PRNG is enabled.

 - Add new copyright line and new author.

 - Tested on Odroid-U3 with Exynos 4412 CPU, kernel 4.13-rc6
   with crypto run-time self test testmgr
   and with tcrypt module with: modprobe tcrypt sec=1 mode=N
   where N=402, 403, 404 (MD5, SHA1, SHA256).

 Modifications in drivers/crypto/Kconfig:

 - Select sw algorithms MD5, SHA1 and SHA256 in S5P
   as they are nedded for fallback.

 Signed-off-by: Kamil Konieczny 
 ---
  drivers/crypto/Kconfig   |6 +
  drivers/crypto/s5p-sss.c | 2062 
 +++---
  2 files changed, 1939 insertions(+), 129 deletions(-)

>>>
>>> Nice work, thanks!
>>>
>>> You need to split the patch, it is just too huge making it very
>>> difficult to review. Please split it per logically sensible
>>> improvements.
>>
>> Can you suggest how to break it up ?>
>> It is now big update, added working functionallity in one piece,
>> but I agree it can be hard to read
>> as git did some strange things,
>> like delete few aes functions (and mixing this delete with '+' lines)
>> and then adding the same aes without any change.
>
> You know the changes you want to do, you know the new architecture so
> usually it is easier for you to figure out the split.
> But few ideas:
> 1. For the problem of functions being deleted-moved without any
> changes, you can try to reorder new code so diff will not show these
> hunks. Indeed a lot diff here looks like weird matching of diff/patch.
> This definitely has to be fixed because I cannot figure out the real
> changes around existing functions (e.g. s5p_set_indata_start(),
> s5p_aes_crypt_start()).
> 2. You add debugging code - FLOW_LOG - this is one candidate to split 
> entirely.
> 3. Cleanups go to separate patch.
>
> Probably working on (1) above will bring the most benefit.

BTW, using some stable git release (not latest master) might help as well...

BR,
Krzysztof

Re: [PATCH net-next v2 01/10] net: dsa: add debugfs interface

[Egil Hjelmeland]

On 15. sep. 2017 07:51, Jiri Pirko wrote:
> Thu, Sep 14, 2017 at 11:01:32PM CEST, and...@lunn.ch wrote:
>>> Can you clarify what type of registers it is you are wanting to read?
>>> We already have ethtool which is meant to allow reading the device
>>> registers for a given netdev. As long as the port has a netdev
>>> associated it then there is no need to be getting into debugfs since
>>> we should probably just be using ethtool.
>>
>> Not all ports of a DSA switch have a netdev. This is by design. The
>> presentation we gave to Netdev 2.1 gives some of the background.
>>
>> Plus a switch has a lot of registers not associated to port. Often a
>> switch has more global registers than port registers.
>>
>>> Also as Jiri pointed out there is already devlink which would probably
>>> be a better way to get the associated information for those pieces
>>> that don't have a netdev associated with them.
>>
>> We have looked at the devlink a few times. The current dpipe code is
>> not generic enough. It makes assumptions about the architecture of the
>> switch, that it is all match/action based. The niche of top of rack
>> switches might be like that, but average switches are not.
>>
>> If dpipe was to support simple generic two dimensional tables, we
>> probably would use it.
>>
>> David suggested making a class device for DSA. It is not ideal, but we
>> are probably going to go that way.
> 
> I believe that is also big mistake.
> 
> Could you put together your requirements so we can work it out to extend
> devlink to support them?
> 
> Thanks.
> 

$ ack -i devlink Documentation/
$ ack -i dpipe Documentation/
$

How you expect new mechanisms to be taken into use with zero documentation?

To all: Why does reviewers nitpick about undocumented formatting rules, 
but not ask about documentation?

Egil

Re: [GIT PULL] overlayfs update for 4.14

[Miklos Szeredi]

On Fri, Sep 15, 2017 at 9:32 AM, Miklos Szeredi  wrote:
> On Thu, Sep 14, 2017 at 01:24:22PM -0700, Linus Torvalds wrote:
>
>> I just don't see any reason why those two "flags" arguments are separate.
>
> Fine.  Here's a patch reverting the new flags and adding O_UPPER.

And, btw. I also hate all the hacks we need to do in the VFS for the
sake of overlayfs.  It may actually end up all being removed and all
the stacking moved to overlayfs; that's something I'd really like to
look at.   All of these hacks are there because overlayfs lets the
open file be owned by the underlying filesystem, which is good for
performance and results in simpler code in overlayfs, but may not
actually be worth it.

The whole overlayfs thing started because I was looking at the union
mounts patches and seeing all the horrid vfs impacts and deciding,
that surely some of this can go into a filesystem without major loss
of performance.   The first versions had really minimal vfs impact,
but it turned out that that wasn't enough for a bunch of things to
work correctly so d_real() evolved into the beast it is now.

And we still have that issue with an fd opened for read-only and then
one opened for write, resulting in a copy-up, modification, and the
read-only fd still seeing the old data (union mounts had the same
issue, BTW).   So we need more hacks or some way to have a shared page
cache that's breakable on copy up, which does not look trivial at all.

Thanks,
Miklos

RE: [PATCH] [media] rcar_drif: fix potential uninitialized variable use

[Ramesh Shanmugasundaram]

Hi Arnd,

Thank you for the patch.

> Subject: [PATCH] [media] rcar_drif: fix potential uninitialized variable
> use
> 
> Older compilers like gcc-4.6 may run into a case that returns an
> uninitialized variable from rcar_drif_enable_rx() if that function was
> ever called with an empty cur_ch_mask:
> 
> drivers/media/platform/rcar_drif.c:658:2: error: ‘ret’ may be used
> uninitialized in this function [-Werror=uninitialized]
> 
> Newer compilers don't have that problem as they optimize the 'ret'
> variable away and just return zero in that case.
> 
> This changes the function to return -EINVAL for this particular failure,
> to make it consistent across all compiler versions.
> In case gcc gets changed to report a warning for it in the future, it's
> also a good idea to shut it up now.
> 
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203
> Signed-off-by: Arnd Bergmann 

Acked-by: Ramesh Shanmugasundaram 

Thanks,
Ramesh

Re: [RFT PATCH v2] gpiolib: allow gpio irqchip to map irqs dynamically

[Jerome Brunet]

On Tue, 2017-08-01 at 13:27 -0500, Grygorii Strashko wrote:
> 
> On 08/01/2017 03:03 AM, Jerome Brunet wrote:
> > On Tue, 2017-08-01 at 09:52 +0200, Linus Walleij wrote:
> > > On Fri, Jul 21, 2017 at 6:49 PM, Grygorii Strashko
> > >  wrote:
> > > 
> > > > Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip
> > > > in
> > > > gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ
> > > > and,
> > > > as result, leads to:
> > > >   - increasing of memory consumption for IRQ descriptors most of which
> > > > will
> > > > never ever be used (espessially on platform with a high number of
> > > > GPIOs).
> > > > (sizeof(struct irq_desc) == 256 on my tested platforms)
> > > >   - imposibility to use GPIO irqchip APIs by gpio drivers when HW
> > > > implements
> > > > GPIO IRQ functionality as IRQ crossbar/router which has only limited
> > > > number of IRQ outputs (example from [1], all GPIOs can be mapped on only
> > > > 8
> > > > IRQs).
> > 
> > Sorry, I forgot to reply to this thread until now.
> > This patch is generalization of create mapping in the gpio_to_irq, right ?
> > 
> > So the issue of mapping left lying around until the gpio driver is unloaded
> > is
> > still there ?
> 
> Yep. But this should unblock you work and allow to use static boot time IRQ
> mappings (if you'll be able to implement irq_domain hierarchy properly). 
> 
> > 
> > Having gpio_irq_prepare/gpio_irq_unprepare would solve that, I suppose
> > (Again, sorry I could not send an RFC for this yet ...)
> 
> Sry, but still do not see how it will work :( But hope you might find the way
> :) 
> Few notes to take into account:
> 
> There is no way now to know when you can release mappings and when it's safe
> to do :(,
> except when gpio driver is unloaded.
> 
> 1) drivers using GPIO IRQ directly (no gpio_to_irq() calls). IRQ can be
> shared.
> IRQ mappings will happen in platform_get_irq()/of_irq_get().
> Drivers may call request_irq/free_irq() many times using the same Linux IRQ
> number.
> Such drivers, in many cases, do not expect to call any kind of GPIO APIs.
> 
> 2) drivers using GPIO as IRQ (gpio_to_irq() calls).
> IRQ mappings will happen in gpio_to_irq(). Theoretically driver can call
> some API to dispose mappings as it knows when its safe to do, but...
> The same IRQ still can be used by another driver as shared IRQ.
> 
> Note. IRQ mappings have no refcount.

You're right. It took me a while to realise there is a (serious) flaw in my plan
 :( Thanks for pointing it out Grygorii.

I initially planned to do some refcounting in the gpio layer but that would make
no sense, as you pointed out, the irq could be shared. This refcounting would
only make sense at the irq level.

On a more general note, I wonder when is it safe for a driver to dispose of the
mapping of a possibly shared irq ? There is no way to know if the mapping is
still used somewhere else, or am I missing something again ?

> 
> Regarding, your use case - MMC issue can be WA using irq_valid_mask.
> (don't blame me it's just WA).
> 

Re: [RFC] [DVB][FRONTEND] Added a new ioctl for optimizing frontend property set operation

[Honza Petrouš]

2017-09-14 22:50 GMT+02:00 Mauro Carvalho Chehab :
> Hi Satendra,
>
> Em Thu, 14 Sep 2017 05:59:27 -0400
> Satendra Singh Thakur  escreveu:
>
>> -For setting one frontend property , one FE_SET_PROPERTY ioctl is called
>> -Since, size of struct dtv_property is 72 bytes, this ioctl requires
>> ---allocating 72 bytes of memory in user space
>> ---allocating 72 bytes of memory in kernel space
>> ---copying 72 bytes of data from user space to kernel space
>> -However, for all the properties, only 8 out of 72 bytes are used
>>  for setting the property
>
> That's true. Yet, for get, the size can be bigger, as ISDB-T can
> return statistics per layer, plus a global one.
>
>> -Four bytes are needed for specifying property type and another 4 for
>>  property value
>> -Moreover, there are 2 properties DTV_CLEAR and DTV_TUNE which use
>>  only 4 bytes for property name
>> ---They don't use property value
>> -Therefore, we have defined new short variant/forms/version of currently
>>  used structures for such 8 byte properties.
>> -This results in 89% (8*100/72) of memory saving in user and kernel space
>>  each.
>> -This also results in faster copy (8 bytes as compared to 72 bytes) from
>>  user to kernel space
>> -We have added new ioctl FE_SET_PROPERTY_SHORT which utilizes above
>>  mentioned new property structures
>> -This ioctl can co-exist with present ioctl FE_SET_PROPERTY
>> -If the apps wish to use shorter forms they can use
>>  proposed FE_SET_PROPERTY_SHORT, rest of them can continue to use
>>  current versions FE_SET_PROPERTY
>
>> -We are currently not validating incoming properties in
>>  function dtv_property_short_process_set because most of
>>  the frontend drivers in linux source are not using the
>>  method ops.set_property. Just two drivers are using it
>>  drivers/media/dvb-frontends/stv0288.c
>>  driver/media/usb/dvb-usb/friio-fe.c
>>  -Moreover, stv0288 driver implemments blank function
>>  for set_property.
>> -If needed in future, we can define a new
>>  ops.set_property_short method to support
>>  struct dtv_property_short.
>
> Nah. Better to just get rid of get_property()/set_froperty() for good.
>
> Just sent a RFC patch series doing that.
>
> The only thing is that stv6110 seems to have a dirty hack that may
> depend on that. Someone need to double-check if the patch series
> I just sent doesn't break anything. If it breaks, then we'll need
> to add an extra parameter to stv6110 attach for it to know what
> behavior is needed there.

Do you mean in stv6110_set_frequency()?

I must say I was shocked by the beginning of it.
Can somebody explain me the reason for such strange
srate computation?

See the head of function:

static int stv6110_set_frequency(struct dvb_frontend *fe, u32 frequency)
{
struct stv6110_priv *priv = fe->tuner_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
u8 ret = 0x04;
u32 divider, ref, p, presc, i, result_freq, vco_freq;
s32 p_calc, p_calc_opt = 1000, r_div, r_div_opt = 0, p_val;
s32 srate;

dprintk("%s, freq=%d kHz, mclk=%d Hz\n", __func__,
frequency, priv->mclk);

/* K = (Reference / 100) - 16 */
priv->regs[RSTV6110_CTRL1] &= ~(0x1f << 3);
priv->regs[RSTV6110_CTRL1] |=
priv->mclk / 100) - 16) & 0x1f) << 3);

/* BB_GAIN = db/2 */
if (fe->ops.set_property && fe->ops.get_property) {
srate = c->symbol_rate;
dprintk("%s: Get Frontend parameters: srate=%d\n",
__func__, srate);
} else
srate = 1500;

 here I would like to note, there there is NO MORE
anything dependant on srate. It looks like some dead code for me.

And the condition sentence looks even more funny - is it
for real to check of retrieval of srate only in case
if some other function pointers are not null?

/Honza

PS: Don't forget that we have duplicated drivers for STV6110,
stv6110 by Igor and stv6110x by Manu.

Re: [PATCH] firmware: cleanup - group and document up private firmware parameters

[Martin Fuzzey]

Hi Luis,

On 15/09/17 00:54, Luis R. Rodriguez wrote:

The firmware API has a slew of private options available, which can
sometimes be hard to understand. When new functionality is introduced
we also tend to have modify a slew of internal helpers.

Just stuff all common private requirements into its own data structure
and move features into properly defined flags which can then be carefully
documented. This:

   o reduces the amount of changes we have make as we advance functionality
   o helps remove the #ifdef mess we had created for private features

The above benefits makes the code much easier to understand and maintain.


Yes I agree it is much cleaner that way.

A couple of nitpicks below.


+/**
+ * enum fw_priv_reqs - private features only used internally
+ *
+ * @FW_PRIV_REQ_FALLBACK: specifies that the firmware request
+ * will use a fallback mechanism if the kernel's direct filesystem
+ * lookup failed to find the requested firmware. If the flag
+ * %FW_PRIV_REQ_FALLBACK is set but the flag
+ * %FW_PRIV_REQ_FALLBACK_UEVENT is not set, it means the caller
+ * is relying on a custom fallback mechanism for firmwarwe lookup as a
+ * fallback mechanism. The custom fallback mechanism is expected to find
+ * any found firmware using the exposed sysfs interface of the
+ * firmware_class.  Since the custom fallback mechanism is not compatible
+ * with the internal caching mechanism for firmware lookups at resume,
+ * caching will be disabled when the custom fallback mechanism is used.
+ * @FW_PRIV_REQ_FALLBACK_UEVENT: indicates that the fallback mechanism
+ * this firmware request will rely on will be that of having the kernel
+ * issue a uevent to userspace. Userspace in turn is expected to be
+ * monitoring for uevents for the firmware_class and will use the
+ * exposted sysfs interface to upload the firmware for the caller.
+ * @FW_PRIV_REQ_NO_CACHE: indicates that the firmware request
+ * should not set up and use the internal caching mechanism to assist
+ * drivers from fetching firmware at resume time after suspend.
+ * @FW_PRIV_REQ_OPTIONAL: if set it is not a hard requirement by the
+ * caller that the file requested be present. An error will not be recorded
+ * if the file is not found.
+ */
+enum fw_priv_reqs {
+   FW_PRIV_REQ_FALLBACK= 1 << 0,
+   FW_PRIV_REQ_FALLBACK_UEVENT = 1 << 1,
+   FW_PRIV_REQ_NO_CACHE= 1 << 2,
+   FW_PRIV_REQ_OPTIONAL= 1 << 3,
+};
+


Why REQ ?
Looks more like a set of flags to me.
Wouldn't FW_PRIV_FLAG_XXX be better?


+/**
+ * struct fw_priv_params - private firmware parameters
+ * @mode: mode of operation
+ * @priv_reqs: private set of &enum fw_priv_reqs, private requirements for
+ * the firmware request
+ * @alloc_buf: buffer area allocated by the caller so we can place the
+ * respective firmware
+ * @alloc_buf_size: size of the @alloc_buf
+ */
+struct fw_priv_params {
+   enum fw_api_mode mode;
+   u64 priv_reqs;


Not sure the priv_ prefix in the priv_reqs is necessary since the whole 
structure is private.

I'd have named it just flags.


Regards,

Martin

Re: [PATCH] z3fold: fix stale list handling

[Vitaly Wool]

Hi Andrew,

2017-09-14 23:15 GMT+02:00 Andrew Morton :
> On Thu, 14 Sep 2017 15:59:36 +0200 Vitaly Wool  wrote:
>
>> Fix the situation when clear_bit() is called for page->private before
>> the page pointer is actually assigned. While at it, remove work_busy()
>> check because it is costly and does not give 100% guarantee anyway.
>
> Does this fix https://bugzilla.kernel.org/show_bug.cgi?id=196877 ?  If
> so, the bugzilla references and a reported-by should be added.

I wish it did but it doesn't. The bug you are referring to happens
with the "unbuddied" list, and the current version of
z3fold_reclaim_page() just doesn't have that code.
This patch fixes the processing of "stale" lists, with stale lists
having been introduced with the per-CPU unbuddied lists patch, which
is pretty recent.
To fix https://bugzilla.kernel.org/show_bug.cgi?id=196877, we'll have
to either backport per-CPU unbuddied lists plus the two fixes, or
propose a separate fix.

> What are the end-user visible effects of the bug?  Please always
> include this info when fixing bugs.

If page is NULL, clear_bit for page->private will result in a kernel crash.

> Should this fix be backported into -stable kernels?

No, this patch fixes the code that is not in any released kernel yet.

~vitaly

[PATCH v2] drm/rockchip: Replace dev_* with DRM_DEV_*

[Haneen Mohammed]

This patch replace instances of dev_info/err/debug with
DRM_DEV_INFO/ERROR/WARN respectively inorder to use a drm-formatted
specific log messages. Issue corrected with the help of the following
Coccinelle script:

@r@
@@

(
-dev_info
+DRM_DEV_INFO
|
-dev_err
+DRM_DEV_ERROR
|
-dev_dbg
+DRM_DEV_DEBUG
)

Signed-off-by: Haneen Mohammed 
---
Changes in v2:
 - Change patch title
 - Remove redundant print messages from DRM_DEV_*

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 26 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 86 ++---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 19 +++---
 drivers/gpu/drm/rockchip/inno_hdmi.c| 14 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 12 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  8 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c   | 18 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 -
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  2 +-
 10 files changed, 121 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 9606121..4d3f6ad 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -88,7 +88,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, 
bool enabled)
if (!analogix_dp_psr_supported(dp->dev))
return;
 
-   dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+   DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
 
spin_lock_irqsave(&dp->psr_lock, flags);
if (enabled)
@@ -110,7 +110,7 @@ static void analogix_dp_psr_work(struct work_struct *work)
ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
 PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
-   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
return;
}
 
@@ -140,13 +140,13 @@ static int rockchip_dp_poweron(struct 
analogix_dp_plat_data *plat_data)
 
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
-   dev_err(dp->dev, "failed to enable pclk %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
return ret;
}
 
ret = rockchip_dp_pre_init(dp);
if (ret < 0) {
-   dev_err(dp->dev, "failed to dp pre init %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to dp pre init %d\n", ret);
clk_disable_unprepare(dp->pclk);
return ret;
}
@@ -211,17 +211,17 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
else
val = dp->data->lcdsel_big;
 
-   dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
+   DRM_DEV_DEBUG(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
 
ret = clk_prepare_enable(dp->grfclk);
if (ret < 0) {
-   dev_err(dp->dev, "failed to enable grfclk %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to enable grfclk %d\n", ret);
return;
}
 
ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
if (ret != 0)
-   dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
 
clk_disable_unprepare(dp->grfclk);
 }
@@ -277,7 +277,7 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
 
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf)) {
-   dev_err(dev, "failed to get rockchip,grf property\n");
+   DRM_DEV_ERROR(dev, "failed to get rockchip,grf property\n");
return PTR_ERR(dp->grf);
}
 
@@ -287,31 +287,31 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
} else if (PTR_ERR(dp->grfclk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
} else if (IS_ERR(dp->grfclk)) {
-   dev_err(dev, "failed to get grf clock\n");
+   DRM_DEV_ERROR(dev, "failed to get grf clock\n");
return PTR_ERR(dp->grfclk);
}
 
dp->pclk = devm_clk_get(dev, "pclk");
if (IS_ERR(dp->pclk)) {
-   dev_err(dev, "failed to get pclk property\n");
+   DRM_DEV_ERROR(dev, "failed to get pclk property\n");
return PTR_ERR(dp->pclk);
}
 
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst)) {
-   dev_err(dev, "failed to get dp reset control\n");
+   DRM_DEV_ERROR(dev, "failed to get dp reset control\n");
return PTR_ERR(dp->rst);
}
 
ret = clk_prepare_enab

Re: [PATCH 0/3] Fix y2038 issues for security/keys subsystem

[Baolin Wang]

Hi James,

On 21 August 2017 at 20:12, Baolin Wang  wrote:
> Hi David and James,
>
> On 9 August 2017 at 16:28, David Howells  wrote:
>> The rxrpc patch isn't part of the security/keys subsystem.  I'll push it
>> to the network tree.  The other two I'll push to James.
>
> Could you apply this patch serials if there are no other comments? Thanks.

Could you apply patch1 and patch2? I have seen patch3 was merged into
4.14 by David. Thanks.

-- 
Baolin.wang
Best Regards

Re: x60: warnings on boot and resume, arch/x86/mm/tlb.c:257 initialize_ ... was Re: [PATCH 0/2] Fix resume failure due to PCID

[Ingo Molnar]

* Pavel Machek  wrote:

> On Wed 2017-09-06 20:25:10, Linus Torvalds wrote:
> > On Wed, Sep 6, 2017 at 7:54 PM, Andy Lutomirski  wrote:
> > > Patch 1 is the fix.  Patch 2 is a comment that would have kept me from
> > > chasing down a false lead.
> > 
> > Yes, this seems to fix things for me. Thanks.
> > 
> > Of course, right now that laptop has no working wifi with tip-of-tree
> > due to some issues with the networking tree, but that's an independent
> > thing and I could suspend and resume with this. So applied and pushed
> > out,
> 
> Ok, seems this is still not completely right, I'm now getting WARN_ON
> during boot and on every resume... but machine works.
> 
> 4.14-rc0, 32-bit.

Which SHA1, just to make sure? (Please enable CONFIG_LOCALVERSION_AUTO=y.)

> [0.004000] Initializing CPU#1
> [0.004000] [ cut here ]
> [0.004000] WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:257 
> initialize_tlbstate_and_flush+0x27/0xcf
> [0.004000] Modules linked in:
> [0.004000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0+ #429
> [0.004000] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 
> 03/31/2011
> [0.004000] task: f5ca2080 task.stack: f5cc4000
> [0.004000] EIP: initialize_tlbstate_and_flush+0x27/0xcf
> [0.004000] EFLAGS: 00210087 CPU: 1
> [0.004000] EAX:  EBX: c506d540 ECX: 051b2000 EDX: 
> [0.004000] ESI: 0503f000 EDI: c51b2000 EBP: f5cc5f54 ESP: f5cc5f48
> [0.004000]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [0.004000] CR0: 80050033 CR2:  CR3: 0503f000 CR4: 06b0
> [0.004000] Call Trace:
> [0.004000]  cpu_init+0xdc/0x2f0
> [0.004000]  start_secondary+0x34/0x1c6
> [0.004000]  startup_32_smp+0x164/0x166
> [0.004000]  ? startup_32_smp+0x164/0x166

Could you please try the debug patch below, so that we get a bit more info?

Thanks,

Ingo

===>

 arch/x86/mm/tlb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 1ab3821f9e26..f98feb4b39a7 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -254,7 +254,8 @@ void initialize_tlbstate_and_flush(void)
unsigned long cr3 = __read_cr3();
 
/* Assert that CR3 already references the right mm. */
-   WARN_ON((cr3 & CR3_ADDR_MASK) != __pa(mm->pgd));
+   if (WARN_ON((cr3 & CR3_ADDR_MASK) != __pa(mm->pgd)))
+   printk("# CR3: %016lx, __pa(mm->pgd): %016lx\n", cr3, 
__pa(mm->pgd));
 
/*
 * Assert that CR4.PCIDE is set if needed.  (CR4.PCIDE initialization

[RFC] Restrict writes into untrusted FIFOs and regular files

[Salvatore Mesoraca]

Disallows writing into FIFOs or regular files not owned by the user
in world writable sticky directories, unless the owner is the same as
that of the directory or the file is opened without the O_CREAT flag.
The purpose is to make data spoofing attacks harder.
This protection can be turned on and off separately for FIFOs and regular
files via sysctl, just like the symlinks/hardlinks protection.
This patch is based on Openwall's "HARDEN_FIFO" feature by Solar
Designer .

Suggested-by: Solar Designer 
Suggested-by: Kees Cook 
Signed-off-by: Salvatore Mesoraca 
---
 Documentation/sysctl/fs.txt | 34 ++
 fs/namei.c  | 23 +++
 include/linux/fs.h  |  2 ++
 kernel/sysctl.c | 18 ++
 4 files changed, 77 insertions(+)

diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
index 35e17f7..18e16b7 100644
--- a/Documentation/sysctl/fs.txt
+++ b/Documentation/sysctl/fs.txt
@@ -36,6 +36,8 @@ Currently, these files are in /proc/sys/fs:
 - pipe-user-pages-soft
 - protected_hardlinks
 - protected_symlinks
+- protected_fifos
+- protected_regular_files
 - suid_dumpable
 - super-max
 - super-nr
@@ -222,6 +224,38 @@ This protection is based on the restrictions in Openwall 
and grsecurity.
 
 ==
 
+protected_fifos:
+
+The intent of this protection is to avoid unintentional writes to
+an attacker-controlled FIFO, where program expected to create a regular
+file.
+
+When set to "0", FIFOs writing is unrestricted.
+
+When set to "1" don't allow O_CREAT open on FIFOs that we don't own
+in world writable sticky directories, unless they are owned by the
+owner of the directory.
+
+This protection is based on the restrictions in Openwall.
+
+==
+
+protected_regular_files:
+
+This protection is similar to protected_fifos, but it
+avoids writes to an attacker-controlled regular file, where program
+expected to create one.
+
+When set to "0", regular files writing is unrestricted.
+
+When set to "1" don't allow O_CREAT open on regular files that we
+don't own in world writable sticky directories, unless they are
+owned by the owner of the directory.
+
+This protection is based on the restrictions in Openwall.
+
+==
+
 suid_dumpable:
 
 This value can be used to query and set the core dump mode for setuid
diff --git a/fs/namei.c b/fs/namei.c
index c75ea03..5459dbc 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3225,6 +3225,9 @@ static int lookup_open(struct nameidata *nd, struct path 
*path,
return error;
 }
 
+int sysctl_protected_fifos __read_mostly;
+int sysctl_protected_regular_files __read_mostly;
+
 /*
  * Handle the last step of open()
  */
@@ -3354,6 +3357,26 @@ static int do_last(struct nameidata *nd,
 
seq = 0;/* out of RCU mode, so the value doesn't matter */
inode = d_backing_inode(path.dentry);
+   /*
+* When this protection is turned on via sysctl:
+* don't allow "O_CREAT" open on FIFOs or regular files that we
+* don't own in world writable sticky directories, unless they
+* are owned by the owner of the directory.
+*/
+   if (((sysctl_protected_fifos && S_ISFIFO(inode->i_mode)) ||
+(sysctl_protected_regular_files && S_ISREG(inode->i_mode))) &&
+   (dir->d_inode->i_mode & (S_ISVTX|S_IWOTH) == (S_ISVTX|S_IWOTH)) &&
+   !uid_eq(inode->i_uid, dir->d_inode->i_uid) &&
+   !uid_eq(current_fsuid(), inode->i_uid)) {
+   pr_notice_ratelimited("denied writing in file of %d.%d in a 
sticky directory by UID %d, EUID %d, process %s:%d.",
+   from_kuid(&init_user_ns, inode->i_uid),
+   from_kgid(&init_user_ns, inode->i_gid),
+   from_kuid(&init_user_ns, current_uid()),
+   from_kuid(&init_user_ns, current_euid()),
+   current->comm, current->pid);
+   path_to_nameidata(&path, nd);
+   return -EACCES;
+   }
 finish_lookup:
error = step_into(nd, &path, 0, inode, seq);
if (unlikely(error))
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 339e737..591ae87 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -71,6 +71,8 @@
 extern int leases_enable, lease_break_time;
 extern int sysctl_protected_symlinks;
 extern int sysctl_protected_hardlinks;
+extern int sysctl_protected_fifos;
+extern int sysctl_protected_regular_files;
 
 typedef __kernel_rwf_t rwf_t;
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbb..b18d500 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1807,6 +1807,24 @@ static int sysrq_sysctl_handler(struct ctl_table *table, 
int write,
.extra2 = &one,
},
{
+  

[crazy hacks] N900 flashlight

[Pavel Machek]

Hi!

This adds /sys interface to n900 flash. So you can do stuff...

/sys/class/leds/led-controller:flash# echo 0 > 
../led-controller\:indicator/brightness

Needs _way_ more work. Also... contains way too much boilerplate, see
leds-flash.c . We'll need to figure out how to share more code between
drivers.

GPL.

Best regards,

Pavel

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c4e8de7..1b88494 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -618,16 +618,21 @@
};
 
adp1653: led-controller@30 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   
compatible = "adi,adp1653";
reg = <0x30>;
enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
 
-   flash {
+   adp_flash: flash@0 {
+   reg = <0x0>;
flash-timeout-us = <50>;
flash-max-microamp = <32>;
led-max-microamp = <5>;
};
-   indicator {
+   adp_indicator: indicator@1 {
+   reg = <0x1>;
led-max-microamp = <17500>;
};
};
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index b7af41e..78bbcbf 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -7,6 +7,9 @@ obj-$(CONFIG_LEDS_CLASS)+= led-class.o
 obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
 obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
 
+obj-$(CONFIG_LEDS_CLASS_FLASH) += leds-flash.o
+obj-y  += leds-adp1653.o
+
 # LED Platform Drivers
 obj-$(CONFIG_LEDS_88PM860X)+= leds-88pm860x.o
 obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o
diff --git a/drivers/leds/leds-adp1653.c b/drivers/leds/leds-adp1653.c
new file mode 100644
index 000..96444a7
--- /dev/null
+++ b/drivers/leds/leds-adp1653.c
@@ -0,0 +1,756 @@
+/*
+ * Example of i2c flash LED driver
+ *
+ * Copyright (c) 2008-2011 Nokia Corporation
+ * Copyright (c) 2011, 2017 Intel Corporation
+ * Copyright (c) 2017 Pavel Machek 
+ *
+ * Based on drivers/media/i2c/, by Sakari Ailus 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#define DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* LED numbers for Devicetree */
+#define AS_LED_FLASH   0
+#define AS_LED_INDICATOR   1
+
+enum as_mode {
+   AS_MODE_EXT_TORCH = 0,
+   AS_MODE_INDICATOR = 1,
+   AS_MODE_ASSIST = 2,
+   AS_MODE_FLASH = 3,
+   AS_MODE_OFF = 4,
+};
+
+struct fl_config {
+   u32 flash_timeout_us;
+   u32 flash_max_ua;
+   u32 assist_max_ua;
+   u32 indicator_max_ua;
+   u32 voltage_reference;
+   u32 peak;
+};
+
+struct fl_names {
+   char flash[32];
+   char indicator[32];
+};
+
+struct fl {
+   struct i2c_client *client;
+
+   struct mutex mutex;
+
+   struct led_classdev_flash fled;
+   struct led_classdev iled_cdev;
+
+   struct v4l2_flash *vf;
+   struct v4l2_flash *vfind;
+
+   struct fwnode_handle *flash_node;
+   struct fwnode_handle *indicator_node;
+
+   struct fl_config cfg;
+
+   enum as_mode mode;
+   unsigned int timeout;
+   unsigned int flash_current;
+   unsigned int assist_current;
+   unsigned int indicator_current;
+   enum v4l2_flash_strobe_source strobe_source;
+
+   int indicator_intensity_min;
+   int indicator_intensity_step;
+   int torch_intensity_min;
+   int torch_intensity_step;
+   int flash_intensity_min;
+   int flash_intensity_step;
+   int flash_timeout_min;
+   int flash_timeout_step;
+
+   int fault;
+   struct gpio_desc *enable_gpio;
+};
+
+#define fled_to_fl(__fled) container_of(__fled, struct fl, fled)
+#define iled_cdev_to_fl(__iled_cdev) \
+   container_of(__iled_cdev, struct fl, iled_cdev)
+
+/* Return negative errno else zero on success */
+static int fl_write(struct fl *flash, u8 addr, u8 val)
+{
+   struct i2c_client *client = flash->client;
+   int rval;
+
+   rval = i2c_smbus_write_byte_data(client, addr, val);
+
+   dev_dbg(&client->dev, "Write Addr:%02X Val:%02X %s\n", addr, val,
+   rval < 0 ? "fail" : "ok");
+
+   return rval;
+}
+
+/* Return negative errno el

[tip:core/urgent] objtool: Do not retrieve data from empty sections

[tip-bot for Petr Vandrovec]

Commit-ID:  7156b7141a037420a3cd99dbc1559e0235f57c07
Gitweb: http://git.kernel.org/tip/7156b7141a037420a3cd99dbc1559e0235f57c07
Author: Petr Vandrovec 
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 10:30:31 +0200

objtool: Do not retrieve data from empty sections

Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:

  elf_getdata: can't manipulate null section

As nothing is done with sections that have zero size, just do not
retrieve their data at all.

Signed-off-by: Petr Vandrovec 
Signed-off-by: Josh Poimboeuf 
Reviewed-by: Don Zickus 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/2ce30a44349065b70d0f00e71e286dc0cbe745e6.1505459652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/objtool/elf.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 1e89a5f..b4cd8bc 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
 
-   sec->data = elf_getdata(s, NULL);
-   if (!sec->data) {
-   WARN_ELF("elf_getdata");
-   return -1;
-   }
-
-   if (sec->data->d_off != 0 ||
-   sec->data->d_size != sec->sh.sh_size) {
-   WARN("unexpected data attributes for %s", sec->name);
-   return -1;
+   if (sec->sh.sh_size != 0) {
+   sec->data = elf_getdata(s, NULL);
+   if (!sec->data) {
+   WARN_ELF("elf_getdata");
+   return -1;
+   }
+   if (sec->data->d_off != 0 ||
+   sec->data->d_size != sec->sh.sh_size) {
+   WARN("unexpected data attributes for %s",
+sec->name);
+   return -1;
+   }
}
-
-   sec->len = sec->data->d_size;
+   sec->len = sec->sh.sh_size;
}
 
/* sanity check, one more call to elf_nextscn() should return NULL */

[tip:core/urgent] tools/objtool: Fix memory leak in elf_create_rela_section()

[tip-bot for Martin Kepplinger]

Commit-ID:  5b1972d74446bed79df5ddc9674bc3f2a0b6c444
Gitweb: http://git.kernel.org/tip/5b1972d74446bed79df5ddc9674bc3f2a0b6c444
Author: Martin Kepplinger 
AuthorDate: Thu, 14 Sep 2017 08:01:38 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 10:30:30 +0200

tools/objtool: Fix memory leak in elf_create_rela_section()

Let's free the allocated char array 'relaname' before returning,
in order to avoid leaking memory.

Signed-off-by: Martin Kepplinger 
Reviewed-by: Don Zickus 
Acked-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: mingo.kernel@gmail.com
Link: http://lkml.kernel.org/r/20170914060138.26472-1-mart...@posteo.de
Signed-off-by: Ingo Molnar 
---
 tools/objtool/elf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 6e9f980..1e89a5f 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -508,6 +508,7 @@ struct section *elf_create_rela_section(struct elf *elf, 
struct section *base)
strcat(relaname, base->name);
 
sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0);
+   free(relaname);
if (!sec)
return NULL;
 

[tip:core/urgent] objtool: Fix object file corruption

[tip-bot for Josh Poimboeuf]

Commit-ID:  3eed2fa7cb2118234cdc89fb6b2bef82b0c9ca81
Gitweb: http://git.kernel.org/tip/3eed2fa7cb2118234cdc89fb6b2bef82b0c9ca81
Author: Josh Poimboeuf 
AuthorDate: Fri, 15 Sep 2017 02:17:11 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 10:30:31 +0200

objtool: Fix object file corruption

Arnd Bergmann reported that a randconfig build was failing with the
following link error:

  built-in.o: member arch/x86/kernel/time.o in archive is not an object

It turns out the link failed because the time.o file had been corrupted
by objtool:

  nm: arch/x86/kernel/time.o: File format not recognized

In certain rare cases, when a .o file's ORC table is very small, the
.data section size doesn't change because it's page aligned.  Because
all the existing sections haven't changed size, libelf doesn't detect
any section header changes, and so it doesn't update the section header
table properly.  Instead it writes junk in the section header entries
for the new ORC sections.

Make sure libelf properly updates the section header table by setting
the ELF_F_DIRTY flag in the top level elf struct.

Reported-by: Arnd Bergmann 
Signed-off-by: Josh Poimboeuf 
Reviewed-by: Don Zickus 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 627fce14809b ("objtool: Add ORC unwind table generation")
Link: 
http://lkml.kernel.org/r/e650fd0f2d8a209d1409a9785deb101fdaed55fb.1505459813.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/objtool/elf.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index b4cd8bc..2446015 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -563,6 +563,7 @@ int elf_write(struct elf *elf)
struct section *sec;
Elf_Scn *s;
 
+   /* Update section headers for changed sections: */
list_for_each_entry(sec, &elf->sections, list) {
if (sec->changed) {
s = elf_getscn(elf->elf, sec->idx);
@@ -570,13 +571,17 @@ int elf_write(struct elf *elf)
WARN_ELF("elf_getscn");
return -1;
}
-   if (!gelf_update_shdr (s, &sec->sh)) {
+   if (!gelf_update_shdr(s, &sec->sh)) {
WARN_ELF("gelf_update_shdr");
return -1;
}
}
}
 
+   /* Make sure the new section header entries get updated properly. */
+   elf_flagelf(elf->elf, ELF_C_SET, ELF_F_DIRTY);
+
+   /* Write all changes to the file. */
if (elf_update(elf->elf, ELF_C_WRITE) < 0) {
WARN_ELF("elf_update");
return -1;

Re: [PATCH] dma-buf: remove redundant initialization of sg_table

[Chris Wilson]

Quoting Colin King (2017-09-15 00:05:16)
> From: Colin Ian King 
> 
> sg_table is being initialized and is never read before it is updated
> again later on, hence making the initialization redundant. Remove
> the initialization.
> 
> Detected by clang scan-build:
> "warning: Value stored to 'sg_table' during its initialization is
> never read"
> 
> Signed-off-by: Colin Ian King 
Reviewed-by: Chris Wilson 
-Chris

[tip:x86/urgent] x86/cpu/AMD: Fix erratum 1076 (CPB bit)

[tip-bot for Borislav Petkov]

Commit-ID:  6a707c0e451cb8d86943b840939e2ed881b8023e
Gitweb: http://git.kernel.org/tip/6a707c0e451cb8d86943b840939e2ed881b8023e
Author: Borislav Petkov 
AuthorDate: Thu, 7 Sep 2017 19:08:21 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 07:44:50 +0200

x86/cpu/AMD: Fix erratum 1076 (CPB bit)

CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on models up to B1. But they do
support CPB (AMD's Core Performance Boosting cpufreq CPU feature), so fix that.

Signed-off-by: Borislav Petkov 
Reviewed-by: Don Zickus 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sherry Hurwitz 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170907170821.16021-1...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/amd.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9862e2c..d58184b 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -763,6 +763,16 @@ static void init_amd_bd(struct cpuinfo_x86 *c)
}
 }
 
+static void init_amd_zn(struct cpuinfo_x86 *c)
+{
+   /*
+* Fix erratum 1076: CPB feature bit not being set in CPUID. It affects
+* all up to and including B1.
+*/
+   if (c->x86_model <= 1 && c->x86_mask <= 1)
+   set_cpu_cap(c, X86_FEATURE_CPB);
+}
+
 static void init_amd(struct cpuinfo_x86 *c)
 {
early_init_amd(c);
@@ -791,6 +801,7 @@ static void init_amd(struct cpuinfo_x86 *c)
case 0x10: init_amd_gh(c); break;
case 0x12: init_amd_ln(c); break;
case 0x15: init_amd_bd(c); break;
+   case 0x17: init_amd_zn(c); break;
}
 
/* Enable workaround for FXSAVE leak */

Re: [PATCH v1] [DVB][FRONTEND] Added a new ioctl for optimizing frontend property set operation

[Mauro Carvalho Chehab]

Em Fri, 15 Sep 2017 01:50:29 -0400
Satendra Singh Thakur  escreveu:

> Hello  Mr Chehab,
> Thanks for reviewing the patch.
> I have modified the patch as per your comments.
> Please check if it looks fine now.

Forgot to mention, but, for the patch series to be applied, you'll need to
also patch Documentation/media/uapi/dvb.

> Signed-off-by: Satendra Singh Thakur 
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 212 
> +-
>  include/uapi/linux/dvb/frontend.h |  24 
>  2 files changed, 234 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index e3fff8f..bc35a86 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -1914,6 +1914,188 @@ static int dtv_property_process_set(struct 
> dvb_frontend *fe,
>   return r;
>  }
>  
> +/**
> + * dtv_property_short_process_set
> + * @fe: Pointer to struct dvb_frontend
> + * @file: Pointer to struct file
> + * @cmd: Property name
> + * @data: Property value
> + *
> + * helper function for dvb_frontend_ioctl_properties,
> + * which can be used to set dtv property using ioctl
> + * cmd FE_SET_PROPERTY_SHORT.
> + * It assigns property value to corresponding member of
> + * property-cache structure
> + * This func is a variant of the func dtv_property_process_set
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +static int dtv_property_short_process_set(struct dvb_frontend *fe,
> + struct file *file,
> + u32 cmd, u32 data)
> +{
> + int r = 0;
> + struct dtv_frontend_properties *c = &fe->dtv_property_cache;
> + switch (cmd) {
> + case DTV_CLEAR:
> + /*
> +  * Reset a cache of data specific to the frontend here. This
> +  * does not effect hardware.
> +  */
> + dvb_frontend_clear_cache(fe);
> + break;

No, you got me wrong. What I want is to have just *one* switch that
would work for both the normal and the short version of this ioctl.

In other words, I was expecting you to patch the existing
dtv_property_process_set() for it to take u32 cmd and u32 data as
arguments and to be used by both FE_SET_PROPERTY and FE_SET_PROPERTY_SHORT
handling.

> + case DTV_TUNE:
> + /* interpret the cache of data, build either a traditional
> +  * frontend tune request so we can pass validation in the
> +  * FE_SET_FRONTEND  ioctl.
> +  */
> + c->state = cmd;
> + dev_dbg(fe->dvb->device, "%s: Finalised property cache\n",
> + __func__);
> +
> + r = dtv_set_frontend(fe);
> + break;
> + case DTV_FREQUENCY:
> + c->frequency = data;
> + break;
> + case DTV_MODULATION:
> + c->modulation = data;
> + break;
> + case DTV_BANDWIDTH_HZ:
> + c->bandwidth_hz = data;
> + break;
> + case DTV_INVERSION:
> + c->inversion = data;
> + break;
> + case DTV_SYMBOL_RATE:
> + c->symbol_rate = data;
> + break;
> + case DTV_INNER_FEC:
> + c->fec_inner = data;
> + break;
> + case DTV_PILOT:
> + c->pilot = data;
> + break;
> + case DTV_ROLLOFF:
> + c->rolloff = data;
> + break;
> + case DTV_DELIVERY_SYSTEM:
> + r = dvbv5_set_delivery_system(fe, data);
> + break;
> + case DTV_VOLTAGE:
> + c->voltage = data;
> + r = dvb_frontend_ioctl_legacy(file, FE_SET_VOLTAGE,
> + (void *)c->voltage);
> + break;
> + case DTV_TONE:
> + c->sectone = data;
> + r = dvb_frontend_ioctl_legacy(file, FE_SET_TONE,
> + (void *)c->sectone);
> + break;
> + case DTV_CODE_RATE_HP:
> + c->code_rate_HP = data;
> + break;
> + case DTV_CODE_RATE_LP:
> + c->code_rate_LP = data;
> + break;
> + case DTV_GUARD_INTERVAL:
> + c->guard_interval = data;
> + break;
> + case DTV_TRANSMISSION_MODE:
> + c->transmission_mode = data;
> + break;
> + case DTV_HIERARCHY:
> + c->hierarchy = data;
> + break;
> + case DTV_INTERLEAVING:
> + c->interleaving = data;
> + break;
> +
> + /* ISDB-T Support here */
> + case DTV_ISDBT_PARTIAL_RECEPTION:
> + c->isdbt_partial_reception = data;
> + break;
> + case DTV_ISDBT_SOUND_BROADCASTING:
> + c->isdbt_sb_mode = data;
> + break;
> + case DTV_ISDBT_SB_SUBCHANNEL_ID:
> + c->isdbt_sb_subchannel = data;
> + break;
> + case DTV_ISDBT_SB_SE

Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

[gustavo panizzo]

Hello

On Thu, Sep 07, 2017 at 01:51:31PM +0300, Felipe Balbi wrote:


Hi,

gustavo panizzo  writes:

---
drivers/usb/dwc3/core.c | 33 +
1 file changed, 33 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 326b302fc440..f92dfe213d89 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1259,6 +1259,38 @@ static int dwc3_probe(struct platform_device
*pdev)
   return ret;
}

+static void dwc3_shutdown(struct platform_device *pdev)
+{
+   struct dwc3 *dwc = platform_get_drvdata(pdev);
+   struct resource *res = platform_get_resource(pdev,
IORESOURCE_MEM, 0);
+
+   pm_runtime_get_sync(&pdev->dev);
+   /*
+* restore res->start back to its original value so that, in case
the
+* probe is deferred, we don't end up getting error in request
the
+* memory region the next time probe is called.
+*/
+   res->start -= DWC3_GLOBALS_REGS_START;
+
+   dwc3_debugfs_exit(dwc);
+   dwc3_core_exit_mode(dwc);
+   dwc3_event_buffers_cleanup(dwc);



What about dwc3_event_buffers_cleanup? should I remove it from
dwc3_shutdown()?
It is already in dwc3_core_exit()


I think so. We should avoid duplicate code.


+   dwc3_free_event_buffers(dwc);
+
+   usb_phy_set_suspend(dwc->usb2_phy, 1);
+   usb_phy_set_suspend(dwc->usb3_phy, 1);
+
+   phy_power_off(dwc->usb2_generic_phy);
+   phy_power_off(dwc->usb3_generic_phy);



We've done these in dwc3_core_exit().


This is the patch after testing on a Odroid XU4, on top of linux-next
964bcc1b4f57028d56dace7d9bc5924f2eb43f36 which translates to 
4.13.0-rc1-next-20170717+
I tested this patch for a week without problems with heavy USB and NIC usage.
Please consider merging it


Author: Brian Kim 
Date:   Wed Jul 12 11:26:55 2017 +0800

   usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot
   The dwc3 could not release resources when the module is built-in
   because this module does not have shutdown method. This causes the USB
   3.0 hub is not able to detect after warm boot.
   Original patch by Brian Kim, updated and submitted upstream by gustavo
   panizzo.
   Also see https://bugs.debian.org/843448
   Signed-off-by: Brian Kim 
   Signed-off-by: gustavo panizzo 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 326b302fc440..09de37d47ee7 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1259,6 +1259,32 @@ static int dwc3_probe(struct platform_device *pdev)
return ret;
}

+static void dwc3_shutdown(struct platform_device *pdev)
+{
+   struct dwc3 *dwc = platform_get_drvdata(pdev);
+   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+   pm_runtime_get_sync(&pdev->dev);
+   /*
+* restore res->start back to its original value so that, in case the
+* probe is deferred, we don't end up getting error in request the
+* memory region the next time probe is called.
+*/
+   res->start -= DWC3_GLOBALS_REGS_START;
+
+   dwc3_debugfs_exit(dwc);
+   dwc3_core_exit_mode(dwc);
+   dwc3_event_buffers_cleanup(dwc);
+   dwc3_free_event_buffers(dwc);
+
+   dwc3_core_exit(dwc);
+   dwc3_ulpi_exit(dwc);
+
+   pm_runtime_put_sync(&pdev->dev);
+   pm_runtime_allow(&pdev->dev);
+   pm_runtime_disable(&pdev->dev);
+}
+
static int dwc3_remove(struct platform_device *pdev)
{
struct dwc3 *dwc = platform_get_drvdata(pdev);
@@ -1488,6 +1514,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = dwc3_remove,
+   .shutdown   = dwc3_shutdown,
.driver = {
.name   = "dwc3",
.of_match_table = of_match_ptr(of_dwc3_match),

Patch applies cleanly on top of c6be5a0e3cebc145127d46a58350e05d2bcf6323 from 
linux-next
Can you _please_ merge it?


why are you upset? You didn't do the changes I requested until now. It's


I'm not upset


too late for v4.14 merge window and you didn't even send this as a
proper patch. I also have no evidence that you've been testing mainline
kernel, the commits you pointed me to are against a v4.9 vendor kernel.


the commit i sent was tested, and is still running, on top linux-next
964bcc1b4f57028d56dace7d9bc5924f2eb43f36, which gives an uname -r
4.13.0-rc1-next-20170717+




Test this against a vanilla tree (v4.13 was tagged days ago) and give me
logs showing the problem without your commit.


dmesg on top of 4.13.0

[0.00] Booting Linux on physical CPU 0x100
[0.00] random: get_random_bytes called from start_kernel+0x44/0x460 
with crng_init=0
[0.00] Linux version 4.13.0 (root@odroid) (gcc version 6.3.0 20170516 
(Debian 6.3.0-18)) #4 SMP Thu Sep 14 21:26:18 UTC 2017
[0.00] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=30c5387d
[0.00] CPU: 

Re: [PATCH 3/3] ima: use fs method to read integrity data

[Mimi Zohar]

On Thu, 2017-09-14 at 22:50 -0700, Linus Torvalds wrote:
> This is still wrong.
> 
> (a) there is no explanation for why we need that exclusive lock in the
> first place

> Why should a read need exclusive access? You'd think shared is sufficient.

True, reading a file shouldn't require an exclusive lock.  The
exclusive lock is taken to prevent the file from changing while the
file hash is being calculated.

> But regardless, it needs *explanation*.

Agreed.  A fuller explanation was included in the cover letter that
should have also been included in the patch description.  The
following is taken from the cover letter:

With the introduction of IMA-appraisal and the need to write file
hashes as security xattrs, IMA needed to take the global i_mutex
lock.  process_measurement() took the iint->mutex first and then
the i_mutex, while setxattr, chmod and chown took the locks in
reverse order.  To resolve this potential deadlock, the iint->mutex
was removed.

Some filesystems have recently replaced their filesystem dependent
lock with the global i_rwsem (formerly the i_mutex) to read a file.
As a result, when IMA attempts to calculate the file hash, reading
the file attempts to take the i_rwsem again.

To resolve this locking problem, this patch set defines a new
->integrity_read file operation method.

(Fixes: Commit 6552321831dc "xfs: remove i_iolock and use i_rwsem in
the VFS inode instead")

Mimi

> (b) the lockdep test isn't for the exclusive lock that the code comment
> says it is
> 
> So no, this needs more work.
> 
> Linus
> 

> 
> On Sep 14, 2017 21:59, "Mimi Zohar"  wrote:
> 
> > From: Christoph Hellwig 
> >
> > Add a new ->integrity_read file operation to read data for integrity
> > hash collection.  This is defined to be equivalent to ->read_iter,
> > except that it will be called with the i_rwsem held exclusively.
> >
> > (Based on Christoph's original patch.)
> >
> > Signed-off-by: Christoph Hellwig 
> > Cc: Matthew Garrett 
> > Cc: Jan Kara 
> > Cc: "Theodore Ts'o" 
> > Cc: Andreas Dilger 
> > Cc: Jaegeuk Kim 
> > Cc: Chao Yu 
> > Cc: Steven Whitehouse 
> > Cc: Bob Peterson 
> > Cc: David Woodhouse 
> > Cc: Dave Kleikamp 
> > Cc: Ryusuke Konishi 
> > Cc: Mark Fasheh 
> > Cc: Joel Becker 
> > Cc: Richard Weinberger 
> > Cc: "Darrick J. Wong" 
> > Cc: Hugh Dickins 
> > Cc: Chris Mason 
> > Signed-off-by: Mimi Zohar 
> > Reviewed-by: Jan Kara 
> > Reviewed-by: Dmitry Kasatkin 
> > ---
> >  fs/btrfs/file.c   |  1 +
> >  fs/efivarfs/file.c|  1 +
> >  fs/ext2/file.c| 17 +
> >  fs/ext4/file.c| 20 
> >  fs/f2fs/file.c|  1 +
> >  fs/jffs2/file.c   |  1 +
> >  fs/jfs/file.c |  1 +
> >  fs/nilfs2/file.c  |  1 +
> >  fs/ramfs/file-mmu.c   |  1 +
> >  fs/ramfs/file-nommu.c |  1 +
> >  fs/ubifs/file.c   |  1 +
> >  fs/xfs/xfs_file.c | 21 +
> >  include/linux/fs.h|  1 +
> >  mm/shmem.c|  1 +
> >  security/integrity/iint.c | 20 ++--
> >  15 files changed, 83 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> > index 9e75d8a39aac..2542dc66c85c 100644
> > --- a/fs/btrfs/file.c
> > +++ b/fs/btrfs/file.c
> > @@ -3125,6 +3125,7 @@ const struct file_operations btrfs_file_operations =
> > {
> >  #endif
> > .clone_file_range = btrfs_clone_file_range,
> > .dedupe_file_range = btrfs_dedupe_file_range,
> > +   .integrity_read = generic_file_read_iter,
> >  };
> >
> >  void btrfs_auto_defrag_exit(void)
> > diff --git a/fs/efivarfs/file.c b/fs/efivarfs/file.c
> > index 863f1b100165..17955a92a5b3 100644
> > --- a/fs/efivarfs/file.c
> > +++ b/fs/efivarfs/file.c
> > @@ -179,4 +179,5 @@ const struct file_operations efivarfs_file_operations
> > = {
> > .write  = efivarfs_file_write,
> > .llseek = no_llseek,
> > .unlocked_ioctl = efivarfs_file_ioctl,
> > +   .integrity_read = efivarfs_file_read_iter,
> >  };
> > diff --git a/fs/ext2/file.c b/fs/ext2/file.c
> > index d34d32bdc944..111069de1973 100644
> > --- a/fs/ext2/file.c
> > +++ b/fs/ext2/file.c
> > @@ -192,6 +192,22 @@ static ssize_t ext2_file_read_iter(struct kiocb
> > *iocb, struct iov_iter *to)
> > return generic_file_read_iter(iocb, to);
> >  }
> >
> > +static ssize_t ext2_file_integrity_read_iter(struct kiocb *iocb,
> > +struct iov_iter *to)
> > +{
> > +   struct inode *inode = file_inode(iocb->ki_filp);
> > +
> > +   lockdep_assert_held(&inode->i_rwsem);
> > +#ifdef CONFIG_FS_DAX
> > +   if (!iov_iter_count(to))
> > +   return 0; /* skip atime */
> > +
> > +   if (IS_DAX(iocb->ki_filp->f_mapping->host))
> > +   return dax_iomap_rw(iocb, to, &ext2_iomap_ops);
> > +#endif
> > +   return generic_file_read_iter(iocb, to);
> > +}
> > +
> >  static ssize_t ext2_file_write_iter(struct kiocb *iocb, str

Re: [PATCH] remoteproc: qcom: select QCOM_SMP2P for all qcom pils

[Srinivas Kandagatla]

On 14/09/17 17:57, Bjorn Andersson wrote:

On Wed 13 Sep 09:04 PDT 2017, srinivas.kandaga...@linaro.org wrote:


From: Srinivas Kandagatla 

All Qualcomm PIL drivers require SMP2P module to get a functional PIL,
Currently user has to explicitly select SMP2P module, after looking
at failure logs.

Fix this by selecting SMP2P as part of dependency of pil kconfig itself.



The Kconfig should describe dependencies needed by the code, not by the
system.


I partially agree with this! As I did not realize that that there are 
more than one SMEM_STATE drivers.



The driver bindings clearly marks "qcom,smem-states" and 
"qcom,smem-state-names" as required properties, so it makes the driver 
dependent on SMEM_STATE.


But SMEM_STATE is only selected from SMP2P Kconfig.

Indirectly/directly the driver is dependent on the SMEM_STATE drivers.




I agree with you that this leads to wasted time trying figure out if
we're missing drivers/modules in the kernel, but I think that needs to
be solved in a more generic way.


Signed-off-by: Srinivas Kandagatla 
---
  drivers/remoteproc/Kconfig | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 8891a8e50f12..052c9e20abb6 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -87,6 +87,7 @@ config QCOM_ADSP_PIL
select QCOM_MDT_LOADER
select QCOM_RPROC_COMMON
select QCOM_SCM
+   select QCOM_SMP2P


I agree, instead of select, we should mark these configs with a

depends on QCOM_SMEM_STATE


so that the final pil kconfigs are only selected with right dependencies 
are in place.

Does that sound okay?


thanks,
srini



NB. QCOM_SMP2P is a user-selectable config option, so you are not
allowed to "select" it, only "depends on" it.

Regards,
Bjorn

Re: [PATCH 3/3] ima: use fs method to read integrity data

[Mimi Zohar]

On Fri, 2017-09-15 at 05:04 -0400, Mimi Zohar wrote:
> On Thu, 2017-09-14 at 22:50 -0700, Linus Torvalds wrote:
> > This is still wrong.
> > 
> > (a) there is no explanation for why we need that exclusive lock in the
> > first place
> 
> > Why should a read need exclusive access? You'd think shared is sufficient.
> 
> True, reading a file shouldn't require an exclusive lock.  The
> exclusive lock is taken to prevent the file from changing while the
> file hash is being calculated.

And also to prevent the file hash from being calculated multiple
times.

> 
> > But regardless, it needs *explanation*.
> 
> Agreed.  A fuller explanation was included in the cover letter that
> should have also been included in the patch description.  The
> following is taken from the cover letter:
> 
> With the introduction of IMA-appraisal and the need to write file
> hashes as security xattrs, IMA needed to take the global i_mutex
> lock.  process_measurement() took the iint->mutex first and then
> the i_mutex, while setxattr, chmod and chown took the locks in
> reverse order.  To resolve this potential deadlock, the iint->mutex
> was removed.
> 
> Some filesystems have recently replaced their filesystem dependent
> lock with the global i_rwsem (formerly the i_mutex) to read a file.
> As a result, when IMA attempts to calculate the file hash, reading
> the file attempts to take the i_rwsem again.
> 
> To resolve this locking problem, this patch set defines a new
> ->integrity_read file operation method.
> 
> (Fixes: Commit 6552321831dc "xfs: remove i_iolock and use i_rwsem in
> the VFS inode instead")
> 
> Mimi
> 
> > (b) the lockdep test isn't for the exclusive lock that the code comment
> > says it is
> > 
> > So no, this needs more work.
> > 
> > Linus
> > 
> 
> > 
> > On Sep 14, 2017 21:59, "Mimi Zohar"  wrote:
> > 
> > > From: Christoph Hellwig 
> > >
> > > Add a new ->integrity_read file operation to read data for integrity
> > > hash collection.  This is defined to be equivalent to ->read_iter,
> > > except that it will be called with the i_rwsem held exclusively.
> > >
> > > (Based on Christoph's original patch.)
> > >
> > > Signed-off-by: Christoph Hellwig 
> > > Cc: Matthew Garrett 
> > > Cc: Jan Kara 
> > > Cc: "Theodore Ts'o" 
> > > Cc: Andreas Dilger 
> > > Cc: Jaegeuk Kim 
> > > Cc: Chao Yu 
> > > Cc: Steven Whitehouse 
> > > Cc: Bob Peterson 
> > > Cc: David Woodhouse 
> > > Cc: Dave Kleikamp 
> > > Cc: Ryusuke Konishi 
> > > Cc: Mark Fasheh 
> > > Cc: Joel Becker 
> > > Cc: Richard Weinberger 
> > > Cc: "Darrick J. Wong" 
> > > Cc: Hugh Dickins 
> > > Cc: Chris Mason 
> > > Signed-off-by: Mimi Zohar 
> > > Reviewed-by: Jan Kara 
> > > Reviewed-by: Dmitry Kasatkin 
> > > ---
> > >  fs/btrfs/file.c   |  1 +
> > >  fs/efivarfs/file.c|  1 +
> > >  fs/ext2/file.c| 17 +
> > >  fs/ext4/file.c| 20 
> > >  fs/f2fs/file.c|  1 +
> > >  fs/jffs2/file.c   |  1 +
> > >  fs/jfs/file.c |  1 +
> > >  fs/nilfs2/file.c  |  1 +
> > >  fs/ramfs/file-mmu.c   |  1 +
> > >  fs/ramfs/file-nommu.c |  1 +
> > >  fs/ubifs/file.c   |  1 +
> > >  fs/xfs/xfs_file.c | 21 +
> > >  include/linux/fs.h|  1 +
> > >  mm/shmem.c|  1 +
> > >  security/integrity/iint.c | 20 ++--
> > >  15 files changed, 83 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> > > index 9e75d8a39aac..2542dc66c85c 100644
> > > --- a/fs/btrfs/file.c
> > > +++ b/fs/btrfs/file.c
> > > @@ -3125,6 +3125,7 @@ const struct file_operations btrfs_file_operations =
> > > {
> > >  #endif
> > > .clone_file_range = btrfs_clone_file_range,
> > > .dedupe_file_range = btrfs_dedupe_file_range,
> > > +   .integrity_read = generic_file_read_iter,
> > >  };
> > >
> > >  void btrfs_auto_defrag_exit(void)
> > > diff --git a/fs/efivarfs/file.c b/fs/efivarfs/file.c
> > > index 863f1b100165..17955a92a5b3 100644
> > > --- a/fs/efivarfs/file.c
> > > +++ b/fs/efivarfs/file.c
> > > @@ -179,4 +179,5 @@ const struct file_operations efivarfs_file_operations
> > > = {
> > > .write  = efivarfs_file_write,
> > > .llseek = no_llseek,
> > > .unlocked_ioctl = efivarfs_file_ioctl,
> > > +   .integrity_read = efivarfs_file_read_iter,
> > >  };
> > > diff --git a/fs/ext2/file.c b/fs/ext2/file.c
> > > index d34d32bdc944..111069de1973 100644
> > > --- a/fs/ext2/file.c
> > > +++ b/fs/ext2/file.c
> > > @@ -192,6 +192,22 @@ static ssize_t ext2_file_read_iter(struct kiocb
> > > *iocb, struct iov_iter *to)
> > > return generic_file_read_iter(iocb, to);
> > >  }
> > >
> > > +static ssize_t ext2_file_integrity_read_iter(struct kiocb *iocb,
> > > +struct iov_iter *to)
> > > +{
> > > +   struct inode *inode = file_inode(iocb->ki_filp);
> > > +
> > > +   lockdep_assert_held(&in

Re: x60: warnings on boot and resume, arch/x86/mm/tlb.c:257 initialize_ ... was Re: [PATCH 0/2] Fix resume failure due to PCID

[Pavel Machek]

Hi!

> * Pavel Machek  wrote:
> 
> > On Wed 2017-09-06 20:25:10, Linus Torvalds wrote:
> > > On Wed, Sep 6, 2017 at 7:54 PM, Andy Lutomirski  wrote:
> > > > Patch 1 is the fix.  Patch 2 is a comment that would have kept me from
> > > > chasing down a false lead.
> > > 
> > > Yes, this seems to fix things for me. Thanks.
> > > 
> > > Of course, right now that laptop has no working wifi with tip-of-tree
> > > due to some issues with the networking tree, but that's an independent
> > > thing and I could suspend and resume with this. So applied and pushed
> > > out,
> > 
> > Ok, seems this is still not completely right, I'm now getting WARN_ON
> > during boot and on every resume... but machine works.
> > 
> > 4.14-rc0, 32-bit.
> 
> Which SHA1, just to make sure? (Please enable CONFIG_LOCALVERSION_AUTO=y.)

46c1e79fee417f151547aa46fae04ab06cb666f4, AFAICT.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[GIT PULL] Please pull powerpc/linux.git powerpc-4.14-2 tag

[Michael Ellerman]

Hi Linus,

Please pull one powerpc fix for 4.14:

The following changes since commit bac65d9d87b383471d8d29128319508d71b74180:

  Merge tag 'powerpc-4.14-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2017-09-07 
10:15:40 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.14-2

for you to fetch changes up to 1bc944cee663f232e3c37b15a6b2f9185bca413c:

  powerpc: Fix handling of alignment interrupt on dcbz instruction (2017-09-15 
08:41:18 +1000)


powerpc fixes for 4.14 #2

Just one fix, for the handling of alignment interrupts on dcbz instructions.

Thanks to:
  Paul Mackerras, Christian Zigotzky, Michal Sojka.


Paul Mackerras (1):
  powerpc: Fix handling of alignment interrupt on dcbz instruction

 arch/powerpc/kernel/align.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


signature.asc
Description: PGP signature

[PATCH 0/3] Handle zone statistics distinctively based-on

[Kemi Wang]

Each page allocation updates a set of per-zone statistics with a call to
zone_statistics(). As discussed in 2017 MM summit.
A link to the MM summit slides:
http://people.netfilter.org/hawk/presentations/MM-summit2017/MM-summit2017
-JesperBrouer.pdf

This is the second step for optimizing zone statistics, the first patch
introduces a tunable interface that allow VM statistics configurable(see
the first patch for details):
if vmstat_mode = auto, automatic detection of VM statistics
if vmstat_mode = strict, keep all the VM statistics
if vmstat_mode = coarse, ignore unimportant VM statistics
As suggested by Dave Hansen and Ying Huang.

With this interface, the second patch handles numa counters distinctively
according to different vmstat mode, and the test result shows about 4.8%
(185->176) drop of cpu cycles with single thread and 8.1% (343->315) drop
of of cpu cycles with 88 threads for single page allocation.

The third patch updates ABI document accordingly.

Kemi Wang (3):
  mm, sysctl: make VM stats configurable
  mm: Handle numa statistics distinctively based-on different VM stats
modes
  sysctl/vm.txt: Update document

 Documentation/sysctl/vm.txt |  26 ++
 drivers/base/node.c |   2 +
 include/linux/vmstat.h  |  20 +++
 kernel/sysctl.c |   7 +++
 mm/page_alloc.c |  13 +
 mm/vmstat.c | 124 
 6 files changed, 192 insertions(+)

-- 
2.7.4

[PATCH 3/3] sysctl/vm.txt: Update document

[Kemi Wang]

Add a paragraph to introduce the functionality and usage on vmstat_mode in
sysctl/vm.txt

Reported-by: Jesper Dangaard Brouer 
Suggested-by: Dave Hansen 
Suggested-by: Ying Huang 
Signed-off-by: Kemi Wang 
---
 Documentation/sysctl/vm.txt | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 9baf66a..6ab2843 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -61,6 +61,7 @@ Currently, these files are in /proc/sys/vm:
 - swappiness
 - user_reserve_kbytes
 - vfs_cache_pressure
+- vmstat_mode
 - watermark_scale_factor
 - zone_reclaim_mode
 
@@ -843,6 +844,31 @@ ten times more freeable objects than there are.
 
 =
 
+vmstat_mode
+
+This interface allows virtual memory statistics configurable.
+
+When performance becomes a bottleneck and you can tolerate some possible
+tool breakage and some decreased counter precision (e.g. numa counter), you
+can do:
+   echo [C|c]oarse > /proc/sys/vm/vmstat_mode
+ignorable statistics list:
+- numa counters
+
+When performance is not a bottleneck and you want all tooling to work, you
+can do:
+   echo [S|s]trict > /proc/sys/vm/vmstat_mode
+
+We recommend automatic detection of virtual memory statistics by system,
+this is also system default configuration, you can do:
+   echo [A|a]uto > /proc/sys/vm/vmstat_mode
+
+E.g. numa statistics does not affect system's decision and it is very
+rarely consumed. If set vmstat_mode = auto, numa counters update is skipped
+unless the counter is *read* by users at least once.
+
+==
+
 watermark_scale_factor:
 
 This factor controls the aggressiveness of kswapd. It defines the
-- 
2.7.4

[PATCH 2/3] mm: Handle numa statistics distinctively based-on different VM stats modes

[Kemi Wang]

Each page allocation updates a set of per-zone statistics with a call to
zone_statistics().  As discussed at the 2017 MM Summit, these are a
substantial source of overhead in the page allocator and are very rarely
consumed.

A link to the MM summit slides:
http://people.netfilter.org/hawk/presentations/MM-summit2017/MM-summit2017
-JesperBrouer.pdf

Therefore, with different VM stats mode, numa counters update can operate
differently so that everybody can benefit:
If vmstat_mode = auto, automatic detection of numa statistics, numa counter
update is skipped unless it has been read by users at least once,
e.g. cat /proc/zoneinfo.

If vmstat_mode = strict, numa counter is updated for each page allocation.

If vmstat_mode = coarse, numa counter update is ignored. We can see about
*4.8%*(185->176) drop of cpu cycles per single page allocation and reclaim
on Jesper's page_bench01 (single thread) and *8.1%*(343->315) drop of cpu
cycles per single page allocation and reclaim on Jesper's page_bench03 (88
threads) running on a 2-Socket Broadwell-based server (88 threads, 126G
memory).

Benchmark link provided by Jesper D Brouer(increase loop times to
1000):
https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/
bench

Reported-by: Jesper Dangaard Brouer 
Suggested-by: Dave Hansen 
Suggested-by: Ying Huang 
Signed-off-by: Kemi Wang 
---
 drivers/base/node.c|  2 ++
 include/linux/vmstat.h |  6 +
 mm/page_alloc.c| 13 +++
 mm/vmstat.c| 60 +++---
 4 files changed, 78 insertions(+), 3 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 3855902..033c0c3 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -153,6 +153,7 @@ static DEVICE_ATTR(meminfo, S_IRUGO, node_read_meminfo, 
NULL);
 static ssize_t node_read_numastat(struct device *dev,
struct device_attribute *attr, char *buf)
 {
+   disable_zone_statistics = false;
return sprintf(buf,
   "numa_hit %lu\n"
   "numa_miss %lu\n"
@@ -194,6 +195,7 @@ static ssize_t node_read_vmstat(struct device *dev,
 NR_VM_NUMA_STAT_ITEMS],
 node_page_state(pgdat, i));
 
+   disable_zone_statistics = false;
return n;
 }
 static DEVICE_ATTR(vmstat, S_IRUGO, node_read_vmstat, NULL);
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index c3634c7..ca9854c 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -9,6 +9,7 @@
 
 extern int sysctl_stat_interval;
 
+extern bool disable_zone_statistics;
 /*
  * vmstat_mode:
  * 0 = auto mode of vmstat, automatic detection of VM statistics.
@@ -19,6 +20,7 @@ extern int sysctl_stat_interval;
 #define VMSTAT_STRICT_MODE  1
 #define VMSTAT_COARSE_MODE  2
 #define VMSTAT_MODE_LEN 16
+extern int vmstat_mode;
 extern char sysctl_vmstat_mode[];
 extern int sysctl_vmstat_mode_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos);
@@ -243,6 +245,10 @@ extern unsigned long sum_zone_node_page_state(int node,
 extern unsigned long sum_zone_numa_state(int node, enum numa_stat_item item);
 extern unsigned long node_page_state(struct pglist_data *pgdat,
enum node_stat_item item);
+extern void zero_zone_numa_counters(struct zone *zone);
+extern void zero_zones_numa_counters(void);
+extern void zero_global_numa_counters(void);
+extern void invalid_numa_statistics(void);
 #else
 #define sum_zone_node_page_state(node, item) global_zone_page_state(item)
 #define node_page_state(node, item) global_node_page_state(item)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c841af8..010a620 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -83,6 +83,8 @@ DEFINE_PER_CPU(int, numa_node);
 EXPORT_PER_CPU_SYMBOL(numa_node);
 #endif
 
+bool disable_zone_statistics = true;
+
 #ifdef CONFIG_HAVE_MEMORYLESS_NODES
 /*
  * N.B., Do NOT reference the '_numa_mem_' per cpu variable directly.
@@ -2743,6 +2745,17 @@ static inline void zone_statistics(struct zone 
*preferred_zone, struct zone *z)
 #ifdef CONFIG_NUMA
enum numa_stat_item local_stat = NUMA_LOCAL;
 
+   /*
+* skip zone_statistics() if vmstat is a coarse mode or zone statistics
+* is inactive in auto vmstat mode
+*/
+
+   if (vmstat_mode) {
+   if (vmstat_mode == VMSTAT_COARSE_MODE)
+   return;
+   } else if (disable_zone_statistics)
+   return;
+
if (z->node != numa_node_id())
local_stat = NUMA_OTHER;
 
diff --git a/mm/vmstat.c b/mm/vmstat.c
index e675ad2..bcaef62 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -85,15 +85,31 @@ int sysctl_vmstat_mode_handler(struct ctl_table *table, int 
write,
/* no change */
mutex_unlock(&vmstat_mode_lock);

[PATCH 1/3] mm, sysctl: make VM stats configurable

[Kemi Wang]

This patch adds a tunable interface that allows VM stats configurable, as
suggested by Dave Hansen and Ying Huang.

When performance becomes a bottleneck and you can tolerate some possible
tool breakage and some decreased counter precision (e.g. numa counter), you
can do:
echo [C|c]oarse > /proc/sys/vm/vmstat_mode

When performance is not a bottleneck and you want all tooling to work, you
can do:
echo [S|s]trict > /proc/sys/vm/vmstat_mode

We recommend automatic detection of virtual memory statistics by system,
this is also system default configuration, you can do:
echo [A|a]uto > /proc/sys/vm/vmstat_mode

The next patch handles numa statistics distinctively based-on different VM
stats mode.

Reported-by: Jesper Dangaard Brouer 
Suggested-by: Dave Hansen 
Suggested-by: Ying Huang 
Signed-off-by: Kemi Wang 
---
 include/linux/vmstat.h | 14 ++
 kernel/sysctl.c|  7 +
 mm/vmstat.c| 70 ++
 3 files changed, 91 insertions(+)

diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
index ade7cb5..c3634c7 100644
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -9,6 +9,20 @@
 
 extern int sysctl_stat_interval;
 
+/*
+ * vmstat_mode:
+ * 0 = auto mode of vmstat, automatic detection of VM statistics.
+ * 1 = strict mode of vmstat, keep all VM statistics.
+ * 2 = coarse mode of vmstat, ignore unimportant VM statistics.
+ */
+#define VMSTAT_AUTO_MODE 0
+#define VMSTAT_STRICT_MODE  1
+#define VMSTAT_COARSE_MODE  2
+#define VMSTAT_MODE_LEN 16
+extern char sysctl_vmstat_mode[];
+extern int sysctl_vmstat_mode_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos);
+
 #ifdef CONFIG_VM_EVENT_COUNTERS
 /*
  * Light weight per cpu counter implementation.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbb..f5b813b 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1234,6 +1234,13 @@ static struct ctl_table kern_table[] = {
 
 static struct ctl_table vm_table[] = {
{
+   .procname   = "vmstat_mode",
+   .data   = &sysctl_vmstat_mode,
+   .maxlen = VMSTAT_MODE_LEN,
+   .mode   = 0644,
+   .proc_handler   = sysctl_vmstat_mode_handler,
+   },
+   {
.procname   = "overcommit_memory",
.data   = &sysctl_overcommit_memory,
.maxlen = sizeof(sysctl_overcommit_memory),
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 4bb13e7..e675ad2 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -32,6 +32,76 @@
 
 #define NUMA_STATS_THRESHOLD (U16_MAX - 2)
 
+int vmstat_mode = VMSTAT_AUTO_MODE;
+char sysctl_vmstat_mode[VMSTAT_MODE_LEN] = "auto";
+static const char *vmstat_mode_name[3] = {"auto", "strict", "coarse"};
+static DEFINE_MUTEX(vmstat_mode_lock);
+
+
+static int __parse_vmstat_mode(char *s)
+{
+   const char *str = s;
+
+   if (strcmp(str, "auto") == 0 || strcmp(str, "Auto") == 0)
+   vmstat_mode = VMSTAT_AUTO_MODE;
+   else if (strcmp(str, "strict") == 0 || strcmp(str, "Strict") == 0)
+   vmstat_mode = VMSTAT_STRICT_MODE;
+   else if (strcmp(str, "coarse") == 0 || strcmp(str, "Coarse") == 0)
+   vmstat_mode = VMSTAT_COARSE_MODE;
+   else {
+   pr_warn("Ignoring invalid vmstat_mode value: %s\n", s);
+   return -EINVAL;
+   }
+   return 0;
+}
+
+int sysctl_vmstat_mode_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos)
+{
+   char old_string[VMSTAT_MODE_LEN];
+   int ret, oldval;
+
+   mutex_lock(&vmstat_mode_lock);
+   if (write)
+   strncpy(old_string, (char *)table->data, VMSTAT_MODE_LEN);
+   ret = proc_dostring(table, write, buffer, length, ppos);
+   if (ret || !write) {
+   mutex_unlock(&vmstat_mode_lock);
+   return ret;
+   }
+
+   oldval = vmstat_mode;
+   if (__parse_vmstat_mode((char *)table->data)) {
+   /*
+* invalid sysctl_vmstat_mode value, restore saved string
+*/
+   strncpy((char *)table->data, old_string, VMSTAT_MODE_LEN);
+   vmstat_mode = oldval;
+   } else {
+   /*
+* check whether vmstat mode changes or not
+*/
+   if (vmstat_mode == oldval) {
+   /* no change */
+   mutex_unlock(&vmstat_mode_lock);
+   return 0;
+   } else if (vmstat_mode == VMSTAT_AUTO_MODE)
+   pr_info("vmstat mode changes from %s to auto mode\n",
+   vmstat_mode_name[oldval]);
+   else if (vmstat_mode == VMSTAT_STRICT_MODE)
+   pr_info("vmstat mode changes from %s to strict mode\n",
+ 

Re: WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:237 initialize_tlbstate_and_flush+0x120/0x130

[Paul Menzel]

Dear Andy,


On 09/10/17 19:42, Andy Lutomirski wrote:

On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel  wrote:



With Linux built from commit 4dfc2788033d (Merge tag 'iommu-updates-v4.14'
of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu), I get the
warning below on a Lenovo X60t with a 32-bit CPU.


Indeed.  I sent a patch this morning.  The warning is harmless -- the
warning condition has a typo.


I am still seeing this with commit 711aab1dbb32 (vfs: constify path 
argument to kernel_read_file_from_path), which is the latest from Linus’ 
master branch.


```
[0.004000] [ cut here ]
[0.004000] WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:257 
initialize_tlbstate_and_flush+0x120/0x130

[0.004000] Modules linked in:
[0.004000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0+ #132
[0.004000] Hardware name: LENOVO 636338U/636338U, BIOS CBET4000 
TIMELESS 01/01/1970

[0.004000] task: f4113380 task.stack: f4118000
[0.004000] EIP: initialize_tlbstate_and_flush+0x120/0x130
[0.004000] EFLAGS: 00210006 CPU: 1
[0.004000] EAX: 159bd000 EBX: d5892d00 ECX: d59c EDX: 159c
[0.004000] ESI:  EDI:  EBP: f4119f60 ESP: f4119f50
[0.004000]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[0.004000] CR0: 80050033 CR2:  CR3: 159bd000 CR4: 0690
[0.004000] Call Trace:
[0.004000]  cpu_init+0xc3/0x260
[0.004000]  start_secondary+0x33/0x1c0
[0.004000]  startup_32_smp+0x164/0x166
[0.004000] Code: 04 00 00 00 00 89 c8 50 9d 8d 74 26 00 83 c3 10 81 
fb 4c 50 9b d5 75 c9 58 5b 5e 5f 5d c3 90 8d 74 26 00 0f ff e9 3c ff ff 
ff 90 <0f> ff e9 13 ff ff ff 89 f6 8d bc 27 00 00 00 00 3e 8d 74 26 00

[0.004000] ---[ end trace 17f2b31512589856 ]---
```


Kind regards,

Paul

Re: [PATCH] clk: tegra: Use readl_relaxed_poll_timeout_atomic in tegra210_clock_init

[Peter De Schrijver]

Apart from the typo in the commit message (preemption rather than preemtion):

Acked-By: Peter De Schrijver 

On Thu, Sep 14, 2017 at 06:36:14PM -0700, Nicolin Chen wrote:
> Below is the call trace of tegra210_init_pllu() function:
>   start_kernel()
>   -> time_init()
>   --> of_clk_init()
>   ---> tegra210_clock_init()
>   > tegra210_pll_init()
>   -> tegra210_init_pllu()
> 
> Because the preemtion is disabled in the start_kernel before calling
> time_init, tegra210_init_pllu is actually in an atomic context while
> it includes a readl_relaxed_poll_timeout that might sleep.
> 
> So this patch just changes this readl_relaxed_poll_timeout() to its
> atomic version.
> 
> Signed-off-by: Nicolin Chen 
> ---
>  drivers/clk/tegra/clk-tegra210.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-tegra210.c 
> b/drivers/clk/tegra/clk-tegra210.c
> index 0b9789a..ea695c4 100644
> --- a/drivers/clk/tegra/clk-tegra210.c
> +++ b/drivers/clk/tegra/clk-tegra210.c
> @@ -2587,8 +2587,8 @@ static int tegra210_enable_pllu(void)
>   reg |= PLL_ENABLE;
>   writel(reg, clk_base + PLLU_BASE);
>  
> - readl_relaxed_poll_timeout(clk_base + PLLU_BASE, reg,
> -reg & PLL_BASE_LOCK, 2, 1000);
> + readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
> +   reg & PLL_BASE_LOCK, 2, 1000);
>   if (!(reg & PLL_BASE_LOCK)) {
>   pr_err("Timed out waiting for PLL_U to lock\n");
>   return -ETIMEDOUT;
> -- 
> 2.1.4
> 

Re: [PATCH] crypto: s5p-sss: Add HASH support for Exynos

[kbuild test robot]

Hi Kamil,

[auto build test WARNING on cryptodev/master]
[also build test WARNING on v4.13 next-20170915]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kamil-Konieczny/crypto-s5p-sss-Add-HASH-support-for-Exynos/20170915-161309
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All warnings (new ones prefixed by >>):

   drivers//crypto/s5p-sss.c: In function 's5p_hash_xmit_dma':
>> drivers//crypto/s5p-sss.c:1153:2: warning: format '%d' expects argument of 
>> type 'int', but argument 5 has type 'size_t' [-Wformat]

vim +1153 drivers//crypto/s5p-sss.c

  1131  
  1132  /**
  1133   * s5p_hash_xmit_dma - start DMA hash processing
  1134   * @dd: secss device
  1135   * @length: length for request
  1136   * @final:  0=not final
  1137   *
  1138   * Map ctx->sg into DMA_TO_DEVICE,
  1139   * remember sg and cnt in device dd->hash_sg_iter, dd->hash_sg_cnt
  1140   * so it can be used in loop inside irq handler.
  1141   * Update ctx->digcnt, need this to keep number of processed bytes
  1142   * for last final/finup request.
  1143   * Set dma address and length, this starts DMA,
  1144   * return with -EINPROGRESS.
  1145   * HW HASH block will issue signal for irq handler.
  1146   */
  1147  static int s5p_hash_xmit_dma(struct s5p_aes_dev *dd, size_t length,
  1148int final)
  1149  {
  1150  struct s5p_hash_reqctx *ctx = ahash_request_ctx(dd->hash_req);
  1151  int cnt;
  1152  
> 1153  dev_dbg(dd->dev, "xmit_dma: digcnt: %lld, length: %d, final: 
> %d\n",
  1154  ctx->digcnt, length, 
final);
  1155  
  1156  cnt = dma_map_sg(dd->dev, ctx->sg, ctx->sg_len, DMA_TO_DEVICE);
  1157  if (!cnt) {
  1158  dev_err(dd->dev, "dma_map_sg error\n");
  1159  set_bit(HASH_FLAGS_ERROR, &ctx->flags);
  1160  return -EINVAL;
  1161  }
  1162  
  1163  FLOW_LOG("xmit_dma");
  1164  set_bit(HASH_FLAGS_DMA_ACTIVE, &dd->hash_flags);
  1165  
  1166  dd->hash_sg_iter = ctx->sg;
  1167  dd->hash_sg_cnt = cnt;
  1168  FLOW_LOG("xmit_dma cnt=%d final=%d len=%d", cnt, final, length);
  1169  
  1170  s5p_hash_write_ctrl(dd, length, final);
  1171  
  1172  /* update digcnt in request */
  1173  ctx->digcnt += length;
  1174  ctx->total -= length;
  1175  
  1176  /* catch last interrupt */
  1177  if (final)
  1178  set_bit(HASH_FLAGS_FINAL, &dd->hash_flags);
  1179  
  1180  s5p_set_dma_hashdata(dd, dd->hash_sg_iter); /* DMA starts */
  1181  
  1182  return -EINPROGRESS;
  1183  }
  1184  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: x60: warnings on boot and resume, arch/x86/mm/tlb.c:257 initialize_ ... was Re: [PATCH 0/2] Fix resume failure due to PCID

[Ingo Molnar]

* Pavel Machek  wrote:

> Hi!
> 
> > * Pavel Machek  wrote:
> > 
> > > On Wed 2017-09-06 20:25:10, Linus Torvalds wrote:
> > > > On Wed, Sep 6, 2017 at 7:54 PM, Andy Lutomirski  wrote:
> > > > > Patch 1 is the fix.  Patch 2 is a comment that would have kept me from
> > > > > chasing down a false lead.
> > > > 
> > > > Yes, this seems to fix things for me. Thanks.
> > > > 
> > > > Of course, right now that laptop has no working wifi with tip-of-tree
> > > > due to some issues with the networking tree, but that's an independent
> > > > thing and I could suspend and resume with this. So applied and pushed
> > > > out,
> > > 
> > > Ok, seems this is still not completely right, I'm now getting WARN_ON
> > > during boot and on every resume... but machine works.
> > > 
> > > 4.14-rc0, 32-bit.
> > 
> > Which SHA1, just to make sure? (Please enable CONFIG_LOCALVERSION_AUTO=y.)
> 
> 46c1e79fee417f151547aa46fae04ab06cb666f4, AFAICT.

Ok, just to reiterate: that SHA1 has all relevant and current fixes included, 
so 
this definitely is an open regression.

Thanks,

Ingo

Re: [PATCH] mm/memory_hotplug: fix wrong casting for __remove_section()

[Michal Hocko]

On Thu 14-09-17 11:43:10, YASUAKI ISHIMATSU wrote:
> Hi Michal,
> 
> On 09/13/2017 01:59 AM, Michal Hocko wrote:
> > On Tue 12-09-17 13:05:39, YASUAKI ISHIMATSU wrote:
> >> Hi Michal,
> >>
> >> Thanks you for reviewing my patch.
> >>
> >> On 09/12/2017 08:49 AM, Michal Hocko wrote:
> >>> On Fri 08-09-17 16:43:04, YASUAKI ISHIMATSU wrote:
>  __remove_section() calls __remove_zone() to shrink zone and pgdat.
>  But due to wrong castings, __remvoe_zone() cannot shrink zone
>  and pgdat correctly if pfn is over 0x.
> 
>  So the patch fixes the following 3 wrong castings.
> 
>    1. find_smallest_section_pfn() returns 0 or start_pfn which defined
>   as unsigned long. But the function always returns 32bit value
>   since the function is defined as int.
> 
>    2. find_biggest_section_pfn() returns 0 or pfn which defined as
>   unsigned long. the function always returns 32bit value
>   since the function is defined as int.
> >>>
> >>> this is indeed wrong. Pfns over would be really broken 15TB. Not that
> >>> unrealistic these days
> >>
> >> Why 15TB?
> > 
> > 0x>>28
> > 
> 
> Even thought I see your explanation, I cannot understand.
> 
> In my understanding, find_{smallest|biggest}_section_pfn() return integer.
> So the functions always return 0x - 0x. Therefore if pfn is 
> over
> 0x (under 16TB), then the function cannot work correctly.
> 
> What am I wrong?

You are not wrong. We are talking about the same thing AFAICS. I was
just less precise...

-- 
Michal Hocko
SUSE Labs

[tip:x86/urgent] x86/cpu/AMD: Fix erratum 1076 (CPB bit)

[tip-bot for Borislav Petkov]

Commit-ID:  f7f3dc00f61261cdc9ccd8b886f21bc4dffd6fd9
Gitweb: http://git.kernel.org/tip/f7f3dc00f61261cdc9ccd8b886f21bc4dffd6fd9
Author: Borislav Petkov 
AuthorDate: Thu, 7 Sep 2017 19:08:21 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 11:30:53 +0200

x86/cpu/AMD: Fix erratum 1076 (CPB bit)

CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on models up to B1. But they do
support CPB (AMD's Core Performance Boosting cpufreq CPU feature), so fix that.

Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sherry Hurwitz 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170907170821.16021-1...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/amd.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9862e2c..d58184b 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -763,6 +763,16 @@ static void init_amd_bd(struct cpuinfo_x86 *c)
}
 }
 
+static void init_amd_zn(struct cpuinfo_x86 *c)
+{
+   /*
+* Fix erratum 1076: CPB feature bit not being set in CPUID. It affects
+* all up to and including B1.
+*/
+   if (c->x86_model <= 1 && c->x86_mask <= 1)
+   set_cpu_cap(c, X86_FEATURE_CPB);
+}
+
 static void init_amd(struct cpuinfo_x86 *c)
 {
early_init_amd(c);
@@ -791,6 +801,7 @@ static void init_amd(struct cpuinfo_x86 *c)
case 0x10: init_amd_gh(c); break;
case 0x12: init_amd_ln(c); break;
case 0x15: init_amd_bd(c); break;
+   case 0x17: init_amd_zn(c); break;
}
 
/* Enable workaround for FXSAVE leak */

[tip:core/urgent] objtool: Do not retrieve data from empty sections

[tip-bot for Petr Vandrovec]

Commit-ID:  df968c9329f6e5cf3596a0a54adb6f749747a746
Gitweb: http://git.kernel.org/tip/df968c9329f6e5cf3596a0a54adb6f749747a746
Author: Petr Vandrovec 
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 11:31:50 +0200

objtool: Do not retrieve data from empty sections

Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:

  elf_getdata: can't manipulate null section

As nothing is done with sections that have zero size, just do not
retrieve their data at all.

Signed-off-by: Petr Vandrovec 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/2ce30a44349065b70d0f00e71e286dc0cbe745e6.1505459652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/objtool/elf.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 1e89a5f..b4cd8bc 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
 
-   sec->data = elf_getdata(s, NULL);
-   if (!sec->data) {
-   WARN_ELF("elf_getdata");
-   return -1;
-   }
-
-   if (sec->data->d_off != 0 ||
-   sec->data->d_size != sec->sh.sh_size) {
-   WARN("unexpected data attributes for %s", sec->name);
-   return -1;
+   if (sec->sh.sh_size != 0) {
+   sec->data = elf_getdata(s, NULL);
+   if (!sec->data) {
+   WARN_ELF("elf_getdata");
+   return -1;
+   }
+   if (sec->data->d_off != 0 ||
+   sec->data->d_size != sec->sh.sh_size) {
+   WARN("unexpected data attributes for %s",
+sec->name);
+   return -1;
+   }
}
-
-   sec->len = sec->data->d_size;
+   sec->len = sec->sh.sh_size;
}
 
/* sanity check, one more call to elf_nextscn() should return NULL */

[tip:core/urgent] objtool: Fix memory leak in elf_create_rela_section()

[tip-bot for Martin Kepplinger]

Commit-ID:  0998b7a0befdf6e734032895ee639a5e6f88cc3f
Gitweb: http://git.kernel.org/tip/0998b7a0befdf6e734032895ee639a5e6f88cc3f
Author: Martin Kepplinger 
AuthorDate: Thu, 14 Sep 2017 08:01:38 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 11:31:43 +0200

objtool: Fix memory leak in elf_create_rela_section()

Let's free the allocated char array 'relaname' before returning,
in order to avoid leaking memory.

Signed-off-by: Martin Kepplinger 
Acked-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: mingo.kernel@gmail.com
Link: http://lkml.kernel.org/r/20170914060138.26472-1-mart...@posteo.de
Signed-off-by: Ingo Molnar 
---
 tools/objtool/elf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 6e9f980..1e89a5f 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -508,6 +508,7 @@ struct section *elf_create_rela_section(struct elf *elf, 
struct section *base)
strcat(relaname, base->name);
 
sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0);
+   free(relaname);
if (!sec)
return NULL;
 

[tip:core/urgent] objtool: Fix object file corruption

[tip-bot for Josh Poimboeuf]

Commit-ID:  97dab2ae7e8473a821f72a039ead0f36b12ba22d
Gitweb: http://git.kernel.org/tip/97dab2ae7e8473a821f72a039ead0f36b12ba22d
Author: Josh Poimboeuf 
AuthorDate: Fri, 15 Sep 2017 02:17:11 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 15 Sep 2017 11:31:57 +0200

objtool: Fix object file corruption

Arnd Bergmann reported that a randconfig build was failing with the
following link error:

  built-in.o: member arch/x86/kernel/time.o in archive is not an object

It turns out the link failed because the time.o file had been corrupted
by objtool:

  nm: arch/x86/kernel/time.o: File format not recognized

In certain rare cases, when a .o file's ORC table is very small, the
.data section size doesn't change because it's page aligned.  Because
all the existing sections haven't changed size, libelf doesn't detect
any section header changes, and so it doesn't update the section header
table properly.  Instead it writes junk in the section header entries
for the new ORC sections.

Make sure libelf properly updates the section header table by setting
the ELF_F_DIRTY flag in the top level elf struct.

Reported-by: Arnd Bergmann 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 627fce14809b ("objtool: Add ORC unwind table generation")
Link: 
http://lkml.kernel.org/r/e650fd0f2d8a209d1409a9785deb101fdaed55fb.1505459813.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/objtool/elf.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index b4cd8bc..2446015 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -563,6 +563,7 @@ int elf_write(struct elf *elf)
struct section *sec;
Elf_Scn *s;
 
+   /* Update section headers for changed sections: */
list_for_each_entry(sec, &elf->sections, list) {
if (sec->changed) {
s = elf_getscn(elf->elf, sec->idx);
@@ -570,13 +571,17 @@ int elf_write(struct elf *elf)
WARN_ELF("elf_getscn");
return -1;
}
-   if (!gelf_update_shdr (s, &sec->sh)) {
+   if (!gelf_update_shdr(s, &sec->sh)) {
WARN_ELF("gelf_update_shdr");
return -1;
}
}
}
 
+   /* Make sure the new section header entries get updated properly. */
+   elf_flagelf(elf->elf, ELF_C_SET, ELF_F_DIRTY);
+
+   /* Write all changes to the file. */
if (elf_update(elf->elf, ELF_C_WRITE) < 0) {
WARN_ELF("elf_update");
return -1;

Re: [PATCH] clk: sunxi-ng: Fix missing CLK_SET_RATE_PARENT in ccu-sun4i-a10.c

[Maxime Ripard]

On Thu, Sep 14, 2017 at 08:14:10PM +0800, Chen-Yu Tsai wrote:
> On Thu, Sep 14, 2017 at 8:05 PM, Alexander Syring  wrote:
> > When using cpufreq-dt with default govenor other than "performance"
> > system freezes while booting.
> > Adding CLK_SET_RATE_PARENT | CLK_IS_CRITICAL to clk_cpu fixes the
> > problem.
> >
> > Tested on Cubietruck (A20).
> >
> > Fixes: c84f5683f6E ("clk: sunxi-ng: Add sun4i/sun7i CCU driver")
> >
> > Reported-by: Alexander Syring 
> 
> You typically don't need this if you yourself are the reporter.

Queued for 4.15.

Thanks!
Maxime

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


signature.asc
Description: PGP signature

[PATCH] tty fix oops when rmmod 8250

[nixiaoming]

After rmmod 8250.ko
tty_kref_put starts kwork (release_one_tty) to release proc interface
oops when accessing driver->driver_name in proc_tty_unregister_driver

Use jprobe, found driver->driver_name point to 8250.ko
static static struct uart_driver serial8250_reg
.driver_name= serial,

Use name in proc_dir_entry instead of driver->driver_name to fix oops

test on linux 4.1.12:

BUG: unable to handle kernel paging request at a01979de
IP: [] strchr+0x0/0x30
PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
Oops:  [#1] PREEMPT SMP
Modules linked in: ... ...  [last unloaded: 8250]
CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G   O4.1.12 #1
Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 
12/21/2015
Workqueue: events release_one_tty
task: 88085b684960 ti: 880852884000 task.ti: 880852884000
RIP: 0010:[]  [] strchr+0x0/0x30
RSP: 0018:880852887c90  EFLAGS: 00010282
RAX: 81a5eca0 RBX: a01979de RCX: 0004
RDX: 880852887d10 RSI: 002f RDI: a01979de
RBP: 880852887cd8 R08:  R09: 88085f5d94d0
R10: 0195 R11:  R12: a01979de
R13: 880852887d00 R14: a01979de R15: 88085f02e840
FS:  () GS:88085f5c() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: a01979de CR3: 01a0c000 CR4: 001406e0
Stack:
 812349b1 880852887cb8 880852887d10 88085f5cd6c2
 880852800a80 a01979de 880852800a84 0010
 88085bb28bd8 880852887d38 812354f0 880852887d08
Call Trace:
 [] ? __xlate_proc_name+0x71/0xd0
 [] remove_proc_entry+0x40/0x180
 [] ? _raw_spin_lock_irqsave+0x41/0x60
 [] ? destruct_tty_driver+0x60/0xe0
 [] proc_tty_unregister_driver+0x28/0x40
 [] destruct_tty_driver+0x88/0xe0
 [] tty_driver_kref_put+0x1d/0x20
 [] release_one_tty+0x5a/0xd0
 [] process_one_work+0x139/0x420
 [] worker_thread+0x121/0x450
 [] ? process_scheduled_works+0x40/0x40
 [] kthread+0xec/0x110
 [] ? tg_rt_schedulable+0x210/0x220
 [] ? kthread_freezable_should_stop+0x80/0x80
 [] ret_from_fork+0x42/0x70
 [] ? kthread_freezable_should_stop+0x80/0x80

Signed-off-by: nixiaoming 
---
 fs/proc/proc_tty.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/proc/proc_tty.c b/fs/proc/proc_tty.c
index 901bd06..20e2c18 100644
--- a/fs/proc/proc_tty.c
+++ b/fs/proc/proc_tty.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "internal.h"
 
 /*
  * The /proc/tty directory inodes...
@@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct tty_driver *driver)
if (!ent)
return;

-   remove_proc_entry(driver->driver_name, proc_tty_driver);
+   remove_proc_entry(ent->name, proc_tty_driver);

driver->proc_entry = NULL;
 }
-- 
2.11.0.1

[PATCH] tty fix oops when rmmod 8250

[nixiaoming]

After rmmod 8250.ko
tty_kref_put starts kwork (release_one_tty) to release proc interface
oops when accessing driver->driver_name in proc_tty_unregister_driver

Use jprobe, found driver->driver_name point to 8250.ko
static static struct uart_driver serial8250_reg
.driver_name= serial,

Use name in proc_dir_entry instead of driver->driver_name to fix oops

test on linux 4.1.12:

BUG: unable to handle kernel paging request at a01979de
IP: [] strchr+0x0/0x30
PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
Oops:  [#1] PREEMPT SMP
Modules linked in: ... ...  [last unloaded: 8250]
CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G   O4.1.12 #1
Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 
12/21/2015
Workqueue: events release_one_tty
task: 88085b684960 ti: 880852884000 task.ti: 880852884000
RIP: 0010:[]  [] strchr+0x0/0x30
RSP: 0018:880852887c90  EFLAGS: 00010282
RAX: 81a5eca0 RBX: a01979de RCX: 0004
RDX: 880852887d10 RSI: 002f RDI: a01979de
RBP: 880852887cd8 R08:  R09: 88085f5d94d0
R10: 0195 R11:  R12: a01979de
R13: 880852887d00 R14: a01979de R15: 88085f02e840
FS:  () GS:88085f5c() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: a01979de CR3: 01a0c000 CR4: 001406e0
Stack:
 812349b1 880852887cb8 880852887d10 88085f5cd6c2
 880852800a80 a01979de 880852800a84 0010
 88085bb28bd8 880852887d38 812354f0 880852887d08
Call Trace:
 [] ? __xlate_proc_name+0x71/0xd0
 [] remove_proc_entry+0x40/0x180
 [] ? _raw_spin_lock_irqsave+0x41/0x60
 [] ? destruct_tty_driver+0x60/0xe0
 [] proc_tty_unregister_driver+0x28/0x40
 [] destruct_tty_driver+0x88/0xe0
 [] tty_driver_kref_put+0x1d/0x20
 [] release_one_tty+0x5a/0xd0
 [] process_one_work+0x139/0x420
 [] worker_thread+0x121/0x450
 [] ? process_scheduled_works+0x40/0x40
 [] kthread+0xec/0x110
 [] ? tg_rt_schedulable+0x210/0x220
 [] ? kthread_freezable_should_stop+0x80/0x80
 [] ret_from_fork+0x42/0x70
 [] ? kthread_freezable_should_stop+0x80/0x80

Signed-off-by: nixiaoming 
---
 fs/proc/proc_tty.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/proc/proc_tty.c b/fs/proc/proc_tty.c
index 901bd06..20e2c18 100644
--- a/fs/proc/proc_tty.c
+++ b/fs/proc/proc_tty.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "internal.h"
 
 /*
  * The /proc/tty directory inodes...
@@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct tty_driver *driver)
if (!ent)
return;

-   remove_proc_entry(driver->driver_name, proc_tty_driver);
+   remove_proc_entry(ent->name, proc_tty_driver);

driver->proc_entry = NULL;
 }
-- 
2.11.0.1

Re: [PATCH] mtd: spi-nor: stm32-quadspi: Fix uninitialized error return code

[Ludovic BARRE]

On 07/17/2017 12:22 PM, Geert Uytterhoeven wrote:

Hi Ludovic,

On Mon, Jul 17, 2017 at 11:56 AM, Ludovic BARRE  wrote:

Today only write_reg could be call with len=0 (spi-nor.c:
write_enable/disable, set_4byte, erase_chip)

But your remark make sense to prevent: gcc warning and framework evolution
...


-In stm32-quadspi.c transfer data is enabled if tx_data is true (some
actions under this bool)

stm32_qspi_write_reg has already this protection with "!!(buf && len > 0);"

but we could extend this protection

-cmd.tx_data = true;
+cmd.tx_data = !!(len > 0);

In : stm32_qspi_read, stm32_qspi_write, stm32_qspi_read_reg


Ah, I missed the check for !cmd->tx_data at the top of stm32_qspi_tx()


-And to avoid gcc warning: I prefer initialize "ret" in the beginning of
function

-int ret;
+int ret = 0;

I tested this changes, and it's ok for me.

Geert could you resend a new version, or do you prefer that I take care of
it


If you initialized ret at the beginning, you lose the ability to catch newly
introduced similar bugs in the future.
like discuss in thread https://patchwork.kernel.org/patch/9952849/ with 
Arnd and Geert


Cyrille, Marek: could you take geert patch and abandon
https://patchwork.kernel.org/patch/9952849/
thanks

Acked-by: Ludovic Barre 




On 07/15/2017 10:00 AM, Geert Uytterhoeven wrote:


With gcc 4.1.2:

  drivers/mtd/spi-nor/stm32-quadspi.c: In function
‘stm32_qspi_tx_poll’:
  drivers/mtd/spi-nor/stm32-quadspi.c:230: warning: ‘ret’ may be used
uninitialized in this function

Indeed, if stm32_qspi_cmd.len is zero, ret will be uninitialized.
This length is passed from outside the driver using the
spi_nor.{read,write}{,_reg}() callbacks.

Several functions in drivers/mtd/spi-nor/spi-nor.c (e.g. write_enable(),
write_disable(), and erase_chip()) call spi_nor.write_reg() with a zero
length.

Fix this by returning an explicit zero on success.

Fixes: 0d43d7ab277a048c ("mtd: spi-nor: add driver for STM32 quad spi
flash controller")
Signed-off-by: Geert Uytterhoeven 
---
   drivers/mtd/spi-nor/stm32-quadspi.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/stm32-quadspi.c
b/drivers/mtd/spi-nor/stm32-quadspi.c
index 86c0931543c538c3..ad6a3e1844cbe5ec 100644
--- a/drivers/mtd/spi-nor/stm32-quadspi.c
+++ b/drivers/mtd/spi-nor/stm32-quadspi.c
@@ -240,12 +240,12 @@ static int stm32_qspi_tx_poll(struct stm32_qspi
*qspi,

STM32_QSPI_FIFO_TIMEOUT_US);
 if (ret) {
 dev_err(qspi->dev, "fifo timeout (stat:%#x)\n",
sr);
-   break;
+   return ret;
 }
 tx_fifo(buf++, qspi->io_base + QUADSPI_DR);
 }
   - return ret;
+   return 0;
   }
 static int stm32_qspi_tx_mm(struct stm32_qspi *qspi,


Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds

Re: Port the period data column to centos6.7 for perf script

[Arnaldo Carvalho de Melo]

Em Thu, Sep 14, 2017 at 09:21:54PM -0700, Andi Kleen escreveu:
> On Fri, Sep 15, 2017 at 10:24:15AM +0800, 禹舟键 wrote:
> >Hi, all.
> >I want to draw off-cpu flamegraph using perf script on centos6.7(kernel
> >version, 2.6.32-573), and I found perf script lacks the period data 
> > column
> >on that version. I  found two related patches, and modifed
> >builin-script.c in reference to those patches.
> >perf script:Add period data column authorJiri Olsa 2014-08-25 16:45:42
> >+0200 commit535aeaae7de821ba5d43ee2a204ee667ca95aae4
> >perf script: Add period as a default output column
> >commite8564b710c6df2c3aeb56c507c22f4bcfa4c0b2d)
 
> I would just compile the newer perf binary for Centos6 and use that. It should
> work with older kernels too. That's much easier than backporting, and you get
> many more features.

yeah, look at the Dockerfile I use to build it for that OS:

[acme@jouet 6]$ cat Dockerfile 
# docker.io/acmel/linux-perf-tools-build-centos:6
FROM docker.io/centos:6
MAINTAINER Arnaldo Carvalho de Melo 
RUN yum -y update && \
yum -y install make gcc flex bison bc elfutils-libelf-devel elfutils-devel \
   libunwind-devel audit-libs-devel openssl-devel slang-devel \
   gtk2-devel perl-ExtUtils-Embed python-devel binutils-devel \
   systemtap-sdt-devel xz-devel numactl-devel && \
yum -y clean all && \
rm -rf /usr/share/doc /usr/share/gtk-doc /usr/share/man && \
mkdir -m 777 -p /tmp/build/perf /tmp/build/objtool && \
groupadd -r perfbuilder && \
useradd -m -r -g perfbuilder perfbuilder
USER perfbuilder
ENTRYPOINT make -C /git/linux/tools/perf O=/tmp/build/perf && \
   rm -rf /tmp/build/perf/{.[^.]*,*} && \
   make NO_LIBELF=1 -C /git/linux/tools/perf O=/tmp/build/perf && \
   make -C /git/linux/tools/objtool O=/tmp/build/objtool
[acme@jouet 6]$

[PATCH v2] doc: coresight: correct usage for disabling idle states

[Leo Yan]

In the coresight CPU debug document it suggests to use 'echo' command
to set latency request to /dev/cpu_dma_latency so can disable all CPU
idle states, but in fact this doesn't work.

This is because when the command 'echo' exits, it releases the device
node's file descriptor and the kernel release function removes the QoS
constraint; finally when the command 'echo' finished there have no
constraint imposed on cpu_dma_latency.

This patch changes to use 'exec' to access '/dev/cpu_dma_latency', the
command 'exec' can avoid the file descriptor to be closed so we can
keep the constraint on cpu_dma_latency.

This patch also adds the info for reference docs for PM QoS and cpuidle
sysfs.

Cc: Jonathan Corbet 
Cc: Mathieu Poirier 
Cc: Sudeep Holla 
Reported-by: Kim Phillips 
Signed-off-by: Leo Yan 
---
 Documentation/trace/coresight-cpu-debug.txt | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/trace/coresight-cpu-debug.txt 
b/Documentation/trace/coresight-cpu-debug.txt
index b3da1f9..205ff95 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -149,11 +149,15 @@ If you want to limit idle states at boot time, you can 
use "nohlt" or
 
 At the runtime you can disable idle states with below methods:
 
-Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle
-states (if latency = 0uS then disable all idle states):
-# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
-
-Disable specific CPU's specific idle state:
+By using PM QoS interface '/dev/cpu_dma_latency', we can set latency
+constraint to disable all CPUs specific idle states (see
+Documentation/power/pm_qos_interface.txt, section 'From user mode');
+below is one example to set latency constraint to '', it is
+hexadecimal format with microsecond unit:
+# exec 3<> /dev/cpu_dma_latency; echo '' >&3
+
+Disable specific CPU's specific idle state from cpuidle sysfs (see
+Documentation/cpuidle/sysfs.txt):
 # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
 
 
-- 
2.7.4

Re: RFC: Audit Kernel Container IDs

[Richard Guy Briggs]

On 2017-09-14 01:30, Richard Guy Briggs wrote:
> On 2017-09-13 14:33, Carlos O'Donell wrote:
> > On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> > > Containers are a userspace concept.  The kernel knows nothing of them.
> > 
> > I am looking at this RFC from a userspace perspective, particularly from
> > the loader's point of view and the unshare syscall and the semantics that
> > arise from the use of it.
> > 
> > At a high level what you are doing is providing a way to group, without
> > hierarchy, processes and namespaces. The processes can move between
> > container's if they have CAP_CONTAINER_ADMIN and can open and write to
> > a special proc file.

I should clarify: It wasn't intended that a process can see or modify
its own or a peer's special proc container file to be able to set it or
discover its value.  This was only meant for its orchestrator or
delegated agents to do.  This can't be left only to CAP_CONTAINER_ADMIN.
This may require a container to have its own mount namespace if the 
trigger mechanism is a proc file write.  Other methods (additional
namespaces?) may be needed to restrict it for other trigger methods
(syscall?).

> > * With unshare a thread may dissociate part of its execution context and
> >   therefore see a distinct mount namespace. When you say "process" in this
> >   particular RFC do you exclude the fact that a thread might be in a
> >   distinct container from the rest of the threads in the process?
> > 
> > > The Linux audit system needs a way to be able to track the container
> > > provenance of events and actions.  Audit needs the kernel's help to do
> > > this.
> > 
> > * Why does the Linux audit system need to tracker container provenance?
> 
> - ability to filter unwanted, irrelevant or unimportant messages before
>   they fill queue so important messages don't get lost.  This is a
>   certification requirement.
> 
> - ability to make security claims about containers, require tracking of
>   actions within those containers to ensure compliance with established
>   security policies.
> 
> - ability to route messages from events to relevant audit daemon
>   instance or host audit daemon instance or both, as required or
>   determined by user-initiated rules
> 
> >   - How does it help to provide better audit messages?
> > 
> >   - Is it be enough to list the namespace that a process occupies?
> 
> We started with that approach back more than 4 years ago and found it
> helped, but didn't go far enough in terms of quick and inexpensive
> record filtering and left some doubt about provenance of events in the
> case of non-user context events (incoming network packets).
> 
> > * Why does it need the kernel's help?
> > 
> >   - Is there a race condition that is only fixable with kernel support?
> 
> This was a concern, but relatively minor compared with the other benefits.
> 
> >   - Or is it easier with kernel help but not required?
> 
> It is much easier and much less expensive.
> 
> > Providing background on these questions would help clarify the
> > design requirements.
> 
> Here are some references that should help provide some background:
>   https://github.com/linux-audit/audit-kernel/issues/32
>   RFE: add namespace IDs to audit records
> 
>   
> https://github.com/linux-audit/audit-documentation/wiki/SPEC-Virtualization-Manager-Guest-Lifecycle-Events
>   SPEC Virtualization Manager Guest Lifecycle Events
> 
>   https://lwn.net/Articles/699819/
>   Audit, namespaces, and containers
> 
>   https://lwn.net/Articles/723561/
>   Containers as kernel objects
>   (my reply, with references: https://lkml.org/lkml/2017/8/14/15 )
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1045666
>   audit: add namespace IDs to log records
> 
> > > Since the concept of a container is entirely a userspace concept, a
> > > trigger signal from the userspace container orchestration system
> > > initiates this.  This will define a point in time and a set of resources
> > > associated with a particular container with an audit container ID.
> > 
> > Please don't use the word 'signal', I suggest 'register' since you are
> > writing to a filesystem.
> 
> Ok, that's a very reasonable request.  'signal' has a previous meaning.
> 
> > > The trigger is a pseudo filesystem (proc, since PID tree already exists)
> > > write of a u64 representing the container ID to a file representing a
> > > process that will become the first process in a new container.
> > > This might place restrictions on mount namespaces required to define a
> > > container, or at least careful checking of namespaces in the kernel to
> > > verify permissions of the orchestrator so it can't change its own
> > > container ID.
> > > A bind mount of nsfs may be necessary in the container orchestrator's
> > > mntNS.
> > > 
> > > Require a new CAP_CONTAINER_ADMIN to be able to write to the pseudo
> > > filesystem to have this action permitted.  At that time, record the
> > > child co

[PATCH v2] [DVB][FRONTEND] Added a new ioctl for optimizing frontend property set operation

[Satendra Singh Thakur]

Hello  Mr Chehab,
Thanks for the comments.
I have modified dtv_property_process_set and
also added documentation.
Please let me know if any further modifications required.

Signed-off-by: Satendra Singh Thakur 
---
 .../media/uapi/dvb/fe-set-property-short.rst   |  60 +
 Documentation/media/uapi/dvb/frontend_fcalls.rst   |   1 +
 drivers/media/dvb-core/dvb_frontend.c  | 143 +
 include/uapi/linux/dvb/frontend.h  |  24 
 4 files changed, 173 insertions(+), 55 deletions(-)
 create mode 100644 Documentation/media/uapi/dvb/fe-set-property-short.rst

diff --git a/Documentation/media/uapi/dvb/fe-set-property-short.rst 
b/Documentation/media/uapi/dvb/fe-set-property-short.rst
new file mode 100644
index 000..7da1e8d
--- /dev/null
+++ b/Documentation/media/uapi/dvb/fe-set-property-short.rst
@@ -0,0 +1,60 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _FE_SET_PROPERTY_SHORT:
+
+**
+ioctl FE_SET_PROPERTY_SHORT
+**
+
+Name
+
+
+FE_SET_PROPERTY_SHORT  sets one or more frontend properties.
+
+
+Synopsis
+
+
+
+.. c:function:: int ioctl( int fd, FE_SET_PROPERTY_SHORT, struct 
dtv_properties_short *argp )
+:name: FE_SET_PROPERTY_SHORT
+
+
+Arguments
+=
+
+``fd``
+File descriptor returned by :ref:`open() `.
+
+``argp``
+pointer to struct :c:type:`dtv_properties_short`,
+   which is a shorter variant of struct dtv_properties.
+
+
+Description
+===
+
+All DVB frontend devices support the ``FE_SET_PROPERTY_SHORT`` ioctl.
+This ioctl is a shorter variant of ioctl FE_SET_PROPERTY.
+The supported properties and statistics depend on the delivery system
+and on the device:
+
+-  ``FE_SET_PROPERTY_SHORT:``
+
+   -  This ioctl is used to set one or more frontend properties.
+
+   -  This is the basic command to request the frontend to tune into
+  some frequency and to start decoding the digital TV signal.
+
+   -  This call requires read/write access to the device.
+
+   -  At return, the values are updated to reflect the actual parameters
+  used.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/dvb/frontend_fcalls.rst 
b/Documentation/media/uapi/dvb/frontend_fcalls.rst
index b03f9ca..a1246c6 100644
--- a/Documentation/media/uapi/dvb/frontend_fcalls.rst
+++ b/Documentation/media/uapi/dvb/frontend_fcalls.rst
@@ -14,6 +14,7 @@ Frontend Function Calls
 fe-get-info
 fe-read-status
 fe-get-property
+fe-set-property-short
 fe-diseqc-reset-overload
 fe-diseqc-send-master-cmd
 fe-diseqc-recv-slave-reply
diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index e3fff8f..6616474 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -1738,23 +1738,28 @@ static int dvbv3_set_delivery_system(struct 
dvb_frontend *fe)
return emulate_delivery_system(fe, delsys);
 }
 
+/**
+ * dtv_property_process_set
+ * @fe: Pointer to struct dvb_frontend
+ * @file: Pointer to struct file
+ * @cmd: Property name
+ * @data: Property value
+ *
+ * helper function for dvb_frontend_ioctl_properties,
+ * which can be used to set a single dtv property
+ * It assigns property value to corresponding member of
+ * property-cache structure
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
 static int dtv_property_process_set(struct dvb_frontend *fe,
-   struct dtv_property *tvp,
-   struct file *file)
+   struct file *file,
+   u32 cmd, u32 data)
 {
int r = 0;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 
-   /* Allow the frontend to validate incoming properties */
-   if (fe->ops.set_property) {
-   r = fe->ops.set_property(fe, tvp);
-   if (r < 0)
-   return r;
-   }
-
-   dtv_property_dump(fe, true, tvp);
-
-   switch(tvp->cmd) {
+   switch (cmd) {
case DTV_CLEAR:
/*
 * Reset a cache of data specific to the frontend here. This 
does
@@ -1767,140 +1772,140 @@ static int dtv_property_process_set(struct 
dvb_frontend *fe,
 * tunerequest so we can pass validation in the FE_SET_FRONTEND
 * ioctl.
 */
-   c->state = tvp->cmd;
+   c->state = cmd;
dev_dbg(fe->dvb->device, "%s: Finalised property cache\n",
__func__);
 
r = dtv_set_frontend(fe);
break;
case DTV_FREQUENCY:
-   c->frequency = tvp->u.data;
+   c->freq

[4.14-rc0 regression] Re: x60: warnings on boot and resume, arch/x86/mm/tlb.c:257 initialize_ ... was Re: [PATCH 0/2] Fix resume failure due to PCID

[Pavel Machek]

Hi!

> > Ok, seems this is still not completely right, I'm now getting WARN_ON
> > during boot and on every resume... but machine works.
> > 
> > 4.14-rc0, 32-bit.
> 
> Which SHA1, just to make sure? (Please enable CONFIG_LOCALVERSION_AUTO=y.)
> 
> > [0.004000] Initializing CPU#1
> > [0.004000] [ cut here ]
> > [0.004000] WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:257 
> > initialize_tlbstate_and_flush+0x27/0xcf
> > [0.004000] Modules linked in:
> > [0.004000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0+ #429
> > [0.004000] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 
> > 03/31/2011
> > [0.004000] task: f5ca2080 task.stack: f5cc4000
> > [0.004000] EIP: initialize_tlbstate_and_flush+0x27/0xcf
> > [0.004000] EFLAGS: 00210087 CPU: 1
> > [0.004000] EAX:  EBX: c506d540 ECX: 051b2000 EDX: 
> > [0.004000] ESI: 0503f000 EDI: c51b2000 EBP: f5cc5f54 ESP: f5cc5f48
> > [0.004000]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > [0.004000] CR0: 80050033 CR2:  CR3: 0503f000 CR4: 06b0
> > [0.004000] Call Trace:
> > [0.004000]  cpu_init+0xdc/0x2f0
> > [0.004000]  start_secondary+0x34/0x1c6
> > [0.004000]  startup_32_smp+0x164/0x166
> > [0.004000]  ? startup_32_smp+0x164/0x166
> 
> Could you please try the debug patch below, so that we get a bit
> more info?

Let me pull latest...

711aab1dbb324d321e3d84368a435a78908c7bce

(Strange. Not authored by Linus and old?)

Applying patch is easy enough.

> @@ -254,7 +254,8 @@ void initialize_tlbstate_and_flush(void)
>   unsigned long cr3 = __read_cr3();
>  
>   /* Assert that CR3 already references the right mm. */
> - WARN_ON((cr3 & CR3_ADDR_MASK) != __pa(mm->pgd));
> + if (WARN_ON((cr3 & CR3_ADDR_MASK) != __pa(mm->pgd)))
> + printk("# CR3: %016lx, __pa(mm->pgd): %016lx\n", cr3, 
> __pa(mm->pgd));
>  
>   /*
>* Assert that CR4.PCIDE is set if needed.  (CR4.PCIDE initialization

But result is still similar, this time with more debug information.

Best regards,
Pavel

[0.00] Linux version 4.13.0+ (pavel@duo) (gcc version 4.9.2 (Debian 
4.9.2-10)) #431 SMP Fri Sep 15 12:05:10 CEST 2017
[0.00] Disabled fast string operations
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbf6c] usable
[0.00] BIOS-e820: [mem 0xbf6d-0xbf6defff] ACPI data
[0.00] BIOS-e820: [mem 0xbf6df000-0xbf6f] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf70-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff80-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.4 present.
[0.00] DMI: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xbf6d0 max_arch_pfn = 0x100
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-DBFFF uncachable
[0.00]   DC000-D write-back
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0BF70 mask 0 uncachable
[0.00]   3 base 0BF80 mask FFF80 uncachable
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: PAT not supported by CPU.
[0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.00] initial memory mapped: [mem 0x-0x05bf]
[0.00] Base memory trampoline at [c009b000]

Re: [PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency'

[Leo Yan]

Hi Kim,

On Wed, Aug 23, 2017 at 11:05:28AM -0500, Kim Phillips wrote:
> On Wed, 23 Aug 2017 15:23:18 +0800
> Leo Yan  wrote:
> 
> > Cc: Kim Phillips 
> > Reported-by: Kim Phillips 
> 
> Thanks; typically only the latter is needed.
> 
> >  Set latency request to /dev/cpu_dma_latency to disable all CPUs specific 
> > idle
> > -states (if latency = 0uS then disable all idle states):
> > -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> > +states (if latency = 0uS then CPU Idle governor selects idle state0, so 
> > this
> > +means 'WFI' is still enabled but other deeper states have be disabled, this
> > +can avoid power off CPUs):
> > +# exec 3<> /dev/cpu_dma_latency; echo "what_ever_latency_you_need_in_uS" 
> > >&3
> 
> not a fan of the "what_ever_latency_you_need_in_uS" (including and
> especially the quotes which can create ambiguity in the user's mind):
> just put a cut-n-pasteable example, clarifying the typically-default
> value you chose, and its unit, in the text.
> 
> More to the point, how did you test this?  Are you sure that that the
> value being echoed isn't being interpreted as a binary number?

I checked for this with manually adding log in kernel function, if we
use 'echo' command and input string with 4 chars length then the
parameter cannot be parsed correctly by copy_from_user(); if input
string with other length, the string will be parsed with hexadecimal
format.

> kernel/power/qos.c:pm_qos_power_read() looks to be looking for a 32-bit
> binary integer, but I'm not sure if that's where it gets read.
> 
> Certainly, this 2013 article uses a C example to write a binary integer:
> 
> https://access.redhat.com/articles/65410
> 
> Please double-check, thanks,

Thanks for the reminding. C code with 's32' type can pass correct
value into kernel.

Have sent new version patch, please help review.

Thanks,
Leo Yan

[PATCH v3 03/10] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc

[AKASHI Takahiro]

arch_kexec_kernel_*() and arch_kimage_file_post_load_cleanup can now be
duplicated among some architectures, so let's factor them out.

Signed-off-by: AKASHI Takahiro 
Cc: Dave Young 
Cc: Vivek Goyal 
Cc: Baoquan He 
Cc: Michael Ellerman 
Cc: Thiago Jung Bauermann 
---
 arch/powerpc/include/asm/kexec.h|  4 ++
 arch/powerpc/kernel/machine_kexec_file_64.c | 36 ++
 arch/x86/kernel/machine_kexec_64.c  | 59 +
 include/linux/kexec.h   | 26 ++---
 kernel/kexec_file.c | 52 +++--
 5 files changed, 70 insertions(+), 107 deletions(-)

diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 25668bc8cb2a..50810d24e38f 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -94,6 +94,10 @@ static inline bool kdump_in_progress(void)
 #ifdef CONFIG_KEXEC_FILE
 extern struct kexec_file_ops kexec_elf64_ops;
 
+#define arch_kexec_kernel_image_probe arch_kexec_kernel_image_probe
+int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
+ unsigned long buf_len);
+
 #ifdef CONFIG_IMA_KEXEC
 #define ARCH_HAS_KIMAGE_ARCH
 
diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c 
b/arch/powerpc/kernel/machine_kexec_file_64.c
index 992c0d258e5d..5b7c4a3fbb50 100644
--- a/arch/powerpc/kernel/machine_kexec_file_64.c
+++ b/arch/powerpc/kernel/machine_kexec_file_64.c
@@ -31,8 +31,9 @@
 
 #define SLAVE_CODE_SIZE256
 
-static struct kexec_file_ops *kexec_file_loaders[] = {
+struct kexec_file_ops *kexec_file_loaders[] = {
&kexec_elf64_ops,
+   NULL
 };
 
 int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
@@ -45,38 +46,7 @@ int arch_kexec_kernel_image_probe(struct kimage *image, void 
*buf,
if (image->type == KEXEC_TYPE_CRASH)
return -ENOTSUPP;
 
-   for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
-   fops = kexec_file_loaders[i];
-   if (!fops || !fops->probe)
-   continue;
-
-   ret = fops->probe(buf, buf_len);
-   if (!ret) {
-   image->fops = fops;
-   return ret;
-   }
-   }
-
-   return ret;
-}
-
-void *arch_kexec_kernel_image_load(struct kimage *image)
-{
-   if (!image->fops || !image->fops->load)
-   return ERR_PTR(-ENOEXEC);
-
-   return image->fops->load(image, image->kernel_buf,
-image->kernel_buf_len, image->initrd_buf,
-image->initrd_buf_len, image->cmdline_buf,
-image->cmdline_buf_len);
-}
-
-int arch_kimage_file_post_load_cleanup(struct kimage *image)
-{
-   if (!image->fops || !image->fops->cleanup)
-   return 0;
-
-   return image->fops->cleanup(image->image_loader_data);
+   return kexec_kernel_image_probe(image, buf, buf_len);
 }
 
 /**
diff --git a/arch/x86/kernel/machine_kexec_64.c 
b/arch/x86/kernel/machine_kexec_64.c
index cb0a30473c23..f4df8315d001 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -30,8 +30,9 @@
 #include 
 
 #ifdef CONFIG_KEXEC_FILE
-static struct kexec_file_ops *kexec_file_loaders[] = {
+struct kexec_file_ops *kexec_file_loaders[] = {
&kexec_bzImage64_ops,
+   NULL
 };
 #endif
 
@@ -361,62 +362,6 @@ void arch_crash_save_vmcoreinfo(void)
 /* arch-dependent functionality related to kexec file-based syscall */
 
 #ifdef CONFIG_KEXEC_FILE
-int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
- unsigned long buf_len)
-{
-   int i, ret = -ENOEXEC;
-   struct kexec_file_ops *fops;
-
-   for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
-   fops = kexec_file_loaders[i];
-   if (!fops || !fops->probe)
-   continue;
-
-   ret = fops->probe(buf, buf_len);
-   if (!ret) {
-   image->fops = fops;
-   return ret;
-   }
-   }
-
-   return ret;
-}
-
-void *arch_kexec_kernel_image_load(struct kimage *image)
-{
-   vfree(image->arch.elf_headers);
-   image->arch.elf_headers = NULL;
-
-   if (!image->fops || !image->fops->load)
-   return ERR_PTR(-ENOEXEC);
-
-   return image->fops->load(image, image->kernel_buf,
-image->kernel_buf_len, image->initrd_buf,
-image->initrd_buf_len, image->cmdline_buf,
-image->cmdline_buf_len);
-}
-
-int arch_kimage_file_post_load_cleanup(struct kimage *image)
-{
-   if (!image->fops || !image->fops->cleanup)
-   return 0;
-
-   return image->fops->cleanup(image->image_loader_data);
-}
-
-#ifdef CONFIG_KEXEC_V

[PATCH v3 05/10] asm-generic: add kexec_file_load system call to unistd.h

[AKASHI Takahiro]

The initial user of this system call number is arm64.

Signed-off-by: AKASHI Takahiro 
Acked-by: Arnd Bergmann 
---
 include/uapi/asm-generic/unistd.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/asm-generic/unistd.h 
b/include/uapi/asm-generic/unistd.h
index 061185a5eb51..086697fe3917 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -731,9 +731,11 @@ __SYSCALL(__NR_pkey_alloc,sys_pkey_alloc)
 __SYSCALL(__NR_pkey_free, sys_pkey_free)
 #define __NR_statx 291
 __SYSCALL(__NR_statx, sys_statx)
+#define __NR_kexec_file_load 292
+__SYSCALL(__NR_kexec_file_load, sys_kexec_file_load)
 
 #undef __NR_syscalls
-#define __NR_syscalls 292
+#define __NR_syscalls 293
 
 /*
  * All syscalls below here should go away really,
-- 
2.14.1

[PATCH v3 04/10] kexec_file: factor out crashdump elf header function from x86

[AKASHI Takahiro]

prepare_elf_headers() can also be useful for other architectures,
including arm64. So let it factored out.

Signed-off-by: AKASHI Takahiro 
Cc: Dave Young 
Cc: Vivek Goyal 
Cc: Baoquan He 
---
 arch/x86/kernel/crash.c | 324 
 include/linux/kexec.h   |  17 +++
 kernel/kexec_file.c | 308 +
 kernel/kexec_internal.h |  20 +++
 4 files changed, 345 insertions(+), 324 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 44404e2307bb..3c6b880f6dbf 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -41,34 +40,6 @@
 /* Alignment required for elf header segment */
 #define ELF_CORE_HEADER_ALIGN   4096
 
-/* This primarily represents number of split ranges due to exclusion */
-#define CRASH_MAX_RANGES   16
-
-struct crash_mem_range {
-   u64 start, end;
-};
-
-struct crash_mem {
-   unsigned int nr_ranges;
-   struct crash_mem_range ranges[CRASH_MAX_RANGES];
-};
-
-/* Misc data about ram ranges needed to prepare elf headers */
-struct crash_elf_data {
-   struct kimage *image;
-   /*
-* Total number of ram ranges we have after various adjustments for
-* crash reserved region, etc.
-*/
-   unsigned int max_nr_ranges;
-
-   /* Pointer to elf header */
-   void *ehdr;
-   /* Pointer to next phdr */
-   void *bufp;
-   struct crash_mem mem;
-};
-
 /* Used while preparing memory map entries for second kernel */
 struct crash_memmap_data {
struct boot_params *params;
@@ -209,301 +180,6 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 }
 
 #ifdef CONFIG_KEXEC_FILE
-static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
-{
-   unsigned int *nr_ranges = arg;
-
-   (*nr_ranges)++;
-   return 0;
-}
-
-
-/* Gather all the required information to prepare elf headers for ram regions 
*/
-static void fill_up_crash_elf_data(struct crash_elf_data *ced,
-  struct kimage *image)
-{
-   unsigned int nr_ranges = 0;
-
-   ced->image = image;
-
-   walk_system_ram_res(0, -1, &nr_ranges,
-   get_nr_ram_ranges_callback);
-
-   ced->max_nr_ranges = nr_ranges;
-
-   /* Exclusion of crash region could split memory ranges */
-   ced->max_nr_ranges++;
-
-   /* If crashk_low_res is not 0, another range split possible */
-   if (crashk_low_res.end)
-   ced->max_nr_ranges++;
-}
-
-static int exclude_mem_range(struct crash_mem *mem,
-   unsigned long long mstart, unsigned long long mend)
-{
-   int i, j;
-   unsigned long long start, end;
-   struct crash_mem_range temp_range = {0, 0};
-
-   for (i = 0; i < mem->nr_ranges; i++) {
-   start = mem->ranges[i].start;
-   end = mem->ranges[i].end;
-
-   if (mstart > end || mend < start)
-   continue;
-
-   /* Truncate any area outside of range */
-   if (mstart < start)
-   mstart = start;
-   if (mend > end)
-   mend = end;
-
-   /* Found completely overlapping range */
-   if (mstart == start && mend == end) {
-   mem->ranges[i].start = 0;
-   mem->ranges[i].end = 0;
-   if (i < mem->nr_ranges - 1) {
-   /* Shift rest of the ranges to left */
-   for (j = i; j < mem->nr_ranges - 1; j++) {
-   mem->ranges[j].start =
-   mem->ranges[j+1].start;
-   mem->ranges[j].end =
-   mem->ranges[j+1].end;
-   }
-   }
-   mem->nr_ranges--;
-   return 0;
-   }
-
-   if (mstart > start && mend < end) {
-   /* Split original range */
-   mem->ranges[i].end = mstart - 1;
-   temp_range.start = mend + 1;
-   temp_range.end = end;
-   } else if (mstart != start)
-   mem->ranges[i].end = mstart - 1;
-   else
-   mem->ranges[i].start = mend + 1;
-   break;
-   }
-
-   /* If a split happend, add the split to array */
-   if (!temp_range.end)
-   return 0;
-
-   /* Split happened */
-   if (i == CRASH_MAX_RANGES - 1) {
-   pr_err("Too many crash ranges after split\n");
-   return -ENOMEM;
-   }
-
-   /* Location where new range should go */
-   j = i + 1;
-   if (j < mem->nr_ranges) {
-

[PATCH v3 00/10] arm64: kexec: add kexec_file_load() support

[AKASHI Takahiro]

This is the third round of implementing kexec_file_load() support
on arm64.[1]
Most of the code is based on kexec-tools (along with some kernel code
from x86, which also came from kexec-tools).


This patch series enables us to
  * load the kernel, Image, with kexec_file_load system call, and
  * optionally verify its signature at load time for trusted boot.

To load the kernel via kexec_file_load system call, a small change
is also needed to kexec-tools. See [2]. This enables '-s' option.

As we discussed a long time ago, users may not be allowed to specify
device-tree file of the 2nd kernel explicitly with kexec-tools, hence
re-using the blob of the first kernel.

Regarding a signing method, we conform with x86 (or rather Microsoft?)
style of signing since the binary can also be seen as in PE format
(assuming that CONFIG_EFI is enabled).

Powerpc is also going to support extended-file-attribute-based
verification[3] with vmlinux, but arm64 doesn't for now partly
because we don't have TPM-based IMA at this moment.

Accordingly, we can use the existing command, sbsign, to sign the kernel.

$ sbsign --key ${KEY} --cert ${CERT} Image

Please note that it is totally up to the system what key/certificate is
used for signing, but one of easy ways to *try* this feature is to turn on
CONFIG_MODULE_SIG so that we can reuse certs/signing_key.pem as a signing
key, KEY and CERT above, for kernel.
(This also enables CONFIG_CRYPTO_SHA1 by default.)


Some concerns(or future works):
* Even if the kernel is configured with CONFIG_RANDOMIZE_BASE, the 2nd
  kernel won't be placed at a randomized address. We will have to
  add some boot code similar to efi-stub to implement the feature.
* While big-endian kernel can support kernel signing, I'm not sure that
  Image can be recognized as in PE format because x86 standard only
  defines little-endian-based format.
* IMA(and extended file attribute)-based kexec
* vmlinux support

  [1] http://git.linaro.org/people/takahiro.akashi/linux-aarch64.git
branch:arm64/kexec_file
  [2] http://git.linaro.org/people/takahiro.akashi/kexec-tools.git
branch:arm64/kexec_file
  [3] http://lkml.iu.edu//hypermail/linux/kernel/1707.0/03669.html


Changes in v3 (Sep 15, 2017)
* fix kbuild test error
* factor out arch_kexec_kernel_*() & arch_kimage_file_post_load_cleanup()
* remove CONFIG_CRASH_CORE guard from kexec_file.c
* add vmapped kernel region to vmcore for gdb backtracing
  (see prepare_elf64_headers())
* merge asm/kexec_file.h into asm/kexec.h
* and some cleanups

Changes in v2 (Sep 8, 2017)
* move core-header-related functions from crash_core.c to kexec_file.c
* drop hash-check code from purgatory
* modify purgatory asm to remove arch_kexec_apply_relocations_add()
* drop older kernel support
* drop vmlinux support (at least, for this series)

Patch #1 to #5 are all preparatory patches on generic side.
Patch #6 is purgatory code.
Patch #7 to #9 are common for enabling kexec_file_load.
Patch #10 is for 'Image' support.

AKASHI Takahiro (10):
  include: pe.h: remove message[] from mz header definition
  resource: add walk_system_ram_res_rev()
  kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc
  kexec_file: factor out crashdump elf header function from x86
  asm-generic: add kexec_file_load system call to unistd.h
  arm64: kexec_file: create purgatory
  arm64: kexec_file: load initrd, device-tree and purgatory segments
  arm64: kexec_file: set up for crash dump adding elf core header
  arm64: enable KEXEC_FILE config
  arm64: kexec_file: add Image format support

 arch/arm64/Kconfig  |  29 +++
 arch/arm64/Makefile |   1 +
 arch/arm64/include/asm/kexec.h  |  93 +++
 arch/arm64/kernel/Makefile  |   4 +-
 arch/arm64/kernel/kexec_image.c | 105 
 arch/arm64/kernel/machine_kexec_file.c  | 365 
 arch/arm64/purgatory/Makefile   |  24 ++
 arch/arm64/purgatory/entry.S|  55 +
 arch/powerpc/include/asm/kexec.h|   4 +
 arch/powerpc/kernel/machine_kexec_file_64.c |  36 +--
 arch/x86/kernel/crash.c | 324 
 arch/x86/kernel/machine_kexec_64.c  |  59 +
 include/linux/ioport.h  |   3 +
 include/linux/kexec.h   |  43 +++-
 include/linux/pe.h  |   2 +-
 include/uapi/asm-generic/unistd.h   |   4 +-
 kernel/kexec_file.c | 360 ++-
 kernel/kexec_internal.h |  20 ++
 kernel/resource.c   |  59 +
 19 files changed, 1156 insertions(+), 434 deletions(-)
 create mode 100644 arch/arm64/kernel/kexec_image.c
 create mode 100644 arch/arm64/kernel/machine_kexec_file.c
 create mode 100644 arch/arm64/purgatory/Makefile
 create mode 100644 arch/arm64/purgatory/entry.S

-- 
2.14.1

[PATCH v3 02/10] resource: add walk_system_ram_res_rev()

[AKASHI Takahiro]

This function, being a variant of walk_system_ram_res() introduced in
commit 8c86e70acead ("resource: provide new functions to walk through
resources"), walks through a list of all the resources of System RAM
in reversed order, i.e., from higher to lower.

It will be used in kexec_file implementation on arm64.

Signed-off-by: AKASHI Takahiro 
Cc: Vivek Goyal 
Cc: Andrew Morton 
Cc: Linus Torvalds 
---
 include/linux/ioport.h |  3 +++
 kernel/resource.c  | 59 ++
 2 files changed, 62 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 6230064d7f95..9a212266299f 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -271,6 +271,9 @@ extern int
 walk_system_ram_res(u64 start, u64 end, void *arg,
int (*func)(u64, u64, void *));
 extern int
+walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+   int (*func)(u64, u64, void *));
+extern int
 walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 
end,
void *arg, int (*func)(u64, u64, void *));
 
diff --git a/kernel/resource.c b/kernel/resource.c
index 9b5f04404152..572f2f91ce9c 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 
@@ -469,6 +471,63 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
return ret;
 }
 
+int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+   int (*func)(u64, u64, void *))
+{
+   struct resource res, *rams;
+   u64 orig_end;
+   int count, i;
+   int ret = -1;
+
+   count = 16; /* initial */
+
+   /* create a list */
+   rams = vmalloc(sizeof(struct resource) * count);
+   if (!rams)
+   return ret;
+
+   res.start = start;
+   res.end = end;
+   res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+   orig_end = res.end;
+   i = 0;
+   while ((res.start < res.end) &&
+   (!find_next_iomem_res(&res, IORES_DESC_NONE, true))) {
+   if (i >= count) {
+   /* re-alloc */
+   struct resource *rams_new;
+   int count_new;
+
+   count_new = count + 16;
+   rams_new = vmalloc(sizeof(struct resource) * count_new);
+   if (!rams_new)
+   goto out;
+
+   memcpy(rams_new, rams, count);
+   vfree(rams);
+   rams = rams_new;
+   count = count_new;
+   }
+
+   rams[i].start = res.start;
+   rams[i++].end = res.end;
+
+   res.start = res.end + 1;
+   res.end = orig_end;
+   }
+
+   /* go reverse */
+   for (i--; i >= 0; i--) {
+   ret = (*func)(rams[i].start, rams[i].end, arg);
+   if (ret)
+   break;
+   }
+
+out:
+   vfree(rams);
+   return ret;
+}
+
 #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
 
 /*
-- 
2.14.1

[PATCH v3 06/10] arm64: kexec_file: create purgatory

[AKASHI Takahiro]

This is a basic purgatory, or a kind of glue code between the two kernels,
for arm64.

Since purgatory is assumed to be relocatable (not executable) object by
kexec generic code, arch_kexec_apply_relocations_add() is required in
general. Arm64's purgatory, however, is a simple asm and all the references
can be resolved as local, no re-linking is needed here.

Please note that even if we don't support digest check at purgatory we
need purgatory_sha_regions and purgatory_sha256_digest as they are
referenced by generic kexec code.

Signed-off-by: AKASHI Takahiro 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/Makefile   |  1 +
 arch/arm64/purgatory/Makefile | 24 +++
 arch/arm64/purgatory/entry.S  | 55 +++
 3 files changed, 80 insertions(+)
 create mode 100644 arch/arm64/purgatory/Makefile
 create mode 100644 arch/arm64/purgatory/entry.S

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 9b41f1e3b1a0..429f60728c0a 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -105,6 +105,7 @@ core-$(CONFIG_XEN) += arch/arm64/xen/
 core-$(CONFIG_CRYPTO) += arch/arm64/crypto/
 libs-y := arch/arm64/lib/ $(libs-y)
 core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
+core-$(CONFIG_KEXEC_FILE) += arch/arm64/purgatory/
 
 # Default target when executing plain make
 boot   := arch/arm64/boot
diff --git a/arch/arm64/purgatory/Makefile b/arch/arm64/purgatory/Makefile
new file mode 100644
index ..c2127a2cbd51
--- /dev/null
+++ b/arch/arm64/purgatory/Makefile
@@ -0,0 +1,24 @@
+OBJECT_FILES_NON_STANDARD := y
+
+purgatory-y := entry.o
+
+targets += $(purgatory-y)
+PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
+
+LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined \
+   -nostdlib -z nodefaultlib
+targets += purgatory.ro
+
+$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
+   $(call if_changed,ld)
+
+targets += kexec_purgatory.c
+
+CMD_BIN2C = $(objtree)/scripts/basic/bin2c
+quiet_cmd_bin2c = BIN2C $@
+   cmd_bin2c = $(CMD_BIN2C) kexec_purgatory < $< > $@
+
+$(obj)/kexec_purgatory.c: $(obj)/purgatory.ro FORCE
+   $(call if_changed,bin2c)
+
+obj-${CONFIG_KEXEC_FILE}   += kexec_purgatory.o
diff --git a/arch/arm64/purgatory/entry.S b/arch/arm64/purgatory/entry.S
new file mode 100644
index ..fe6e968076db
--- /dev/null
+++ b/arch/arm64/purgatory/entry.S
@@ -0,0 +1,55 @@
+/*
+ * kexec core purgatory
+ */
+#include 
+#include 
+
+#define SHA256_DIGEST_SIZE 32 /* defined in crypto/sha.h */
+
+.text
+
+ENTRY(purgatory_start)
+   /* Start new image. */
+   ldr x17, __kernel_entry
+   ldr x0, __dtb_addr
+   mov x1, xzr
+   mov x2, xzr
+   mov x3, xzr
+   br  x17
+END(purgatory_start)
+
+/*
+ * data section:
+ * kernel_entry and dtb_addr are global but also labelled as local,
+ * "__xxx:", to avoid unwanted re-linking.
+ *
+ * purgatory_sha_regions and purgatory_sha256_digest are referenced
+ * by kexec generic code and so must exist, but not actually used
+ * here because hash check is not that useful in purgatory.
+ */
+.align 3
+
+.globl kernel_entry
+kernel_entry:
+__kernel_entry:
+   .quad   0
+END(kernel_entry)
+
+.globl dtb_addr
+dtb_addr:
+__dtb_addr:
+   .quad   0
+END(dtb_addr)
+
+.globl purgatory_sha_regions
+purgatory_sha_regions:
+   .rept   KEXEC_SEGMENT_MAX
+   .quad   0
+   .quad   0
+   .endr
+END(purgatory_sha_regions)
+
+.globl purgatory_sha256_digest
+purgatory_sha256_digest:
+.skip   SHA256_DIGEST_SIZE
+END(purgatory_sha256_digest)
-- 
2.14.1

[PATCH v3 01/10] include: pe.h: remove message[] from mz header definition

[AKASHI Takahiro]

message[] field won't be part of the definition of mz header.

This change is crucial for enabling kexec_file_load on arm64 because
arm64's "Image" binary, as in PE format, doesn't have any data for it and
accordingly the following check in pefile_parse_binary() will fail:

chkaddr(cursor, mz->peaddr, sizeof(*pe));

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Ard Biesheuvel 
Cc: David Howells 
Cc: Vivek Goyal 
Cc: Herbert Xu 
Cc: David S. Miller 
---
 include/linux/pe.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/pe.h b/include/linux/pe.h
index 143ce75be5f0..3482b18a48b5 100644
--- a/include/linux/pe.h
+++ b/include/linux/pe.h
@@ -166,7 +166,7 @@ struct mz_hdr {
uint16_t oem_info;  /* oem specific */
uint16_t reserved1[10]; /* reserved */
uint32_t peaddr;/* address of pe header */
-   char message[64];   /* message to print */
+   char message[]; /* message to print */
 };
 
 struct mz_reloc {
-- 
2.14.1

[PATCH v3 10/10] arm64: kexec_file: add Image format support

[AKASHI Takahiro]

The "Image" binary will be loaded at the offset of TEXT_OFFSET from
the start of system memory. TEXT_OFFSET is determined from the header
of the image.

Regarding kernel signature verification, it will be done through
verify_pefile_signature() as arm64's "Image" binary can be seen as
in PE format. This approach is consistent with x86 implementation.

we can sign an image with sbsign command.

Signed-off-by: AKASHI Takahiro 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/Kconfig |   7 +++
 arch/arm64/include/asm/kexec.h |  66 +
 arch/arm64/kernel/Makefile |   1 +
 arch/arm64/kernel/kexec_image.c| 105 +
 arch/arm64/kernel/machine_kexec_file.c |   3 +
 5 files changed, 182 insertions(+)
 create mode 100644 arch/arm64/kernel/kexec_image.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fa7299f08cc6..b7f1a760434a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -769,10 +769,17 @@ config KEXEC_FILE
  In addition to this option, you need to enable a specific type
  of image support.
 
+config KEXEC_FILE_IMAGE_FMT
+   bool "Enable Image support"
+   depends on KEXEC_FILE
+   ---help---
+ Select this option to enable 'Image' kernel loading.
+
 config KEXEC_VERIFY_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on KEXEC_FILE
select SYSTEM_DATA_VERIFICATION
+   select SIGNED_PE_FILE_VERIFICATION if KEXEC_FILE_IMAGE_FMT
---help---
  Select this option to verify a signature with loaded kernel
  image. If configured, any attempt of loading a image without
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index edb702e64a8a..7ec529e11a8b 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -104,6 +104,72 @@ struct kimage_arch {
unsigned long elf_load_addr;
 };
 
+/**
+ * struct arm64_image_header - arm64 kernel image header
+ *
+ * @pe_sig: Optional PE format 'MZ' signature
+ * @branch_code: Instruction to branch to stext
+ * @text_offset: Image load offset, little endian
+ * @image_size: Effective image size, little endian
+ * @flags:
+ * Bit 0: Kernel endianness. 0=little endian, 1=big endian
+ * @reserved: Reserved
+ * @magic: Magic number, "ARM\x64"
+ * @pe_header: Optional offset to a PE format header
+ **/
+
+struct arm64_image_header {
+   u8 pe_sig[2];
+   u8 pad[2];
+   u32 branch_code;
+   u64 text_offset;
+   u64 image_size;
+   u64 flags;
+   u64 reserved[3];
+   u8 magic[4];
+   u32 pe_header;
+};
+
+static const u8 arm64_image_magic[4] = {'A', 'R', 'M', 0x64U};
+static const u8 arm64_image_pe_sig[2] = {'M', 'Z'};
+
+/**
+ * arm64_header_check_magic - Helper to check the arm64 image header.
+ *
+ * Returns non-zero if header is OK.
+ */
+
+static inline int arm64_header_check_magic(const struct arm64_image_header *h)
+{
+   if (!h)
+   return 0;
+
+   if (!h->text_offset)
+   return 0;
+
+   return (h->magic[0] == arm64_image_magic[0]
+   && h->magic[1] == arm64_image_magic[1]
+   && h->magic[2] == arm64_image_magic[2]
+   && h->magic[3] == arm64_image_magic[3]);
+}
+
+/**
+ * arm64_header_check_pe_sig - Helper to check the arm64 image header.
+ *
+ * Returns non-zero if 'MZ' signature is found.
+ */
+
+static inline int arm64_header_check_pe_sig(const struct arm64_image_header *h)
+{
+   if (!h)
+   return 0;
+
+   return (h->pe_sig[0] == arm64_image_pe_sig[0]
+   && h->pe_sig[1] == arm64_image_pe_sig[1]);
+}
+
+extern struct kexec_file_ops kexec_image_ops;
+
 struct kimage;
 
 #define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 5df003d6157c..a1161bab6810 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -51,6 +51,7 @@ arm64-obj-$(CONFIG_HIBERNATION)   += hibernate.o 
hibernate-asm.o
 arm64-obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o
\
   cpu-reset.o
 arm64-obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o
+arm64-obj-$(CONFIG_KEXEC_FILE_IMAGE_FMT)   += kexec_image.o
 arm64-obj-$(CONFIG_ARM64_RELOC_TEST)   += arm64-reloc-test.o
 arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
 arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
new file mode 100644
index ..b19538af2f3d
--- /dev/null
+++ b/arch/arm64/kernel/kexec_image.c
@@ -0,0 +1,105 @@
+/*
+ * Kexec image loader
+
+ * Copyright (C) 2017 Linaro Limited
+ * Author: AKASHI Takahiro 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Ge

Re: [v8 0/4] cgroup-aware OOM killer

[Michal Hocko]

On Thu 14-09-17 09:05:48, Roman Gushchin wrote:
> On Thu, Sep 14, 2017 at 03:40:14PM +0200, Michal Hocko wrote:
> > On Wed 13-09-17 14:56:07, Roman Gushchin wrote:
> > > On Wed, Sep 13, 2017 at 02:29:14PM +0200, Michal Hocko wrote:
> > [...]
> > > > I strongly believe that comparing only leaf memcgs
> > > > is more straightforward and it doesn't lead to unexpected results as
> > > > mentioned before (kill a small memcg which is a part of the larger
> > > > sub-hierarchy).
> > > 
> > > One of two main goals of this patchset is to introduce cgroup-level
> > > fairness: bigger cgroups should be affected more than smaller,
> > > despite the size of tasks inside. I believe the same principle
> > > should be used for cgroups.
> > 
> > Yes bigger cgroups should be preferred but I fail to see why bigger
> > hierarchies should be considered as well if they are not kill-all. And
> > whether non-leaf memcgs should allow kill-all is not entirely clear to
> > me. What would be the usecase?
> 
> We definitely want to support kill-all for non-leaf cgroups.
> A workload can consist of several cgroups and we want to clean up
> the whole thing on OOM.

Could you be more specific about such a workload? E.g. how can be such a
hierarchy handled consistently when its sub-tree gets killed due to
internal memory pressure? Or do you expect that none of the subtree will
have hard limit configured?

> I don't see any reasons to limit this functionality to leaf cgroups
> only.

Well, I wanted to start simple first and extend on top. Memcg v1 is full
of seemingly interesting and very generic concepts which turned out
being a headache long term.

> Hierarchies are memory consumers, we do account their usage,
> we do apply limits and guarantees for the hierarchies. The same is
> with OOM victim selection: we are reclaiming memory from the
> biggest consumer. Kill-all knob only defines the way _how_ we do that:
> by killing one or all processes.

But then you just enforce a structural restriction on your configuration
because
root
/  \
   AD
  /\   
 B  C

is a different thing than
root
/ | \
   B  C  D

And consider that the sole purpose of A might be a control over
a non-memory resource (e.g. a cpu share distribution). Why should we
discriminate B and C in such a case?

> Just for example, we might want to take memory.low into account at
> some point: prefer cgroups which are above their guarantees, avoid
> killing those who fit. It would be hard if we're comparing cgroups
> from different hierarchies.

This can be reflected in the memcg oom score calculation I believe. We
already do something similar during the reclaim.

> The same will be with introducing oom_priorities, which is much more
> required functionality.

More on that below.

> > Consider that it might be not your choice (as a user) how deep is your
> > leaf memcg. I can already see how people complain that their memcg has
> > been killed just because it was one level deeper in the hierarchy...
> 
> The kill-all functionality is enforced by parent, and it seems to be
> following the overall memcg design. The parent cgroup enforces memory
> limit, memory low limit, etc.

And the same is true for the memcg oom killer. It enforces the selection
to the out-of-memory subtree. We are trying to be proportional on the
size of the _reclaimable_ memory in that scope. Same way as with the
LRU reclaim. We do not prefer larger hierarchies over smaller. We just
iterate over those that have pages on LRUs (leaf memcgs with v2) and
scan/reclaim proportionally to their size. Why should the oom killer
decision be any different in that regards?

> I don't know why OOM control should be different.

I am not arguing that kill-all functionality on non-leaf is wrong. I
just haven't heard the usecase for it yet. I am also not opposed to
consider the cumulative size of non-leaf memcg if it is kill-all as the
cumulative size will be reclaimed then. But I fail to see why we should
prefer larger hierarchies when the resulting memcg victim is much
smaller in the end.

> > I would really start simple and only allow kill-all on leaf memcgs and
> > only compare leaf memcgs & root. If we ever need to kill whole
> > hierarchies then allow kill-all on intermediate memcgs as well and then
> > consider cumulative consumptions only on those that have kill-all
> > enabled.
> 
> This sounds hacky to me: the whole thing is depending on cgroup v2 and
> is additionally explicitly opt-in.
> 
> Why do we need to introduce such incomplete functionality first,
> and then suffer trying to extend it and provide backward compatibility?

Why would a backward compatibility be a problem? kill-all on non-leaf
memcgs should be seamless. We would simply allow setting the knob. Adding
a priority shouldn't be a problem either. A new knob would be added. Any
memcg with a non-zero priority would be considered during selection for
example (cumulative size would be considered as a ti

[PATCH v3 09/10] arm64: enable KEXEC_FILE config

[AKASHI Takahiro]

Modify arm64/Kconfig and Makefile to enable kexec_file_load support.

Signed-off-by: AKASHI Takahiro 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/Kconfig | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dfd908630631..fa7299f08cc6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -756,6 +756,28 @@ config KEXEC
  but it is independent of the system firmware.   And like a reboot
  you can start any kernel with it, not just Linux.
 
+config KEXEC_FILE
+   bool "kexec file based system call"
+   select KEXEC_CORE
+   select BUILD_BIN2C
+   ---help---
+ This is new version of kexec system call. This system call is
+ file based and takes file descriptors as system call argument
+ for kernel and initramfs as opposed to list of segments as
+ accepted by previous system call.
+
+ In addition to this option, you need to enable a specific type
+ of image support.
+
+config KEXEC_VERIFY_SIG
+   bool "Verify kernel signature during kexec_file_load() syscall"
+   depends on KEXEC_FILE
+   select SYSTEM_DATA_VERIFICATION
+   ---help---
+ Select this option to verify a signature with loaded kernel
+ image. If configured, any attempt of loading a image without
+ valid signature will fail.
+
 config CRASH_DUMP
bool "Build kdump crash kernel"
help
-- 
2.14.1

[PATCH v3 08/10] arm64: kexec_file: set up for crash dump adding elf core header

[AKASHI Takahiro]

load_crashdump_segments() creates and loads a memory segment of elf core
header for crash dump.

"linux,usable-memory-range" and "linux,elfcorehdr" will add to the 2nd
kernel's device-tree blob. The logic of this cod is also from kexec-tools.

Signed-off-by: AKASHI Takahiro 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/include/asm/kexec.h |   5 ++
 arch/arm64/kernel/machine_kexec_file.c | 149 +
 kernel/kexec_file.c|   2 +-
 3 files changed, 155 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 2fadd3cbf3af..edb702e64a8a 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -98,6 +98,10 @@ static inline void crash_post_resume(void) {}
 
 struct kimage_arch {
void *dtb_buf;
+   /* Core ELF header buffer */
+   void *elf_headers;
+   unsigned long elf_headers_sz;
+   unsigned long elf_load_addr;
 };
 
 struct kimage;
@@ -113,6 +117,7 @@ extern int load_other_segments(struct kimage *image,
unsigned long kernel_load_addr,
char *initrd, unsigned long initrd_len,
char *cmdline, unsigned long cmdline_len);
+extern int load_crashdump_segments(struct kimage *image);
 #endif
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/machine_kexec_file.c 
b/arch/arm64/kernel/machine_kexec_file.c
index 09be2674c2ab..e4671610fb12 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -32,6 +32,10 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
vfree(image->arch.dtb_buf);
image->arch.dtb_buf = NULL;
 
+   vfree(image->arch.elf_headers);
+   image->arch.elf_headers = NULL;
+   image->arch.elf_headers_sz = 0;
+
return kexec_kernel_post_load_cleanup(image);
 }
 
@@ -48,6 +52,77 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf, int 
(*func)(u64, u64, void *))
return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
 }
 
+static int __init arch_kexec_file_init(void)
+{
+   /* Those values are used later on loading the kernel */
+   __dt_root_addr_cells = dt_root_addr_cells;
+   __dt_root_size_cells = dt_root_size_cells;
+
+   return 0;
+}
+late_initcall(arch_kexec_file_init);
+
+#define FDT_ALIGN(x, a)(((x) + (a) - 1) & ~((a) - 1))
+#define FDT_TAGALIGN(x)(FDT_ALIGN((x), FDT_TAGSIZE))
+
+static int fdt_prop_len(const char *prop_name, int len)
+{
+   return (strlen(prop_name) + 1) +
+   sizeof(struct fdt_property) +
+   FDT_TAGALIGN(len);
+}
+
+static bool cells_size_fitted(unsigned long base, unsigned long size)
+{
+   /* if *_cells >= 2, cells can hold 64-bit values anyway */
+   if ((__dt_root_addr_cells == 1) && (base >= (1ULL << 32)))
+   return false;
+
+   if ((__dt_root_size_cells == 1) && (size >= (1ULL << 32)))
+   return false;
+
+   return true;
+}
+
+static void fill_property(void *buf, u64 val64, int cells)
+{
+   u32 val32;
+   int i;
+
+   if (cells == 1) {
+   val32 = cpu_to_fdt32((u32)val64);
+   memcpy(buf, &val32, sizeof(val32));
+   } else {
+   for (i = 0; i < (cells * sizeof(u32) - sizeof(u64)); i++)
+   *(char *)buf++ = 0;
+
+   val64 = cpu_to_fdt64(val64);
+   memcpy(buf, &val64, sizeof(val64));
+   }
+}
+
+static int fdt_setprop_range(void *fdt, int nodeoffset, const char *name,
+   unsigned long addr, unsigned long size)
+{
+   u64 range[2];
+   void *prop;
+   size_t buf_size;
+   int result;
+
+   prop = range;
+   buf_size = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
+
+   fill_property(prop, addr, __dt_root_addr_cells);
+   prop += __dt_root_addr_cells * sizeof(u32);
+
+   fill_property(prop, size, __dt_root_size_cells);
+   prop += __dt_root_size_cells * sizeof(u32);
+
+   result = fdt_setprop(fdt, nodeoffset, name, range, buf_size);
+
+   return result;
+}
+
 int setup_dtb(struct kimage *image,
unsigned long initrd_load_addr, unsigned long initrd_len,
char *cmdline, unsigned long cmdline_len,
@@ -60,10 +135,26 @@ int setup_dtb(struct kimage *image,
int range_len;
int ret;
 
+   /* check ranges against root's #address-cells and #size-cells */
+   if (image->type == KEXEC_TYPE_CRASH &&
+   (!cells_size_fitted(image->arch.elf_load_addr,
+   image->arch.elf_headers_sz) ||
+!cells_size_fitted(crashk_res.start,
+   crashk_res.end - crashk_res.start + 1))) {
+   pr_err("Crash memory region doesn't fit into DT's root cell 
sizes.\n");
+   ret = -EINVAL;
+   goto out_err;
+   }
+
/* duplicat

[PATCH v3 07/10] arm64: kexec_file: load initrd, device-tree and purgatory segments

[AKASHI Takahiro]

load_other_segments() sets up and adds all the memory segments necessary
other than kernel, including initrd, device-tree blob and purgatory.
Most of the code was borrowed from kexec-tools' counterpart.

arch_kimage_kernel_post_load_cleanup() is meant to free arm64-specific data
allocated for loading kernel.

Signed-off-by: AKASHI Takahiro 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/include/asm/kexec.h |  22 
 arch/arm64/kernel/Makefile |   3 +-
 arch/arm64/kernel/machine_kexec_file.c | 213 +
 3 files changed, 237 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/machine_kexec_file.c

diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index e17f0529a882..2fadd3cbf3af 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -93,6 +93,28 @@ static inline void crash_prepare_suspend(void) {}
 static inline void crash_post_resume(void) {}
 #endif
 
+#ifdef CONFIG_KEXEC_FILE
+#define ARCH_HAS_KIMAGE_ARCH
+
+struct kimage_arch {
+   void *dtb_buf;
+};
+
+struct kimage;
+
+#define arch_kimage_file_post_load_cleanup arch_kimage_file_post_load_cleanup
+extern int arch_kimage_file_post_load_cleanup(struct kimage *image);
+
+extern int setup_dtb(struct kimage *image,
+   unsigned long initrd_load_addr, unsigned long initrd_len,
+   char *cmdline, unsigned long cmdline_len,
+   char **dtb_buf, size_t *dtb_buf_len);
+extern int load_other_segments(struct kimage *image,
+   unsigned long kernel_load_addr,
+   char *initrd, unsigned long initrd_len,
+   char *cmdline, unsigned long cmdline_len);
+#endif
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index f2b4e816b6de..5df003d6157c 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -48,8 +48,9 @@ arm64-obj-$(CONFIG_ARM64_ACPI_PARKING_PROTOCOL)   += 
acpi_parking_protocol.o
 arm64-obj-$(CONFIG_PARAVIRT)   += paravirt.o
 arm64-obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
 arm64-obj-$(CONFIG_HIBERNATION)+= hibernate.o hibernate-asm.o
-arm64-obj-$(CONFIG_KEXEC)  += machine_kexec.o relocate_kernel.o
\
+arm64-obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o
\
   cpu-reset.o
+arm64-obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o
 arm64-obj-$(CONFIG_ARM64_RELOC_TEST)   += arm64-reloc-test.o
 arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
 arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
diff --git a/arch/arm64/kernel/machine_kexec_file.c 
b/arch/arm64/kernel/machine_kexec_file.c
new file mode 100644
index ..09be2674c2ab
--- /dev/null
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -0,0 +1,213 @@
+/*
+ * kexec_file for arm64
+ *
+ * Copyright (C) 2017 Linaro Limited
+ * Author: AKASHI Takahiro 
+ *
+ * Most code is derived from arm64 port of kexec-tools
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "kexec_file: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int __dt_root_addr_cells;
+static int __dt_root_size_cells;
+
+struct kexec_file_ops *kexec_file_loaders[] = {
+   NULL
+};
+
+int arch_kimage_file_post_load_cleanup(struct kimage *image)
+{
+   vfree(image->arch.dtb_buf);
+   image->arch.dtb_buf = NULL;
+
+   return kexec_kernel_post_load_cleanup(image);
+}
+
+int arch_kexec_walk_mem(struct kexec_buf *kbuf, int (*func)(u64, u64, void *))
+{
+   if (kbuf->image->type == KEXEC_TYPE_CRASH)
+   return walk_iomem_res_desc(crashk_res.desc,
+   IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
+   crashk_res.start, crashk_res.end,
+   kbuf, func);
+   else if (kbuf->top_down)
+   return walk_system_ram_res_rev(0, ULONG_MAX, kbuf, func);
+   else
+   return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
+}
+
+int setup_dtb(struct kimage *image,
+   unsigned long initrd_load_addr, unsigned long initrd_len,
+   char *cmdline, unsigned long cmdline_len,
+   char **dtb_buf, size_t *dtb_buf_len)
+{
+   char *buf = NULL;
+   size_t buf_size;
+   int nodeoffset;
+   u64 value;
+   int range_len;
+   int ret;
+
+   /* duplicate dt blob */
+   buf_size = fdt_totalsize(initial_boot_params);
+   range_len = (__dt_root_addr_cells + __dt_root_size_cells) * sizeof(u32);
+
+   if (initrd_load_addr)
+   buf_size += fdt_prop_len("initrd-start", sizeof(u64))
+   + fdt_prop_len("initr