Re: [PATCH 2/3] clockevents: Restart clockevent device before using it again

[Preeti U Murthy]

On 03/27/2015 10:44 PM, Viresh Kumar wrote:
> Next commit would update clockevents core to switch clockevent devices to
> ONESHOT_STOPPED state to avoid getting spurious interrupts on a tickless CPU.
> 
> Before programming the clockevent device for next event, we must switch its
> state to ONESHOT.
> 
> Switch state back to ONESHOT from ONESHOT_STOPPED at following places:
> 
> 1.) NOHZ_MODE_LOWRES Mode
> 
> Timers & hrtimers are dependent on tick for their working in this mode and the
> only place from where clockevent device is programmed is the tick-code.
> 
> Two routines can restart ticks in LOWRES mode: tick_nohz_restart() and
> tick_nohz_stop_sched_tick().
> 
> 2.) NOHZ_MODE_HIGHRES Mode
> 
> Tick & timers are dependent on hrtimers for their working in this mode and the
> only place from where clockevent device is programmed is the hrtimer-code.
> 
> Only hrtimer_reprogram() is responsible for programming the clockevent device
> for next event, if the clockevent device is stopped earlier. And updating that
> alone is sufficient here.
> 
> To make sure we haven't missed any corner case, add a WARN() for the case 
> where
> we try to reprogram clockevent device while we aren't configured in
> ONESHOT_STOPPED state.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  kernel/time/clockevents.c |  4 
>  kernel/time/hrtimer.c |  5 +
>  kernel/time/tick-sched.c  | 14 +-
>  3 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 04f6c3433f8e..e95896fd21fd 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -335,6 +335,10 @@ int clockevents_program_event(struct clock_event_device 
> *dev, ktime_t expires,
>   if (dev->state == CLOCK_EVT_STATE_SHUTDOWN)
>   return 0;
> 
> + /* We must be in ONESHOT state here */
> + WARN_ONCE(dev->state != CLOCK_EVT_STATE_ONESHOT, "Current state: %d\n",
> +   dev->state);
> +
>   /* Shortcut for clockevent devices that can deal with ktime. */
>   if (dev->features & CLOCK_EVT_FEAT_KTIME)
>   return dev->set_next_ktime(expires, dev);
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index bee0c1f78091..045ba7e2be6c 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -566,6 +566,7 @@ static int hrtimer_reprogram(struct hrtimer *timer,
>  {
>   struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(_bases);
>   ktime_t expires = ktime_sub(hrtimer_get_expires(timer), base->offset);
> + struct clock_event_device *dev = 
> __this_cpu_read(tick_cpu_device.evtdev);
>   int res;
> 
>   WARN_ON_ONCE(hrtimer_get_expires_tv64(timer) < 0);
> @@ -610,6 +611,10 @@ static int hrtimer_reprogram(struct hrtimer *timer,
>   if (cpu_base->hang_detected)
>   return 0;
> 
> + /* Switchback to ONESHOT state */
> + if (unlikely(dev->state == CLOCK_EVT_STATE_ONESHOT_STOPPED))
> + clockevents_set_state(dev, CLOCK_EVT_STATE_ONESHOT);
> +
>   /*
>* Clockevents returns -ETIME, when the event was in the past.
>*/
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index a4c4edac4528..47c04edd07df 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -694,8 +694,14 @@ static ktime_t tick_nohz_stop_sched_tick(struct 
> tick_sched *ts,
>   /* Check, if the timer was already in the past */
>   if (hrtimer_active(>sched_timer))
>   goto out;
> - } else if (!tick_program_event(expires, 0))
> + } else {
> + /* Switchback to ONESHOT state */
> + if (unlikely(dev->state == 
> CLOCK_EVT_STATE_ONESHOT_STOPPED))
> + clockevents_set_state(dev, 
> CLOCK_EVT_STATE_ONESHOT);
> +
> + if (!tick_program_event(expires, 0))
>   goto out;
> + }
>   /*
>* We are past the event already. So we crossed a
>* jiffie boundary. Update jiffies and raise the
> @@ -873,6 +879,8 @@ ktime_t tick_nohz_get_sleep_length(void)
> 
>  static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)
>  {
> + struct clock_event_device *dev = 
> __this_cpu_read(tick_cpu_device.evtdev);
> +
>   hrtimer_cancel(>sched_timer);
>   hrtimer_set_expires(>sched_timer, ts->last_tick);
> 
> @@ -887,6 +895,10 @@ static void tick_nohz_restart(struct tick_sched *ts, 
> ktime_t now)
>   if (hrtimer_active(>sched_timer))
>   break;
>   } else {
> + /* Switchback to ONESHOT state */
> + if (likely(dev->state == 
> CLOCK_EVT_STATE_ONESHOT_STOPPED))
> + clockevents_set_state(dev, 
> CLOCK_EVT_STATE_ONESHOT);
> +
>   if 

Re: [PATCH 3/3] clockevents: Switch state to ONESHOT_STOPPED for unused clockevent devices

[Preeti U Murthy]

On 03/27/2015 10:44 PM, Viresh Kumar wrote:
> Clockevent device can now be stopped by switching to ONESHOT_STOPPED state, to
> avoid getting spurious interrupts on a tickless CPU.
> 
> Switch state to ONESHOT_STOPPED at following places:
> 
> 1.) NOHZ_MODE_LOWRES Mode
> 
> Timers & hrtimers are dependent on tick for their working in this mode and the
> only place from where clockevent device is programmed is the tick-code.
> 
> In LOWRES mode we skip reprogramming the clockevent device in
> tick_nohz_stop_sched_tick() if expires == KTIME_MAX. In addition to that we 
> must
> also switch the clockevent device to ONESHOT_STOPPED state to avoid all 
> spurious
> interrupts that may follow.
> 
> 2.) NOHZ_MODE_HIGHRES Mode
> 
> Tick & timers are dependent on hrtimers for their working in this mode and the
> only place from where clockevent device is programmed is the hrtimer-code.
> 
> There are two places here from which we reprogram the clockevent device or 
> skip
> reprogramming it on expires == KTIME_MAX.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  kernel/time/hrtimer.c| 46 ++
>  kernel/time/tick-sched.c |  3 +++
>  2 files changed, 45 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 045ba7e2be6c..89d4b593dfc0 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -543,8 +543,19 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base 
> *cpu_base, int skip_equal)
>   if (cpu_base->hang_detected)
>   return;
> 
> - if (cpu_base->expires_next.tv64 != KTIME_MAX)
> + if (cpu_base->expires_next.tv64 != KTIME_MAX) {
>   tick_program_event(cpu_base->expires_next, 1);
> + } else {
> + struct clock_event_device *dev =
> + __this_cpu_read(tick_cpu_device.evtdev);
> + /*
> +  * Don't need clockevent device anymore, stop it.
> +  *
> +  * We reach here only for NOHZ_MODE_HIGHRES mode and we are
> +  * guaranteed that no timers/hrtimers are enqueued on this cpu.
> +  */
> + clockevents_set_state(dev, CLOCK_EVT_STATE_ONESHOT_STOPPED);
> + }
>  }
> 
>  /*
> @@ -1312,9 +1323,36 @@ void hrtimer_interrupt(struct clock_event_device *dev)
>   cpu_base->in_hrtirq = 0;
>   raw_spin_unlock(_base->lock);
> 
> - /* Reprogramming necessary ? */
> - if (expires_next.tv64 == KTIME_MAX ||
> - !tick_program_event(expires_next, 0)) {
> + if (expires_next.tv64 == KTIME_MAX) {
> + struct clock_event_device *dev =
> + __this_cpu_read(tick_cpu_device.evtdev);
> +
> + cpu_base->hang_detected = 0;
> +
> + /*
> +  * Don't need clockevent device anymore, stop it.
> +  *
> +  * We reach here only for NOHZ_MODE_HIGHRES mode and we are
> +  * guaranteed that no timers/hrtimers are enqueued on this cpu.
> +  *
> +  * Most of the scenarios will be covered by similar code
> +  * present in hrtimer_force_reprogram(), as we always try to
> +  * evaluate tick requirement on idle/irq exit and cancel
> +  * tick-sched hrtimer when tick isn't required anymore.
> +  *
> +  * It is required here as well as a special case.
> +  *
> +  * Last hrtimer fires on a tickless CPU and doesn't rearm
> +  * itself. tick_nohz_irq_exit() reevaluates next event and it
> +  * gets expires == KTIME_MAX. Because tick was already stopped,
> +  * and last expires == new_expires, we return early. And the
> +  * clockevent device is never stopped.
> +  */
> + clockevents_set_state(dev, CLOCK_EVT_STATE_ONESHOT_STOPPED);
> + return;
> + }
> +
> + if (!tick_program_event(expires_next, 0)) {
>   cpu_base->hang_detected = 0;
>   return;
>   }
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 47c04edd07df..ff271a26fa4d 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -685,6 +685,9 @@ static ktime_t tick_nohz_stop_sched_tick(struct 
> tick_sched *ts,
>if (unlikely(expires.tv64 == KTIME_MAX)) {
>   if (ts->nohz_mode == NOHZ_MODE_HIGHRES)
>   hrtimer_cancel(>sched_timer);
> + else
> + /* stop clock event device */
> + clockevents_set_state(dev, 
> CLOCK_EVT_STATE_ONESHOT_STOPPED);
>   goto out;
>   }
> 
Reviewed-by: Preeti U. Murthy 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the 

Re: [PATCH 1/3] clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state

[Preeti U Murthy]

On 03/27/2015 10:44 PM, Viresh Kumar wrote:
> When no timers/hrtimers are pending, the expiry time is set to a special 
> value:
> 'KTIME_MAX'. This normally happens with NO_HZ_{IDLE|FULL} in both 
> LOWRES/HIGHRES
> modes.
> 
> When 'expiry == KTIME_MAX', we either cancel the 'tick-sched' hrtimer
> (NOHZ_MODE_HIGHRES) or skip reprogramming clockevent device 
> (NOHZ_MODE_LOWRES).
> But, the clockevent device is already reprogrammed from the tick-handler for
> next tick.
> 
> As the clock event device is programmed in ONESHOT mode it will at least fire
> one more time (unnecessarily). Timers on few implementations (like
> arm_arch_timer, etc.) only support PERIODIC mode and their drivers emulate
> ONESHOT over that. Which means that on these platforms we will get spurious
> interrupts periodically (at last programmed interval rate, normally tick 
> rate).
> 
> In order to avoid spurious interrupts, the clockevent device should be stopped
> or its interrupts should be masked.
> 
> A simple (yet hacky) solution to get this fixed could be: update
> hrtimer_force_reprogram() to always reprogram clockevent device and update
> clockevent drivers to STOP generating events (or delay it to max time) when
> 'expires' is set to KTIME_MAX. But the drawback here is that every clockevent
> driver has to be hacked for this particular case and its very easy for new 
> ones
> to miss this.
> 
> However, Thomas suggested to add an optional state ONESHOT_STOPPED to solve 
> this
> problem: lkml.org/lkml/2014/5/9/508.
> 
> This patch adds support for ONESHOT_STOPPED state in clockevents core. It will
> only be available to drivers that implement the state-specific callbacks 
> instead
> of the legacy ->set_mode() callback.
> 
> Signed-off-by: Viresh Kumar 
> ---
>  include/linux/clockchips.h |  7 ++-
>  kernel/time/clockevents.c  | 14 +-
>  kernel/time/timer_list.c   |  6 ++
>  3 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
> index e20232c3320a..33ad247f8662 100644
> --- a/include/linux/clockchips.h
> +++ b/include/linux/clockchips.h
> @@ -51,12 +51,15 @@ enum clock_event_mode {
>   *   reached from DETACHED or SHUTDOWN.
>   * ONESHOT:  Device is programmed to generate event only once. Can be reached
>   *   from DETACHED or SHUTDOWN.
> + * ONESHOT_STOPPED: Device was programmed in ONESHOT mode and is temporarily
> + *   stopped.
>   */
>  enum clock_event_state {
>   CLOCK_EVT_STATE_DETACHED = 0,
>   CLOCK_EVT_STATE_SHUTDOWN,
>   CLOCK_EVT_STATE_PERIODIC,
>   CLOCK_EVT_STATE_ONESHOT,
> + CLOCK_EVT_STATE_ONESHOT_STOPPED,
>  };
> 
>  /*
> @@ -103,6 +106,7 @@ enum clock_event_state {
>   * @set_mode:legacy set mode function, only for modes <= 
> CLOCK_EVT_MODE_RESUME.
>   * @set_state_periodic:  switch state to periodic, if !set_mode
>   * @set_state_oneshot:   switch state to oneshot, if !set_mode
> + * @set_state_oneshot_stopped: switch state to oneshot_stopped, if !set_mode
>   * @set_state_shutdown:  switch state to shutdown, if !set_mode
>   * @tick_resume: resume clkevt device, if !set_mode
>   * @broadcast:   function to broadcast events
> @@ -136,12 +140,13 @@ struct clock_event_device {
>* State transition callback(s): Only one of the two groups should be
>* defined:
>* - set_mode(), only for modes <= CLOCK_EVT_MODE_RESUME.
> -  * - set_state_{shutdown|periodic|oneshot}(), tick_resume().
> +  * - set_state_{shutdown|periodic|oneshot|oneshot_stopped}(), 
> tick_resume().
>*/
>   void(*set_mode)(enum clock_event_mode mode,
>   struct clock_event_device *);
>   int (*set_state_periodic)(struct clock_event_device 
> *);
>   int (*set_state_oneshot)(struct clock_event_device 
> *);
> + int (*set_state_oneshot_stopped)(struct 
> clock_event_device *);
>   int (*set_state_shutdown)(struct clock_event_device 
> *);
>   int (*tick_resume)(struct clock_event_device *);
> 
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 73689df1e4b8..04f6c3433f8e 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -138,6 +138,17 @@ static int __clockevents_set_state(struct 
> clock_event_device *dev,
>   return -ENOSYS;
>   return dev->set_state_oneshot(dev);
> 
> + case CLOCK_EVT_STATE_ONESHOT_STOPPED:
> + /* Core internal bug */
> + if (WARN_ONCE(dev->state != CLOCK_EVT_STATE_ONESHOT,
> +   "Current state: %d\n", dev->state))
> + return -EINVAL;
> +
> + if (dev->set_state_oneshot_stopped)
> + return dev->set_state_oneshot_stopped(dev);
> +   

Re: [PATCH 3/4] mm: move lazy free pages to inactive list

[Minchan Kim]

Hello Andrew,

On Fri, Mar 20, 2015 at 03:43:58PM -0700, Andrew Morton wrote:
> On Wed, 11 Mar 2015 10:20:37 +0900 Minchan Kim  wrote:
> 
> > MADV_FREE is hint that it's okay to discard pages if there is
> > memory pressure and we uses reclaimers(ie, kswapd and direct reclaim)
> > to free them so there is no worth to remain them in active anonymous LRU
> > so this patch moves them to inactive LRU list's head.
> > 
> > This means that MADV_FREE-ed pages which were living on the inactive list
> > are reclaimed first because they are more likely to be cold rather than
> > recently active pages.
> > 
> > A arguable issue for the approach would be whether we should put it to
> > head or tail in inactive list. I selected *head* because kernel cannot
> > make sure it's really cold or warm for every MADV_FREE usecase but
> > at least we know it's not *hot* so landing of inactive head would be
> > comprimise for various usecases.
> > 
> > This is fixing a suboptimal behavior of MADV_FREE when pages living on
> > the active list will sit there for a long time even under memory
> > pressure while the inactive list is reclaimed heavily. This basically
> > breaks the whole purpose of using MADV_FREE to help the system to free
> > memory which is might not be used.
> > 
> > @@ -789,6 +790,23 @@ static void lru_deactivate_file_fn(struct page *page, 
> > struct lruvec *lruvec,
> > update_page_reclaim_stat(lruvec, file, 0);
> >  }
> >  
> > +
> > +static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec,
> > +   void *arg)
> >
> > ...
> >
> > @@ -844,6 +866,18 @@ void deactivate_file_page(struct page *page)
> > }
> >  }
> >  
> > +void deactivate_page(struct page *page)
> > +{
> 
> lru_deactivate_file_fn() and deactivate_file_page() are carefully
> documented and lru_deactivate_fn() and deactivate_page() should
> be as well.  In fact it becomes more important now that we have two
> similar-looking things.

Sorry, I have missed this comment.

Acutally, deactive_file_page was too specific on file-backed page
invalidation when I implemented first time. That's why it had a lot
description but deactivate_page is too general so I think short comment
is enough. :)

Here it goes.

Thanks.

>From 1dbff1d18876962e5248346b59e41014561c09ac Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 30 Mar 2015 14:30:44 +0900
Subject: [PATCH] mm: document deactivate_page

This patch adds function description for deactivate_page.

Signed-off-by: Minchan Kim 
---
 mm/swap.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/mm/swap.c b/mm/swap.c
index 6b5adc7..b65fc8c 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -866,6 +866,13 @@ void deactivate_file_page(struct page *page)
}
 }
 
+/**
+ * deactivate_page - deactivate a page
+ * @page: page to deactivate
+ *
+ * This function moves @page to inactive list if @page was on active list and
+ * was not unevictable page to accelerate to reclaim @page.
+ */
 void deactivate_page(struct page *page)
 {
if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) {
-- 
1.9.3


> 
> 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] powerpc/powernv: Reboot when requested by firmware

[Michael Ellerman]

On Mon, 2015-03-30 at 12:45 +1030, Joel Stanley wrote:
> Use orderly_reboot so userspace will to shut itself down via the reboot
> path. This is required for graceful reboot initiated by the BMC, such
> as when a user uses ipmitool to issue a 'chassis power cycle' command.
> 
> Signed-off-by: Joel Stanley 
> ---
>  arch/powerpc/platforms/powernv/opal-power.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal-power.c 
> b/arch/powerpc/platforms/powernv/opal-power.c
> index 48bf5b0..ac46c2c 100644
> --- a/arch/powerpc/platforms/powernv/opal-power.c
> +++ b/arch/powerpc/platforms/powernv/opal-power.c
> @@ -29,8 +29,9 @@ static int opal_power_control_event(struct notifier_block 
> *nb,
>  
>   switch (type) {
>   case SOFT_REBOOT:
> - /* Fall through. The service processor is responsible for
> -  * bringing the machine back up */
> + pr_info("OPAL: reboot requested\n");
> + orderly_reboot();
> + break;

Acked-by: Michael Ellerman 


Andrew, do you want to take these 2 via your tree? Assuming folks are OK with
patch 1.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/86] x86/gart: use uapi/linux/pci_ids.h directly

[Ingo Molnar]

* Michael S. Tsirkin  wrote:

> Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h,
> use the new header directly so we can drop
> the wrapper in include/linux/pci_ids.h.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  arch/x86/kernel/aperture_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index 76164e1..3b52a56 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -17,7 +17,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> MST
> 

NAK, it's absolutely ridiculous to send a 86 patches series for a 
trivial change like this!

Just do the rename in a single patch and avoid the churn. Even if 
there are conflicts, they are utmost trivial to fix up.

In fact the usual way to do such renames is to wait until the end of 
-rc1, auto-generate it and send Linus the core patch with the trivial 
renames straight away.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] mm: make every pte dirty on do_swap_page

[Minchan Kim]

2nd description trial.

>From ccfc6c79634f6cec69d8fb23b0e863ebfa5b893c Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 30 Mar 2015 13:43:08 +0900
Subject: [PATCH v2] mm: make every pte dirty on do_swap_page

Bascially, MADV_FREE relys on the dirty bit in page table entry
to decide whether VM allows to discard the page or not.
IOW, if page table entry includes marked dirty bit, VM shouldn't
discard the page.

However, if swap-in by read fault happens, page table entry
point out the page doesn't have marked dirty bit so MADV_FREE
might discard the page wrongly. For avoiding the problem,
MADV_FREE did more checks with PageDirty and PageSwapCache.
It worked out because swapped-in page lives on swap cache
and since it was evicted from the swap cache, the page has
PG_dirty flag. So both page flags checks effectvely prevent
wrong discarding by MADV_FREE.

A problem in above logic is that swapped-in page has PG_dirty
since they are removed from swap cache so VM cannot consider
those pages as freeable any more alghouth madvise_free is
called in future. Look at below example for detail.

ptr = malloc();
memset(ptr);
..
..
.. heavy memory pressure so all of pages are swapped out
..
..
var = *ptr; -> a page swapped-in and removed from swapcache.
   page table doesn't mark dirty bit and page
   descriptor includes PG_dirty
..
..
madvise_free(ptr);
..
..
..
.. heavy memory pressure again.
.. In this time, VM cannot discard the page because the page
.. has *PG_dirty*

Rather than relying on the PG_dirty of page descriptor
for preventing discarding a page, dirty bit in page table is more
straightforward and simple. So, this patch makes page table dirty
bit marked whenever swap-in happens. Inherenty, page table entry
point out swapped-out page had dirty bit so I think it's no prblem.

With this, it removes complicated logic and makes freeable page
checking by madvise_free simple. Of course, we could solve
above mentioned example.

Cc: Hugh Dickins 
Cc: Cyrill Gorcunov 
Cc: Pavel Emelyanov 
Reported-by: Yalin Wang 
Signed-off-by: Minchan Kim 
---

* From v1:
  * Rewrite description - Andrew

 mm/madvise.c |  1 -
 mm/memory.c  | 10 --
 mm/rmap.c|  2 +-
 mm/vmscan.c  |  3 +--
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 22e8f0c..a045798 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -325,7 +325,6 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long 
addr,
continue;
}
 
-   ClearPageDirty(page);
unlock_page(page);
}
 
diff --git a/mm/memory.c b/mm/memory.c
index 6743966..48ff537 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2521,9 +2521,15 @@ static int do_swap_page(struct mm_struct *mm, struct 
vm_area_struct *vma,
 
inc_mm_counter_fast(mm, MM_ANONPAGES);
dec_mm_counter_fast(mm, MM_SWAPENTS);
-   pte = mk_pte(page, vma->vm_page_prot);
+
+   /*
+* The page is swapping in now was dirty before it was swapped out
+* so restore the state again(ie, pte_mkdirty) because MADV_FREE
+* relies on the dirty bit on page table.
+*/
+   pte = pte_mkdirty(mk_pte(page, vma->vm_page_prot));
if ((flags & FAULT_FLAG_WRITE) && reuse_swap_page(page)) {
-   pte = maybe_mkwrite(pte_mkdirty(pte), vma);
+   pte = maybe_mkwrite(pte, vma);
flags &= ~FAULT_FLAG_WRITE;
ret |= VM_FAULT_WRITE;
exclusive = 1;
diff --git a/mm/rmap.c b/mm/rmap.c
index dad23a4..281e806 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1275,7 +1275,7 @@ static int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
 
if (flags & TTU_FREE) {
VM_BUG_ON_PAGE(PageSwapCache(page), page);
-   if (!dirty && !PageDirty(page)) {
+   if (!dirty) {
/* It's a freeable page by MADV_FREE */
dec_mm_counter(mm, MM_ANONPAGES);
goto discard;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index dc6cd51..fffebf0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -805,8 +805,7 @@ static enum page_references page_check_references(struct 
page *page,
return PAGEREF_KEEP;
}
 
-   if (PageAnon(page) && !pte_dirty && !PageSwapCache(page) &&
-   !PageDirty(page))
+   if (PageAnon(page) && !pte_dirty && !PageSwapCache(page))
*freeable = true;
 
/* Reclaim if clean, defer dirty pages to writeback */
-- 
1.9.3

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ftracetest: Cope properly with stack tracer not being enabled

[Michael Ellerman]

If the stack tracer (CONFIG_STACK_TRACER) is disabled, the
fgraph-filter-stack test blows chunks:

  [8] ftrace - function graph filters with stack tracer [FAIL]
  + reset_tracer
  + echo nop
  ./ftracetest: 19: 
/home/michael/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc:
cannot create /proc/sys/kernel/stack_tracer_enabled: Directory 
nonexistent

Fix it by checking if the proc file exists before echoing to it. With
the patch applied it fails correctly with:

  [8] ftrace - function graph filters with stack tracer [UNSUPPORTED]

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
index c15e018e0220..3b1cf20cf6d8 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
@@ -16,7 +16,9 @@ fi
 
 do_reset() {
 reset_tracer
-echo 0 > /proc/sys/kernel/stack_tracer_enabled
+if [ -e /proc/sys/kernel/stack_tracer_enabled ]; then
+   echo 0 > /proc/sys/kernel/stack_tracer_enabled
+fi
 enable_tracing
 clear_trace
 echo > set_ftrace_filter
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] ftracetest: Convert exit -1 to exit $FAIL

[Michael Ellerman]

POSIX says that exit takes an unsigned integer between 0 and 255, so
using -1 doesn't work on POSIX shells.

There is already a well-defined failure code, $FAIL (1), so use that.

Signed-off-by: Michael Ellerman 
---

v2: Use exit $FAIL not exit 255.

 tools/testing/selftests/ftrace/test.d/00basic/basic4.tc | 2 +-
 tools/testing/selftests/ftrace/test.d/event/event-enable.tc | 2 +-
 tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc | 2 +-
 tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc  | 2 +-
 tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc | 2 +-
 tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc   | 2 +-
 tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/ftrace/test.d/00basic/basic4.tc 
b/tools/testing/selftests/ftrace/test.d/00basic/basic4.tc
index fd9c49a13612..aa51f6c17359 100644
--- a/tools/testing/selftests/ftrace/test.d/00basic/basic4.tc
+++ b/tools/testing/selftests/ftrace/test.d/00basic/basic4.tc
@@ -2,4 +2,4 @@
 # description: Basic event tracing check
 test -f available_events -a -f set_event -a -d events
 # check scheduler events are available
-grep -q sched available_events && exit 0 || exit -1
\ No newline at end of file
+grep -q sched available_events && exit 0 || exit $FAIL
diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
index 668616d9bb03..dbddb7836f73 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
@@ -9,7 +9,7 @@ do_reset() {
 fail() { #msg
 do_reset
 echo $1
-exit -1
+exit $FAIL
 }
 
 if [ ! -f set_event -o ! -d events/sched ]; then
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
index 655c415b6e7f..ef9b95dc10c5 100644
--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
@@ -9,7 +9,7 @@ do_reset() {
 fail() { #msg
 do_reset
 echo $1
-exit -1
+exit $FAIL
 }
 
 if [ ! -f set_event -o ! -d events/sched ]; then
diff --git a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
index 480845774007..af8cf01fc3a7 100644
--- a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
@@ -9,7 +9,7 @@ do_reset() {
 fail() { #msg
 do_reset
 echo $1
-exit -1
+exit $FAIL
 }
 
 if [ ! -f available_events -o ! -f set_event -o ! -d events ]; then
diff --git 
a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
index c15e018e0220..c652c06b231f 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter-stack.tc
@@ -25,7 +25,7 @@ do_reset() {
 fail() { # msg
 do_reset
 echo $1
-exit -1
+exit $FAIL
 }
 
 disable_tracing
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
index 6af5f6360b18..0ab2189613ef 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
@@ -17,7 +17,7 @@ do_reset() {
 fail() { # msg
 do_reset
 echo $1
-exit -1
+exit $FAIL
 }
 
 disable_tracing
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
index 2e719cb1fc4d..7808336d6f50 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
@@ -31,7 +31,7 @@ fail() { # mesg
 reset_tracer
 echo > set_ftrace_filter
 echo $1
-exit -1
+exit $FAIL
 }
 
 echo "Testing function tracer with profiler:"
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] extcon next for 4.1

[Chanwoo Choi]

Dear Greg,

This is extcon-next full request for v4.1. I add detailed description of this
pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.1

for you to fetch changes up to 66bee35f29683fc4a9a530a1c56a0ec45e3f7d72:

  extcon: Fix missing locking when [un]registering notifiers (2015-03-23 
11:06:04 +0900)


Update extcon for v4.1

This patchset include two new extcon driver and fix minor issue of extcon
driver.

Detailed description for patchset:
1. new extcon-max77843.c and extcon-usb-gpio.c extcon driver
- extcon-max77843.c driver support the MAXIM MAX77843 MUIC (Micor-USB Interface
  Controller) device which handles the various external connectors such as 
TA/USB
  /USB-HOST/JIG and so on.
- extcon-usb-gpio.c driver support the USB and USB-HOST cable detection by
  using the GPIO pin which is connected to USB ID pin. This GPIO pin updates the
  USB cable states.

2. Rename the filename of extcon core driver and add missing locking mechanism
- Rename the previous extcon-class driver.c as extcon.c because '-class'
  postfix is not necessary word.
- extcon core driver (extcon.c) used the raw_notifier_chain. It must be
  protected by locking mechanism to avoid the list changing while
  extcon_update_state() is executed.

3. Fix minor issue of extcon drviers
- Fix cable name by using the capital letter instead of small letter on
  extcon-max77693.c driver.
- Clean-up code of extcon-arizona.c to detect headphone cable.
- Fix the wrong return type and variable type on extcon-max77843.c.
- Fix the checkpatch warning of all extcon drivers.


Chanwoo Choi (2):
  extcon: Rename extcon core driver
  extcon: Fix the checkpatch warning

Charles Keepax (2):
  extcon: arizona: Deobfuscate arizona_extcon_do_magic
  extcon: arizona: Fix headphone clamping on wm5110

Dan Carpenter (2):
  extcon: max77843: Fix signedness bug in max77843_muic_set_debounce_time()
  extcon: max77843: Fix an error code in max77843_init_muic_regmap()

Hans de Goede (1):
  extcon: Fix missing locking when [un]registering notifiers

Jaewon Kim (3):
  extcon: max77693: Fix cable name of MHL-TA
  extcon: max77693: Use HOST term to express USB-HOST cable instead of OTG 
term
  extcon: max77843: Add max77843 MUIC driver

Roger Quadros (1):
  extcon: usb-gpio: Introduce gpio usb extcon driver

 .../devicetree/bindings/extcon/extcon-usb-gpio.txt |  18 +
 drivers/extcon/Kconfig |  17 +
 drivers/extcon/Makefile|   4 +-
 drivers/extcon/extcon-arizona.c|  49 +-
 drivers/extcon/extcon-max14577.c   |   5 +-
 drivers/extcon/extcon-max77693.c   |  37 +-
 drivers/extcon/extcon-max77843.c   | 881 +
 drivers/extcon/extcon-max8997.c|   5 +-
 drivers/extcon/extcon-rt8973a.c|   6 +-
 drivers/extcon/extcon-sm5502.c |   6 +-
 drivers/extcon/extcon-usb-gpio.c   | 237 ++
 drivers/extcon/{extcon-class.c => extcon.c}|  36 +-
 include/linux/mfd/arizona/core.h   |   2 +-
 sound/soc/codecs/arizona.c |   4 +-
 14 files changed, 1248 insertions(+), 59 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
 create mode 100644 drivers/extcon/extcon-max77843.c
 create mode 100644 drivers/extcon/extcon-usb-gpio.c
 rename drivers/extcon/{extcon-class.c => extcon.c} (97%)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] timers: Allocate per-cpu tvec_base's statically

[Viresh Kumar]

Hi Ingo/Thomas,

Here are few cleanups around timer-core initialization. The first one is
suggested by Peter Zijlstra [1] and the other two make few more changes in order
to simplify it.

Please see if they look fine.

--
viresh

[1] http://lkml.iu.edu/hypermail/linux/kernel/1503.3/04091.html

Peter Zijlstra (1):
  timer: Allocate per-cpu tvec_base's statically

Viresh Kumar (2):
  timer: Limit the scope of __tvec_bases to init_timers_cpu()
  timer: Don't initialize tvec_base on hotplug

 kernel/time/timer.c | 121 +++-
 1 file changed, 45 insertions(+), 76 deletions(-)

-- 
2.3.0.rc0.44.ga94655d

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] timer: Allocate per-cpu tvec_base's statically

[Viresh Kumar]

From: Peter Zijlstra 

Memory for tvec_base is allocated separately for boot CPU (statically) and
non-boot CPUs (dynamically).

The reason is because __TIMER_INITIALIZER() needs to set ->base to a valid
pointer (because we've made NULL special, hint: lock_timer_base()) and we cannot
get a compile time pointer to per-cpu entries because we don't know where we'll
map the section, even for the boot cpu.

This can be simplified a bit by statically allocating per-cpu memory. The only
disadvantage is that memory for one of the structures will stay unused, i.e. for
the boot CPU, which uses boot_tvec_bases.

This will also guarantee that tvec_base is cacheline aligned. Even though
tvec_base has cacheline_aligned stuck on, kzalloc_node() does not actually
respect that (but guarantees a minimum u64 alignment).

Signed-off-by: Peter Zijlstra 
Signed-off-by: Viresh Kumar 
---
 kernel/time/timer.c | 36 
 1 file changed, 8 insertions(+), 28 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 2d3f5c504939..6e8220ec8a62 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -93,6 +93,7 @@ struct tvec_base {
 struct tvec_base boot_tvec_bases;
 EXPORT_SYMBOL(boot_tvec_bases);
 static DEFINE_PER_CPU(struct tvec_base *, tvec_bases) = _tvec_bases;
+static DEFINE_PER_CPU(struct tvec_base, __tvec_bases);
 
 /* Functions below help us manage 'deferrable' flag */
 static inline unsigned int tbase_get_deferrable(struct tvec_base *base)
@@ -1534,46 +1535,25 @@ EXPORT_SYMBOL(schedule_timeout_uninterruptible);
 
 static int init_timers_cpu(int cpu)
 {
-   int j;
-   struct tvec_base *base;
+   struct tvec_base *base = per_cpu(tvec_bases, cpu);
static char tvec_base_done[NR_CPUS];
+   int j;
 
if (!tvec_base_done[cpu]) {
static char boot_done;
 
-   if (boot_done) {
-   /*
-* The APs use this path later in boot
-*/
-   base = kzalloc_node(sizeof(*base), GFP_KERNEL,
-   cpu_to_node(cpu));
-   if (!base)
-   return -ENOMEM;
-
-   /* Make sure tvec_base has TIMER_FLAG_MASK bits free */
-   if (WARN_ON(base != tbase_get_base(base))) {
-   kfree(base);
-   return -ENOMEM;
-   }
-   per_cpu(tvec_bases, cpu) = base;
+   if (!boot_done) {
+   boot_done = 1; /* skip the boot cpu */
} else {
-   /*
-* This is for the boot CPU - we use compile-time
-* static initialisation because per-cpu memory isn't
-* ready yet and because the memory allocators are not
-* initialised either.
-*/
-   boot_done = 1;
-   base = _tvec_bases;
+   base = per_cpu_ptr(&__tvec_bases, cpu);
+   per_cpu(tvec_bases, cpu) = base;
}
+
spin_lock_init(>lock);
tvec_base_done[cpu] = 1;
base->cpu = cpu;
-   } else {
-   base = per_cpu(tvec_bases, cpu);
}
 
-
for (j = 0; j < TVN_SIZE; j++) {
INIT_LIST_HEAD(base->tv5.vec + j);
INIT_LIST_HEAD(base->tv4.vec + j);
-- 
2.3.0.rc0.44.ga94655d

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] timer: Limit the scope of __tvec_bases to init_timers_cpu()

[Viresh Kumar]

per-cpu variable '__tvec_bases' is used for all CPUs except the boot CPU, which
uses 'boot_tvec_bases'. Because of this special case, we shouldn't make direct
references to __tvec_bases from timer core as there are chances of using the
wrong instance for boot CPU.

To force that, lets move __tvec_bases to the only routine which can use it
directly (to set tvec_bases).

Signed-off-by: Viresh Kumar 
---
 kernel/time/timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 6e8220ec8a62..40918a5d3e1d 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -93,7 +93,6 @@ struct tvec_base {
 struct tvec_base boot_tvec_bases;
 EXPORT_SYMBOL(boot_tvec_bases);
 static DEFINE_PER_CPU(struct tvec_base *, tvec_bases) = _tvec_bases;
-static DEFINE_PER_CPU(struct tvec_base, __tvec_bases);
 
 /* Functions below help us manage 'deferrable' flag */
 static inline unsigned int tbase_get_deferrable(struct tvec_base *base)
@@ -1537,6 +1536,7 @@ static int init_timers_cpu(int cpu)
 {
struct tvec_base *base = per_cpu(tvec_bases, cpu);
static char tvec_base_done[NR_CPUS];
+   static DEFINE_PER_CPU(struct tvec_base, __tvec_bases);
int j;
 
if (!tvec_base_done[cpu]) {
-- 
2.3.0.rc0.44.ga94655d

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] timer: Don't initialize tvec_base on hotplug

[Viresh Kumar]

There is no need to call init_timers_cpu() on every cpu hotplug event, there is
not much we need to reset.

- Timer-lists are already empty at the end of migrate_timers().
- timer_jiffies will be refreshed while adding a new timer, after the CPU is
  online again.
- active_timers and all_timers can be reset from migrate_timers().

Signed-off-by: Viresh Kumar 
---
 kernel/time/timer.c | 101 +++-
 1 file changed, 45 insertions(+), 56 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 40918a5d3e1d..aa02d49b3748 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1532,44 +1532,6 @@ signed long __sched 
schedule_timeout_uninterruptible(signed long timeout)
 }
 EXPORT_SYMBOL(schedule_timeout_uninterruptible);
 
-static int init_timers_cpu(int cpu)
-{
-   struct tvec_base *base = per_cpu(tvec_bases, cpu);
-   static char tvec_base_done[NR_CPUS];
-   static DEFINE_PER_CPU(struct tvec_base, __tvec_bases);
-   int j;
-
-   if (!tvec_base_done[cpu]) {
-   static char boot_done;
-
-   if (!boot_done) {
-   boot_done = 1; /* skip the boot cpu */
-   } else {
-   base = per_cpu_ptr(&__tvec_bases, cpu);
-   per_cpu(tvec_bases, cpu) = base;
-   }
-
-   spin_lock_init(>lock);
-   tvec_base_done[cpu] = 1;
-   base->cpu = cpu;
-   }
-
-   for (j = 0; j < TVN_SIZE; j++) {
-   INIT_LIST_HEAD(base->tv5.vec + j);
-   INIT_LIST_HEAD(base->tv4.vec + j);
-   INIT_LIST_HEAD(base->tv3.vec + j);
-   INIT_LIST_HEAD(base->tv2.vec + j);
-   }
-   for (j = 0; j < TVR_SIZE; j++)
-   INIT_LIST_HEAD(base->tv1.vec + j);
-
-   base->timer_jiffies = jiffies;
-   base->next_timer = base->timer_jiffies;
-   base->active_timers = 0;
-   base->all_timers = 0;
-   return 0;
-}
-
 #ifdef CONFIG_HOTPLUG_CPU
 static void migrate_timer_list(struct tvec_base *new_base, struct list_head 
*head)
 {
@@ -1611,6 +1573,9 @@ static void migrate_timers(int cpu)
migrate_timer_list(new_base, old_base->tv5.vec + i);
}
 
+   old_base->active_timers = 0;
+   old_base->all_timers = 0;
+
spin_unlock(_base->lock);
spin_unlock_irq(_base->lock);
put_cpu_var(tvec_bases);
@@ -1620,25 +1585,16 @@ static void migrate_timers(int cpu)
 static int timer_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
 {
-   long cpu = (long)hcpu;
-   int err;
-
-   switch(action) {
-   case CPU_UP_PREPARE:
-   case CPU_UP_PREPARE_FROZEN:
-   err = init_timers_cpu(cpu);
-   if (err < 0)
-   return notifier_from_errno(err);
-   break;
 #ifdef CONFIG_HOTPLUG_CPU
+   switch (action) {
case CPU_DEAD:
case CPU_DEAD_FROZEN:
-   migrate_timers(cpu);
+   migrate_timers((long)hcpu);
break;
-#endif
default:
break;
}
+#endif
return NOTIFY_OK;
 }
 
@@ -1646,18 +1602,51 @@ static struct notifier_block timers_nb = {
.notifier_call  = timer_cpu_notify,
 };
 
+static void __init init_timer_cpu(struct tvec_base *base, int cpu)
+{
+   int j;
 
-void __init init_timers(void)
+   base->cpu = cpu;
+   per_cpu(tvec_bases, cpu) = base;
+   spin_lock_init(>lock);
+
+   for (j = 0; j < TVN_SIZE; j++) {
+   INIT_LIST_HEAD(base->tv5.vec + j);
+   INIT_LIST_HEAD(base->tv4.vec + j);
+   INIT_LIST_HEAD(base->tv3.vec + j);
+   INIT_LIST_HEAD(base->tv2.vec + j);
+   }
+   for (j = 0; j < TVR_SIZE; j++)
+   INIT_LIST_HEAD(base->tv1.vec + j);
+
+   base->timer_jiffies = jiffies;
+   base->next_timer = base->timer_jiffies;
+}
+
+static void __init init_timer_cpus(void)
 {
-   int err;
+   /* Used for all CPUs, except boot CPU (which uses boot_tvec_bases) */
+   static DEFINE_PER_CPU(struct tvec_base, __tvec_bases);
+   struct tvec_base *base;
+   int local_cpu = smp_processor_id();
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   if (likely(cpu != local_cpu))
+   base = per_cpu_ptr(&__tvec_bases, cpu);
+   else
+   base = _tvec_bases;
+
+   init_timer_cpu(base, cpu);
+   }
+}
 
+void __init init_timers(void)
+{
/* ensure there are enough low bits for flags in timer->base pointer */
BUILD_BUG_ON(__alignof__(struct tvec_base) & TIMER_FLAG_MASK);
 
-   err = timer_cpu_notify(_nb, (unsigned long)CPU_UP_PREPARE,
-  (void *)(long)smp_processor_id());
-   BUG_ON(err != NOTIFY_OK);
-
+   init_timer_cpus();
init_timer_stats();

Re: [PATCH v6 0/6] Add common clock support for Broadcom iProc architecture

[Ray Jui]

Hi Mike,

This is the latest patch series of the Broadcom iProc clock driver that
I was talking about. I believe it has addressed your previous code
review comments by switching to use assigned-clocks/assigned-clock-rates
for configuring PLL clock at the time of clock registration.

Please have a look and let us know if this can be pulled in.

Thanks,

Ray

On 3/17/2015 10:45 PM, Ray Jui wrote:
> This patchset contains the initial common clock support for Broadcom's iProc
> family of SoCs. The iProc clock architecture comprises of various PLLs, e.g.,
> ARMPLL, GENPLL, LCPLL0, MIPIPLL, and etc. An onboard crystal serves as the
> basic reference clock for these PLLs. Each PLL may have several leaf clocks.
> One special group of clocks is the ASIU clocks, which are dervied directly
> from the crystal reference clock.
> 
> This patchset also contains the basic clock support for the Broadcom Cygnus
> SoC, which implements the iProc clock architecture
> 
> Changes from v5:
>  - Rebase to v4.0-rc4
>  - Drop of_clk_get_parent_rate helper function from the clock framework
>  - Get rid of custom "clock-frequency" support in iProc PLL code. Instead, add
>standard clock set_rate and round_rate support and make use of DT 
> properties
>"assigned-clocks" and "assigned-clock-rates" to initialize PLL to the
>desired rate when registering to the clock framework
>  - Add SW workaround for ASIC bug on MIPI PLL to always read back the same
>register following a write transaction, to ensure value is written to the
>correct register
> 
> Changes from v4:
>  - Add of_clk_get_parent_rate helper function into the clock framework
>  - Switch to use of_clk_get_parent_rate in the iProc PLL clock driver
> 
> Changes from v3:
>  - Fix incorrect use of passing in of_clk_src_onecell_get when adding ARM PLL
>and other iProc PLLs as clock provider. These PLLs have zero cells in DT 
> and
>thefore of_clk_src_simple_get should be used instead
>  - Rename Cygnus MIPI PLL Channel 2 clock from BCM_CYGNUS_MIPIPLL_CH2_UNUSED
>to BCM_CYGNUS_MIPIPLL_CH2_V3D, since a 3D graphic rendering engine has been
>integrated into Cygnus revision B0 and has its core clock running off
>MIPI PLL Channel 2
>  - Changed default MIPI PLL VCO frequency from 1.75 GHz to 2.1 GHz. This 
> allows
>us to derive 300 MHz V3D clock from channel 2 through the post divisor
> 
> Changes from v2:
>  - Re-arrange Cygnus clock/pll init functions so each init function is right
>next to its clock table
>  - Removed #defines for number of clocks in Cygnus. Have the number of clocks
>automatically determined based on array size of the clock table
> 
> Changes from v1:
>  - Separate drivers/clk/Makefile change for drivers/clk/bcm out to a 
> standalone patch
> 
> Ray Jui (6):
>   clk: iproc: define Broadcom iProc clock binding
>   clk: iproc: add initial common clock support
>   clk: Change bcm clocks build dependency
>   clk: cygnus: add clock support for Broadcom Cygnus
>   ARM: dts: enable clock support for Broadcom Cygnus
>   clk: cygnus: remove Cygnus dummy clock binding
> 
>  .../devicetree/bindings/clock/bcm-cygnus-clock.txt |   34 --
>  .../bindings/clock/brcm,iproc-clocks.txt   |  171 +++
>  arch/arm/boot/dts/bcm-cygnus-clock.dtsi|  112 -
>  arch/arm/boot/dts/bcm-cygnus.dtsi  |2 +-
>  drivers/clk/Makefile   |2 +-
>  drivers/clk/bcm/Kconfig|9 +
>  drivers/clk/bcm/Makefile   |2 +
>  drivers/clk/bcm/clk-cygnus.c   |  284 
>  drivers/clk/bcm/clk-iproc-armpll.c |  282 +++
>  drivers/clk/bcm/clk-iproc-asiu.c   |  275 +++
>  drivers/clk/bcm/clk-iproc-clk.c|  244 ++
>  drivers/clk/bcm/clk-iproc-pll.c|  490 
> 
>  drivers/clk/bcm/clk-iproc.h|  164 +++
>  include/dt-bindings/clock/bcm-cygnus.h |   65 +++
>  14 files changed, 2075 insertions(+), 61 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
>  create mode 100644 
> Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
>  create mode 100644 drivers/clk/bcm/clk-cygnus.c
>  create mode 100644 drivers/clk/bcm/clk-iproc-armpll.c
>  create mode 100644 drivers/clk/bcm/clk-iproc-asiu.c
>  create mode 100644 drivers/clk/bcm/clk-iproc-clk.c
>  create mode 100644 drivers/clk/bcm/clk-iproc-pll.c
>  create mode 100644 drivers/clk/bcm/clk-iproc.h
>  create mode 100644 include/dt-bindings/clock/bcm-cygnus.h
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Input: Add driver for a generic ADC keypad

[Andrew Bresticker]

On Sat, Mar 28, 2015 at 7:02 AM, Jonathan Cameron  wrote:
> On 28/03/15 00:43, Andrew Bresticker wrote:
>> Add a polled input driver for a keypad in which the buttons are connected
>> in resistor ladders to an ADC.  The IIO framework is used to claim and
>> read the ADC channels.
>>
>> Signed-off-by: Andrew Bresticker 

>> +static int adc_keypad_probe(struct platform_device *pdev)
>> +{
>> + struct adc_keypad *keypad;
>> + struct input_polled_dev *poll_dev;
>> + struct input_dev *input;
>> + unsigned int i;
>> + int ret;
>> +
>> + keypad = devm_kzalloc(>dev, sizeof(*keypad), GFP_KERNEL);
>> + if (!keypad)
>> + return -ENOMEM;
>> + keypad->dev = >dev;
>> + platform_set_drvdata(pdev, keypad);
>> +
>> + keypad->iio_chans = iio_channel_get_all(>dev);
>> + if (IS_ERR(keypad->iio_chans)) {
>> + dev_err(>dev, "Failed to get IIO channels: %ld\n",
>> + PTR_ERR(keypad->iio_chans));
>> + return PTR_ERR(keypad->iio_chans);
>> + }
>> +
>> + i = 0;
>> + while (keypad->iio_chans[i].channel != NULL)
>> + i++;
>> + keypad->num_chans = i;
>> + keypad->chan_map = devm_kcalloc(>dev, keypad->num_chans,
>> + sizeof(*keypad->chan_map), GFP_KERNEL);
>> + if (!keypad->chan_map) {
>> + ret = -ENOMEM;
>> + goto put_chans;
>> + }
>> +
>> + ret = adc_keypad_of_parse(keypad);
>> + if (ret < 0)
>> + goto put_chans;
>> +
>> + poll_dev = devm_input_allocate_polled_device(>dev);
>> + if (!poll_dev) {
>> + ret = -ENOMEM;
>> + goto put_chans;
>> + }
>> + keypad->poll_dev = poll_dev;
>> +
>> + poll_dev->private = keypad;
>> + poll_dev->poll = adc_keypad_poll;
>> + poll_dev->poll_interval = keypad->poll_interval;
>> +
>> + input = poll_dev->input;
>> + input->name = pdev->name;
>> + input->phys = "adc-keys/input0";
>> +
>> + input->id.bustype = BUS_HOST;
>> + input->id.vendor = 0x0001;
>> + input->id.product = 0x0001;
>> + input->id.version = 0x0100;

> Why these particular values?

I just chose these because these are the values most other platform
input devices use, including gpio_keys and gpio_keys_polled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Input: Add binding document for a generic ADC keypad

[Andrew Bresticker]

On Sat, Mar 28, 2015 at 9:00 PM, Dmitry Torokhov
 wrote:
> On Fri, Mar 27, 2015 at 05:43:17PM -0700, Andrew Bresticker wrote:
>> Add a binding document for a generic ADC keypad.  Buttons on an ADC
>> keypad are connected in a resistor ladder to an ADC.  The binding
>> describes the mapping of ADC channel and voltage ranges to buttons.
>>
>> Signed-off-by: Andrew Bresticker 
>> Cc: Rob Herring 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Ian Campbell 
>> Cc: Kumar Gala 
>> ---
>>  .../devicetree/bindings/input/adc-keys.txt | 43 
>> ++
>>  1 file changed, 43 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
>>
>> diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt 
>> b/Documentation/devicetree/bindings/input/adc-keys.txt
>> new file mode 100644
>> index 000..c9a57de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/adc-keys.txt
>> @@ -0,0 +1,43 @@
>> +Generic ADC keypad
>> +==
>> +
>> +Required properties:
>> + - compatible: "adc-keys"
>> + - poll-interval: Polling interval time in ms.
>> + - io-channels: List of IIO channels used by the keypad.
>> +   See ../iio/iio-bindings.txt for details.
>> +
>> +Optional properties:
>> + - autorepeat: Enable auto-repeat.
>> +
>> +Each button on the ADC keypad is represented by a sub-node.
>> +
>> +Required sub-node properties:
>> + - label: Descriptive name for the key.
>> + - linux,code: Keycode to emit.
>> + - channel: IIO channel (index into the 'io-channels' above) to which this
>> +   button is attached.
>> + - min-voltage: Minimum voltage in uV when this key is pressed.
>> + - max-voltage: Maximum voltage in uV when this key is pressed.
>> +
>> +Optional sub-node properties:
>> + - linux,input-type: Event type this key generates.  Defaults to 1 (EV_KEY) 
>> if
>> +   not specified.
>
> I'd rather we have it defined explicitly in the binding, i.e. make it a
> required property?

Sure, will do.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Input: Add binding document for a generic ADC keypad

[Andrew Bresticker]

On Sat, Mar 28, 2015 at 7:03 AM, Jonathan Cameron  wrote:
> On 28/03/15 00:43, Andrew Bresticker wrote:
>> Add a binding document for a generic ADC keypad.  Buttons on an ADC
>> keypad are connected in a resistor ladder to an ADC.  The binding
>> describes the mapping of ADC channel and voltage ranges to buttons.
>>
>> Signed-off-by: Andrew Bresticker 
>> Cc: Rob Herring 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Ian Campbell 
>> Cc: Kumar Gala 
>
> Just thinking about this, what options do we have for how such a keypad might
> be wired.  The interesting cases are the more than one key at a time ones.
>
> If that happens, then we end up with a voltage that should allow us to
> work out which combination of keys is pressed.
>
> http://en.wikipedia.org/wiki/Resistor_ladder
>
> The binding as it stands only works for single keys being pressed at a time
> (I think!)

Right.  The binding was meant for the simplest resistor ladder case,
something like http://linksprite.com/wiki/images/d/d2/Lcd-button-ladder.png
where only a single button press can be detected.  It will also work
with the more complex resistor ladders, but will only be able to
detect if a single button is pressed.

> Do we want to make it flexible enough to cope with multiple keys?
> I guess we'd need to model the common resistor ladder forms and provide
> a way of specifying the different setups in the device tree.

Given that the hardware I'm dealing with doesn't support this, I'd
prefer to leave it as a possible future extension :).  That said, one
way to do this would be to specify a table mapping the possible
combinations to voltages in the DT, though that table would grow
exponentially.  Another way would be to describe the circuit (R-2R,
logarithmic, etc.) with resistor values in the DT and then have the
driver do the math.

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

[Wu, Feng]

> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Saturday, March 28, 2015 3:30 AM
> To: Wu, Feng
> Cc: h...@zytor.com; t...@linutronix.de; mi...@redhat.com; x...@kernel.org;
> g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
> eric.au...@linaro.org; linux-kernel@vger.kernel.org;
> io...@lists.linux-foundation.org; k...@vger.kernel.org
> Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU
> is blocked
> 
> On Fri, Mar 27, 2015 at 06:34:14AM +, Wu, Feng wrote:
> > > > Currently, the following code is executed before local_irq_disable() is
> called,
> > > > so do you mean 1)moving local_irq_disable() to the place before it. 2) 
> > > > after
> > > interrupt
> > > > is disabled, set KVM_REQ_EVENT in case the ON bit is set?
> > >
> > > 2) after interrupt is disabled, set KVM_REQ_EVENT in case the ON bit
> > > is set.
> >
> > Here is my understanding about your comments here:
> > - Disable interrupts
> > - Check 'ON'
> > - Set KVM_REQ_EVENT if 'ON' is set
> >
> > Then we can put the above code inside " if
> (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) "
> > just like it used to be. However, I still have some questions about this
> comment:
> >
> > 1. Where should I set KVM_REQ_EVENT? In function vcpu_enter_guest(), or
> other places?
> 
> See below:
> 
> > If in vcpu_enter_guest(), since currently local_irq_disable() is called 
> > after
> 'KVM_REQ_EVENT'
> > is checked, is it helpful to set KVM_REQ_EVENT after local_irq_disable() is
> called?
> 
> local_irq_disable();
> 
>   *** add code here ***

So we need add code like the following here, right?

  if ('ON' is set)
  kvm_make_request(KVM_REQ_EVENT, vcpu);

> 
> if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
>   ^^
> || need_resched() || signal_pending(current)) {
> vcpu->mode = OUTSIDE_GUEST_MODE;
> smp_wmb();
> local_irq_enable();
> preempt_enable();
> vcpu->srcu_idx = srcu_read_lock(>kvm->srcu);
> r = 1;
> goto cancel_injection;
> }
> 
> > 2. 'ON' is set by VT-d hardware, it can be set even when interrupt is 
> > disabled
> (the related bit in PIR is also set).
> 
> Yes, we are checking if the HW has set an interrupt in PIR while
> outside VM (which requires PIR->VIRR transfer by software).
> 
> If the interrupt it set by hardware after local_irq_disable(),
> VMX-entry will handle the interrupt and perform the PIR->VIRR
> transfer and reevaluate interrupts, injecting to guest
> if necessary, is that correct ?
> 
> > So does it make sense to check 'ON' and set KVM_REQ_EVENT accordingly
> after interrupt is disabled?
> 
> To replace the costly
> 
> +*/
> +   if (kvm_x86_ops->hwapic_irr_update)
> +   kvm_x86_ops->hwapic_irr_update(vcpu,
> +   kvm_lapic_find_highest_irr(vcpu));
> 
> Yes, i think so.

After adding the "checking ON and setting KVM_REQ_EVENT" operations listed in my
comments above, do you mean we still need to keep the costly code above
inside "if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {}" in 
function
vcpu_enter_guest() as it used to be? If yes, my question is what is the exact 
purpose
of "checking ON and setting KVM_REQ_EVENT" operations? Here is the code flow in
vcpu_enter_guest():

1. Check KVM_REQ_EVENT, if it is set, sync pir->virr
2. Disable interrupts
3. Check ON and set KVM_REQ_EVENT -- Here, we set KVM_REQ_EVENT, but it is
checked in the step 1, which means, we cannot get any benefits even we set it 
here,
since the "pir->virr" sync operation was done in step 1, between step 3 and 
VM-Entry,
we don't synchronize the pir to virr. So even we set KVM_REQ_EVENT here, the 
interrupts
remaining in PIR cannot be delivered to guest during this VM-Entry, right?

Thanks,
Feng

> 
> > I might miss something in your comments, if so please point out. Thanks a
> lot!
> >
> > Thanks,
> > Feng
> >
> > >
> > > >
> > > > "if (kvm_x86_ops->hwapic_irr_update)
> > > > kvm_x86_ops->hwapic_irr_update(vcpu,
> > > > kvm_lapic_find_highest_irr(vcpu));
> > > >
> > > > > kvm_lapic_find_highest_irr(vcpu) eats some cache
> > > > > (4 cachelines) versus 1 cacheline for reading ON bit.
> > > > >
> > > > > > > > > Please remove blocked and wakeup_cpu, they should not be
> > > necessary.
> > > > > > > >
> > > > > > > > Why do you think wakeup_cpu is not needed, when vCPU is
> blocked,
> > > > > > > > wakeup_cpu saves the cpu which the vCPU is blocked on, after
> vCPU
> > > > > > > > is woken up, it can run on a different cpu, so we need 
> > > > > > > > wakeup_cpu
> to
> > > > > > > > find the right list to wake up the vCPU.
> > > > > > >
> > > > > > > If the vCPU was 

Re: arm/ksm: Unable to handle kernel paging request in get_ksm_page() and ksm_scan_thread()

[Hugh Dickins]

On Mon, 30 Mar 2015, Xishi Qiu wrote:
> On 2015/3/30 9:46, Xishi Qiu wrote:
> > On 2015/3/30 8:43, Hugh Dickins wrote:
> >> On Sat, 28 Mar 2015, Xishi Qiu wrote:
> >>> On 2015/3/26 21:23, Xishi Qiu wrote:
> >>>
>  Here are two panic logs from smart phone test, and the kernel version is 
>  v3.10.
> 
>  log1 is "Unable to handle kernel paging request at virtual address 
>  c0704da020", it should be ffc0704da020, right?
> >>
> >> That one was an oops at get_ksm_page+0x34/0x150: I'm pretty sure that
> >> comes from the "kpfn = ACCESS_ONCE(stable_node->kpfn)" line, that the
> >> stable_node pointer (in x21 or x22) has upper bits cleared; which
> >> suggests corruption of the rmap_item supposed to point to it.
> >>
> >> get_ksm_page() is tricky with ACCESS_ONCEs against page migration,
> >> and the structures tricky with unions; but pointers overlay pointers
> >> in those unions, I don't see any way we might pick up an address with
> >> the upper 24 or 32 bits cleared due to that.
> >>
>  and log2 is "Unable to handle kernel paging request at virtual address 
>  1e000796", it should be ffc01e000796, right?
> >>
> >> And this one was an oops at ksm_scan_thread+0x4ac/0xce0; as is the oops
> >> you posted below.  Which contains lots of hex numbers, but very little
> >> info I can work from.
> >>
> >> Please make a CONFIG_DEBUG_INFO=y build of one of the kernels you're
> >> hitting this with, then use the disassembler (objdump -ld perhaps) to
> >> identify precisely which line of ksm.c that is oopsing on: the compiler
> >> will have inlined more interesting functions into ksm_scan_thread, so
> >> I haven't a clue where it's actually oopsing.
> >>
> >> Maybe we'll find that it's also oopsing on a kernel virtual address
> >> from an rmap_item, maybe we won't.
> >>
> >> And I don't read arm64 assembler at all, so I shall be rather limited
> >> in what I can tell you, I'm afraid.
> >>
> 
>  I cann't repeat the panic by test, so could anyone tell me this is the 
>  bug of ksm or other reason?
> >>
> >> I've not heard of any problem like this with KSM on other architectures.
> >> Maybe it is making some assumption which is invalid on arm64, but I'd
> >> have thought we'd have heard about that before now.  My guess is that
> >> something in your kernel is stamping on KSM's structures.
> >>
> >> A relevant experiment (after identifying the oops line in your current
> >> kernel) might be to switch from CONFIG_SLAB=y to CONFIG_SLUB=y or vice
> >> versa.  I doubt SLAB or SLUB is to blame, but changing allocator might
> >> shake things up in a way that either hides the problem, or shifts it
> >> elsewhere.
> >>
> >> Hugh
> >>
> > 
> > Hi Hugh,
> > 
> > Thanks for your reply. There are 3 cases as follows, at first I think maybe
> > something causes the oops, but all of the cases are relevant to "rmap_item",
> > so I have no idea.
> > 
> > 1. ksm_scan_thread+0xa88/0xce0 -> unstable_tree_search_insert() -> 
> > tree_rmap_item = rb_entry(*new, struct rmap_item, node);
> > 
> > 2. ksm_scan_thread+0x4ac/0xce0 -> get_next_rmap_item() -> if 
> > ((rmap_item->address & PAGE_MASK) == addr)
> > 
> > 3. get_ksm_page+0x34/0x150 -> get_ksm_page() -> kpfn = 
> > ACCESS_ONCE(stable_node->kpfn);

So, something is zeroing bytes inside a struct rmap_item.
I say bytes because the pointer in your third dump was ff00
when it should have been a good struct rmap_item *rmap_list.
But I have no idea what, I'm afraid.

There has to be some reason it's struct rmap_item that's vulnerable;
but I haven't spotted a likely culprit in ksm.c.

If you're using CONFIG_SLUB=y, then "slabinfo -a | grep ksm_rmap_item"
would show what is sharing the same cache as the rmap_items, which may
suggest somewhere to look.  (slabinfo comes from tools/vm/slabinfo.c;
I think cache merging has been extended from SLUB to SLAB in later
kernels, but not in v3.10.)

As I said before, it is worth switching SLAB<->SLUB, just to see
what if any difference that makes.  Or are you using SLOB (that
might be significant)?  If so, please try SLUB or SLAB.

> > 
> > Thanks,
> > Xishi Qiu
> > 
> 
> The kernel is v3.10.59

3.10.61-gxxx-dirty is what your dumps show, but perhaps you know
that -gxxx-dirty is taking it back to v3.10.59.

I'd like to think that you've run this test on other kernels, and can
therefore bisect to find where it goes wrong; but suspect I'll be
disappointed to learn this is the first you've tried.

Sorry, no ideas.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: vf610: fix missing irqs

[Shawn Guo]

On Fri, Mar 27, 2015 at 01:04:41PM +0100, Stefan Agner wrote:
> While adding the MSCM interrupt router, all interrupts have been moved
> to vfxxx.dtsi again. However, some properties got lost. Readd the
> missing interrupt properties.
> 
> Fixes: 97e6466ab9d0 ("ARM: dts: vf610: add Miscellaneous System Control 
> Module (MSCM)")
> Signed-off-by: Stefan Agner 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

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

drivers/net/usb/cdc_ncm.c: In function 'cdc_ncm_fill_tx_frame':
drivers/net/usb/cdc_ncm.c:1187:2: error: too few arguments to function 
'usbnet_set_skb_tx_stats'
  usbnet_set_skb_tx_stats(skb_out, n);
  ^
In file included from drivers/net/usb/cdc_ncm.c:51:0:
include/linux/usb/usbnet.h:238:1: note: declared here
 usbnet_set_skb_tx_stats(struct sk_buff *skb,
 ^

Caused by a bad merge between commits 1e9e39f4a298 ("usbnet: Fix
tx_packets stat for FLAG_MULTI_FRAME drivers") and 7a1e890e2168
("usbnet: Fix tx_bytes statistic running backward in cdc_ncm") form the
net tree and commit 6588af614e7b ("usbnet: Fix tx_packets stat for
FLAG_MULTI_FRAME drivers") from the net-next tree.  (Presumably,
6588af614e7b was cherry-picked as a bug fix.  So, Dave, something to
watch for if you merge net into net-next.)

I applied the following merge fix patch:

From: Stephen Rothwell 
Date: Mon, 30 Mar 2015 14:59:49 +1100
Subject: [PATCH] usbnet: fix bad merge in cdc_ncm.c

Signed-off-by: Stephen Rothwell 
---
 drivers/net/usb/cdc_ncm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index ee6fed0af6f5..c3e4da9e79ca 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1184,8 +1184,6 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff 
*skb, __le32 sign)
usbnet_set_skb_tx_stats(skb_out, n,
ctx->tx_curr_frame_payload - skb_out->len);
 
-   usbnet_set_skb_tx_stats(skb_out, n);
-
return skb_out;
 
 exit_no_skb:
-- 
2.1.4

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpf517a0X_C3.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 1/1] dts: cubox: Map gpio-keys to gpio3 8

[Shawn Guo]

On Tue, Mar 24, 2015 at 10:31:35AM -0600, George Joseph wrote:
> The Cubox has a recessed button between the HDMI and RJ-45 connectors
> that wasn't mapped in the device tree, so I've mapped it to gpio-keys
> BTN_0.
> 
> Signed-off-by: George Joseph 
> Tested-by: George Joseph 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 00/10] tracing: Use TRACE_DEFINE_ENUM() to show enum values

[Masami Hiramatsu]

(2015/03/28 6:37), Steven Rostedt wrote:
> As there are many tracepoints that use __print_symbolic() to translate
> numbers into ASCII strings, and several of these translate enums as
> well, it causes a problem for user space tools that read the tracepoint
> format files and have to translate the binary data to their associated
> strings.
> 
> For example, with the tlb_flush tracepoint, we have this in the format
> file:
> 
> print fmt: "pages:%ld reason:%s (%d)", REC->pages,
>  __print_symbolic(REC->reason,
>{ TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" },
>{ TLB_REMOTE_SHOOTDOWN, "remote shootdown" },
>{ TLB_LOCAL_SHOOTDOWN, "local shootdown" },
>{ TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" }), REC->reason

Hmm, would user-space application really need to know the symbol name of enums?
If not, the event format files would better export the number(value) instead of
the enum name, like below.

 print fmt: "pages:%ld reason:%s (%d)", REC->pages,
  __print_symbolic(REC->reason,
{ 0, "flush on task switch" },
{ 1, "remote shootdown" },
{ 2, "local shootdown" },
{ 3, "local mm shootdown" }), REC->reason

I'm still not sure how we can code it :( (It seems that some trick we need when
showing the print fmt.)

> 
> Now, userspace does not know what the value of TLB_REMOTE_SHOOTDOWN is.
> To solve this, a new macro is created as a helper to allow tracepoints
> to export enums they use to userspace. This macro is called,
> TRACE_DEFINE_ENUM(), such that
> 
>  TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN);
> 
> Will export the TLB_REMOTE_SHOOTDOWN enum to use space.
> 
> How that is done is with a new file in the debugfs tracing directory.
> 
>  # cat /sys/kernel/debug/tracing/enum_map
> TLB_LOCAL_MM_SHOOTDOWN 3
> TLB_LOCAL_SHOOTDOWN 2
> TLB_REMOTE_SHOOTDOWN 1
> TLB_FLUSH_ON_TASK_SWITCH 0

BTW, if we can show the enum_map, can we also show the "symbolic" map
instead of using the __print_symbolic() ? :)

Thank you,

> 
> Now userspace, when seeing TLB_REMOTE_SHOOTDOWN in the format, knows
> that represents "1", and can do the conversions properly.
> 
> 
> Local SHA1: 6115e48a506e738f0f24771b4c87e4ba90d3d1c2
> 
> 
> Steven Rostedt (Red Hat) (10):
>   tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values
>   tracing: Allow for modules to export their trace enums as well
>   x86/tlb/trace: Export enums in used by tlb_flush tracepoint
>   net/9p/tracing: Export enums in tracepoints to userspace
>   f2fs: Export the enums in the tracepoints to userspace
>   irq/tracing: Export enums in tracepoints to user space
>   mm: tracing: Export enums in tracepoints to user space
>   SUNRPC: Export enums in tracepoints to user space
>   v4l: Export enums used by tracepoints to user space
>   writeback: Export enums used by tracepoint to user space
> 
> 
>  include/asm-generic/vmlinux.lds.h |   5 +-
>  include/linux/module.h|   2 +
>  include/linux/tracepoint.h|   7 +
>  include/trace/events/9p.h | 157 +--
>  include/trace/events/f2fs.h   |  21 +++
>  include/trace/events/irq.h|  39 --
>  include/trace/events/migrate.h|  42 --
>  include/trace/events/sunrpc.h |  62 ++---
>  include/trace/events/tlb.h|  30 -
>  include/trace/events/v4l2.h   |  75 +++
>  include/trace/events/writeback.h  |  33 +++--
>  include/trace/ftrace.h|  11 ++
>  kernel/module.c   |   3 +
>  kernel/trace/trace.c  | 260 
> +-
>  14 files changed, 598 insertions(+), 149 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the net-next tree with the vfs tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/socket.c between commit 774157aa4897 ("net: switch importing msghdr
from userland to {compat_,}import_iovec()") from the vfs tree and
commit 0345f93138b2 ("net: socket: add support for async operations")
from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc net/socket.c
index abc721654ab5,073809f4125f..
--- a/net/socket.c
+++ b/net/socket.c
@@@ -841,11 -808,10 +794,10 @@@ static ssize_t sock_read_iter(struct ki
if (iocb->ki_pos != 0)
return -ESPIPE;
  
 -  if (iocb->ki_nbytes == 0)   /* Match SYS5 behaviour */
 +  if (!iov_iter_count(to))/* Match SYS5 behaviour */
return 0;
  
-   res = __sock_recvmsg(iocb, sock, ,
-iov_iter_count(to), msg.msg_flags);
 -  res = sock_recvmsg(sock, , iocb->ki_nbytes, msg.msg_flags);
++  res = sock_recvmsg(sock, , iov_iter_count(to), msg.msg_flags);
*to = msg.msg_iter;
return res;
  }
@@@ -866,7 -833,7 +819,7 @@@ static ssize_t sock_write_iter(struct k
if (sock->type == SOCK_SEQPACKET)
msg.msg_flags |= MSG_EOR;
  
-   res = __sock_sendmsg(iocb, sock, , iov_iter_count(from));
 -  res = sock_sendmsg(sock, , iocb->ki_nbytes);
++  res = sock_sendmsg(sock, , iov_iter_count(from));
*from = msg.msg_iter;
return res;
  }
@@@ -1921,8 -1896,15 +1874,10 @@@ static int copy_msghdr_from_user(struc
if (nr_segs > UIO_MAXIOV)
return -EMSGSIZE;
  
+   kmsg->msg_iocb = NULL;
+ 
 -  err = rw_copy_check_uvector(save_addr ? READ : WRITE,
 -  uiov, nr_segs,
 -  UIO_FASTIOV, *iov, iov);
 -  if (err >= 0)
 -  iov_iter_init(>msg_iter, save_addr ? READ : WRITE,
 -*iov, nr_segs, err);
 -  return err;
 +  return import_iovec(save_addr ? READ : WRITE, uiov, nr_segs,
 +  UIO_FASTIOV, iov, >msg_iter);
  }
  
  static int ___sys_sendmsg(struct socket *sock, struct user_msghdr __user *msg,


pgpP7KeplIfAx.pgp
Description: OpenPGP digital signature

Re: [PATCH] fs: btrfs: Add missing include file

[Guenter Roeck]

On Fri, Mar 13, 2015 at 01:58:46AM -0700, Guenter Roeck wrote:
> Building alpha:allmodconfig fails with
> 
> fs/btrfs/inode.c: In function 'check_direct_IO':
> fs/btrfs/inode.c:8050:2: error: implicit declaration of function 
> 'iov_iter_alignment'
> 
> due to a missing include file.
> 
> Fixes: 3737c63e1fb0 ("fs: move struct kiocb to fs.h")
> Cc: Christoph Hellwig 
> Signed-off-by: Guenter Roeck 
> ---

This problem still affects the following builds as of today.

alpha:allmodconfig
i386:allyesconfig
i386:allmodconfig
m68k:allmodconfig
mips:allmodconfig
xtensa:allmodconfig

and thus probabably many other allmodconfig builds which I don't try to build.

This is getting really annoying, and prevents us from finding and fixing
other build problems.

It has been more than two weeks since I submitted the patch. This suggests 
that the patch got lost otr that the Powers That Be don't care. Which one
is it ?

Should I request to revert 3737c63e1fb0 instead ?

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] arm64: kdump: do not go into EL2 before starting a crash dump kernel

[AKASHI Takahiro]

On 03/27/2015 07:29 AM, Geoff Levand wrote:

On Thu, 2015-03-26 at 17:28 +0900, AKASHI Takahiro wrote:

@@ -64,7 +65,11 @@ void soft_restart(unsigned long addr)
setup_mm_for_reboot();

cpu_soft_restart(virt_to_phys(cpu_reset),
-   is_hyp_mode_available(), addr);
+#ifdef CONFIG_KEXEC
+   !in_crash_kexec &&
+#endif


Why not define in_crash_kexec without condition on CONFIG_KEXEC, say
here in process.c and then avoid these preprocessor conditionals.


Well, I thought of that, but as its name suggested, the variable should
be basically part of kdump code.
Moreover, I suspect that some one might reject a whole idea of patch #3.

-Takahiro AKASHI


+   is_hyp_mode_available(),
+   addr);

/* Should never get here */
BUG();





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] bpf: Suggestion on bpf syscall interface

[He Kuang]

On 2015/3/29 1:21, Alexei Starovoitov wrote:

On 3/28/15 4:36 AM, He Kuang wrote:

Hi, Alexei

In our end-end IO module project, we use bpf maps to record
configurations. According to current bpf syscall interface, we
should specify map_fd to lookup/update bpf maps, so we are
restricted to do config in the same user program.


you can pass map_fd and prog_fd from one process to another via normal
scm_rights mechanism.


In our current use case, we add a bpf probe point in sys_write()
as the entry of IO procedure, this bpf point will return true on
some conditions, and then trigger bpf chain on IO path, for
example:

SEC("kprobe/sys_write")
int NODE_sys_write(struct pt_regs *ctx) {
...
   struct parameters *param = bpf_map_lookup_elem(_map, 
);

   if(param->num_samples % param->sample_rate !=0)
   return 0;
...
   /* extract characters from this sampled point, fill it to another 
map */
   bpf_map_update_elem(_mpage_submit_page_HASH, 
(void**)__b__buf, , BPF_ANY);

   return 1;
...
SEC("kprobe/mpage_submit_page")
int NODE_mpage_submit_page(struct pt_regs *ctx) {
...
  /* lookup filter table */
  value = (struct 
table_value*)bpf_map_lookup_elem(_mpage_submit_page_HASH, 
(void**)__b__buf);

  if (!value) return 0;
...

By using current bpf syscalls, we should keep the program which
attaches bpf programs running background, use it or some other
processes communicate with it to adjust maps parameters, like
sample rate for sys_write.

What we hope is to use bpf maps/progs like kernel-modules or
kprobes, one process inserts them to kernel, then they detactch
from that process, and allow us to configure them with sysfs. For
example:

$ perf probe --add='sys_write'
$ perf record -e probe:sys_open -aR sleep 1

In current implementation, we have to use a large and relative
heavy daemon to deal with loading, configuration, adjusting and
unloading works together.

Thanks.



My suggestion is to export this kind of operations to sysfs, so
we can load bpf progs and config it seperately. We
implement this feature in our demo project. What's your opinion
on this?


Eventually we may use single sysfs file for lsmod-like listings, but I
definitely don't want to create parallel interface to maps via sysfs.
It's way too expensive and not really suitable for binary key/values.







--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] sched: Add cpu based entries to debugfs

[Mike Galbraith]

Oh, you can add /proc/sys/kernel/sched_domain diddling to the hotplug
todo... which will either create read /sys, poke modify buttons over
yonder in /proc situation, or have to duplicate that.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: arm/ksm: Unable to handle kernel paging request in get_ksm_page() and ksm_scan_thread()

[Xishi Qiu]

On 2015/3/30 9:46, Xishi Qiu wrote:

> On 2015/3/30 8:43, Hugh Dickins wrote:
> 
>> On Sat, 28 Mar 2015, Xishi Qiu wrote:
>>> On 2015/3/26 21:23, Xishi Qiu wrote:
>>>
 Here are two panic logs from smart phone test, and the kernel version is 
 v3.10.

 log1 is "Unable to handle kernel paging request at virtual address 
 c0704da020", it should be ffc0704da020, right?
>>
>> That one was an oops at get_ksm_page+0x34/0x150: I'm pretty sure that
>> comes from the "kpfn = ACCESS_ONCE(stable_node->kpfn)" line, that the
>> stable_node pointer (in x21 or x22) has upper bits cleared; which
>> suggests corruption of the rmap_item supposed to point to it.
>>
>> get_ksm_page() is tricky with ACCESS_ONCEs against page migration,
>> and the structures tricky with unions; but pointers overlay pointers
>> in those unions, I don't see any way we might pick up an address with
>> the upper 24 or 32 bits cleared due to that.
>>
 and log2 is "Unable to handle kernel paging request at virtual address 
 1e000796", it should be ffc01e000796, right?
>>
>> And this one was an oops at ksm_scan_thread+0x4ac/0xce0; as is the oops
>> you posted below.  Which contains lots of hex numbers, but very little
>> info I can work from.
>>
>> Please make a CONFIG_DEBUG_INFO=y build of one of the kernels you're
>> hitting this with, then use the disassembler (objdump -ld perhaps) to
>> identify precisely which line of ksm.c that is oopsing on: the compiler
>> will have inlined more interesting functions into ksm_scan_thread, so
>> I haven't a clue where it's actually oopsing.
>>
>> Maybe we'll find that it's also oopsing on a kernel virtual address
>> from an rmap_item, maybe we won't.
>>
>> And I don't read arm64 assembler at all, so I shall be rather limited
>> in what I can tell you, I'm afraid.
>>

 I cann't repeat the panic by test, so could anyone tell me this is the 
 bug of ksm or other reason?
>>
>> I've not heard of any problem like this with KSM on other architectures.
>> Maybe it is making some assumption which is invalid on arm64, but I'd
>> have thought we'd have heard about that before now.  My guess is that
>> something in your kernel is stamping on KSM's structures.
>>
>> A relevant experiment (after identifying the oops line in your current
>> kernel) might be to switch from CONFIG_SLAB=y to CONFIG_SLUB=y or vice
>> versa.  I doubt SLAB or SLUB is to blame, but changing allocator might
>> shake things up in a way that either hides the problem, or shifts it
>> elsewhere.
>>
>> Hugh
>>
> 
> Hi Hugh,
> 
> Thanks for your reply. There are 3 cases as follows, at first I think maybe
> something causes the oops, but all of the cases are relevant to "rmap_item",
> so I have no idea.
> 
> 1. ksm_scan_thread+0xa88/0xce0 -> unstable_tree_search_insert() -> 
> tree_rmap_item = rb_entry(*new, struct rmap_item, node);
> 
> 2. ksm_scan_thread+0x4ac/0xce0 -> get_next_rmap_item() -> if 
> ((rmap_item->address & PAGE_MASK) == addr)
> 
> 3. get_ksm_page+0x34/0x150 -> get_ksm_page() -> kpfn = 
> ACCESS_ONCE(stable_node->kpfn);
> 
> Thanks,
> Xishi Qiu
> 

The kernel is v3.10.59

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> .
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the net-next tree with the vfs tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/compat.c between commit 774157aa4897 ("net: switch importing msghdr
from userland to {compat_,}import_iovec()") from the vfs tree and
commit 0345f93138b2 ("net: socket: add support for async operations")
from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc net/compat.c
index 0e34814592e6,c4b6b0f43d5d..
--- a/net/compat.c
+++ b/net/compat.c
@@@ -79,9 -79,15 +79,11 @@@ int get_compat_msghdr(struct msghdr *km
if (nr_segs > UIO_MAXIOV)
return -EMSGSIZE;
  
+   kmsg->msg_iocb = NULL;
+ 
 -  err = compat_rw_copy_check_uvector(save_addr ? READ : WRITE,
 - compat_ptr(uiov), nr_segs,
 - UIO_FASTIOV, *iov, iov);
 -  if (err >= 0)
 -  iov_iter_init(>msg_iter, save_addr ? READ : WRITE,
 -*iov, nr_segs, err);
 -  return err;
 +  return compat_import_iovec(save_addr ? READ : WRITE,
 + compat_ptr(uiov), nr_segs,
 + UIO_FASTIOV, iov, >msg_iter);
  }
  
  /* Bleech... */


pgpaD8eYaliVO.pgp
Description: OpenPGP digital signature

Re: [RFC][PATCH 02/10] tracing: Allow for modules to export their trace enums as well

[Rusty Russell]

Steven Rostedt  writes:

> From: "Steven Rostedt (Red Hat)" 
>
> Update the infrastructure such that modules that declare TRACE_DEFINE_ENUM()
> will have those enums shown in the enum_map files in the tracing directory.
>
> Cc: Rusty Russell 
> Signed-off-by: Steven Rostedt 

Acked-by: Rusty Russell 

Cheers,
Rusty.

> ---
>  include/linux/module.h |   2 +
>  kernel/module.c|   3 +
>  kernel/trace/trace.c   | 184 
> -
>  3 files changed, 173 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 42999fe2dbd0..53dc41dd5c62 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -338,6 +338,8 @@ struct module {
>  #ifdef CONFIG_EVENT_TRACING
>   struct ftrace_event_call **trace_events;
>   unsigned int num_trace_events;
> + struct trace_enum_map **trace_enums;
> + unsigned int num_trace_enums;
>  #endif
>  #ifdef CONFIG_FTRACE_MCOUNT_RECORD
>   unsigned int num_ftrace_callsites;
> diff --git a/kernel/module.c b/kernel/module.c
> index b3d634ed06c9..d8f8ab271c2b 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2753,6 +2753,9 @@ static int find_module_sections(struct module *mod, 
> struct load_info *info)
>   mod->trace_events = section_objs(info, "_ftrace_events",
>sizeof(*mod->trace_events),
>>num_trace_events);
> + mod->trace_enums = section_objs(info, "_ftrace_enum_map",
> + sizeof(*mod->trace_enums),
> + >num_trace_enums);
>  #endif
>  #ifdef CONFIG_TRACING
>   mod->trace_bprintk_fmt_start = section_objs(info, "__trace_printk_fmt",
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 53b449c522a7..97031878eb3d 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -124,7 +124,38 @@ enum ftrace_dump_mode ftrace_dump_on_oops;
>  int __disable_trace_on_warning;
>  
>  /* Map of enums to their values, for "enum_map" file */
> -static struct trace_enum_map *trace_enum_maps;
> +struct trace_enum_map_head {
> + struct module   *mod;
> + unsigned long   length;
> +};
> +
> +union trace_enum_map_item;
> +
> +struct trace_enum_map_tail {
> + /*
> +  * "end" is first and points to NULL as it must be different
> +  * than "mod" or "enum_string"
> +  */
> + const char  *end;   /* points to NULL */
> + union trace_enum_map_item   *next;
> +};
> +
> +static DEFINE_MUTEX(trace_enum_mutex);
> +
> +/*
> + * The trace_enum_maps are saved in an array whith two extra elements,
> + * one at the beginning, and one at the end. The beginning item contains
> + * the count of the saved maps (head.length), and the module they
> + * belong to if not built in (head.mod). The ending item contains a
> + * pointer to the next array of saved enum_map items.
> + */
> +union trace_enum_map_item {
> + struct trace_enum_map   map;
> + struct trace_enum_map_head  head;
> + struct trace_enum_map_tail  tail;
> +};
> +
> +static union trace_enum_map_item *trace_enum_maps;
>  
>  static int tracing_set_tracer(struct trace_array *tr, const char *buf);
>  
> @@ -3911,29 +3942,47 @@ static const struct file_operations 
> tracing_saved_cmdlines_size_fops = {
>   .write  = tracing_saved_cmdlines_size_write,
>  };
>  
> +static union trace_enum_map_item *
> +update_enum_map(union trace_enum_map_item *ptr)
> +{
> + if (!ptr->map.enum_string) {
> + if (ptr->tail.next) {
> + ptr = ptr->tail.next;
> + ptr++;
> + } else
> + return NULL;
> + }
> + return ptr;
> +}
> +
>  static void *enum_map_next(struct seq_file *m, void *v, loff_t *pos)
>  {
> - struct trace_enum_map *ptr = v;
> + union trace_enum_map_item *ptr = v;
>  
> - if (!ptr->enum_string)
> + ptr = update_enum_map(ptr);
> + if (!ptr)
>   return NULL;
>  
>   ptr++;
>  
>   (*pos)++;
>  
> - if (!ptr->enum_string)
> - return NULL;
> + ptr = update_enum_map(ptr);
>  
>   return ptr;
>  }
>  
>  static void *enum_map_start(struct seq_file *m, loff_t *pos)
>  {
> - struct trace_enum_map *v;
> + union trace_enum_map_item *v;
>   loff_t l = 0;
>  
> + mutex_lock(_enum_mutex);
> +
>   v = trace_enum_maps;
> + if (v)
> + v++;
> +
>   while (v && l < *pos) {
>   v = enum_map_next(m, v, );
>   }
> @@ -3943,13 +3992,15 @@ static void *enum_map_start(struct seq_file *m, 
> loff_t *pos)
>  
>  static void enum_map_stop(struct seq_file *m, void *v)
>  {
> + mutex_unlock(_enum_mutex);
>  }
>  
>  static int enum_map_show(struct seq_file *m, void *v)
>  {
> - struct trace_enum_map *ptr = v;
> + union trace_enum_map_item 

Re: [RFC][PATCH 05/10] f2fs: Export the enums in the tracepoints to userspace

[Namhyung Kim]

On Fri, Mar 27, 2015 at 05:37:09PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)" 
> 
> The tracepoints that use __print_symbolic() use enums as the value
> to convert to strings. Unfortunately, the format files for these
> tracepoints show the enum name and not their value. This causes some
> userspace tools not to know how to convert __print_symbolic() to
> their strings.
> 
> Add TRACE_DEFINE_ENUM() macros to export the enums used to userspace
> to let those tools know what those enum values are.
> 
> Cc: Namjae Jeon 
> Cc: Pankaj Kumar 
> Cc: Jaegeuk Kim 

AFAIK Jaegeuk's samsung email is not valid anymore..

  $ grep -a Jaegeuk MAINTAINERS
  M:  Jaegeuk Kim 


Thanks,
Namhyung


> Signed-off-by: Steven Rostedt 
> ---
>  include/trace/events/f2fs.h | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h
> index 5422dbfaf97d..a0074dd8d140 100644
> --- a/include/trace/events/f2fs.h
> +++ b/include/trace/events/f2fs.h
> @@ -9,6 +9,27 @@
>  #define show_dev(entry)  MAJOR(entry->dev), MINOR(entry->dev)
>  #define show_dev_ino(entry)  show_dev(entry), (unsigned long)entry->ino
>  
> +TRACE_DEFINE_ENUM(NODE);
> +TRACE_DEFINE_ENUM(DATA);
> +TRACE_DEFINE_ENUM(META_FLUSH);
> +TRACE_DEFINE_ENUM(CURSEG_HOT_DATA);
> +TRACE_DEFINE_ENUM(CURSEG_WARM_DATA);
> +TRACE_DEFINE_ENUM(CURSEG_COLD_DATA);
> +TRACE_DEFINE_ENUM(CURSEG_HOT_NODE);
> +TRACE_DEFINE_ENUM(CURSEG_WARM_NODE);
> +TRACE_DEFINE_ENUM(CURSEG_COLD_NODE);
> +TRACE_DEFINE_ENUM(NO_CHECK_TYPE);
> +TRACE_DEFINE_ENUM(GC_GREEDY);
> +TRACE_DEFINE_ENUM(GC_CB);
> +TRACE_DEFINE_ENUM(__REQ_RAHEAD);
> +TRACE_DEFINE_ENUM(__REQ_WRITE);
> +TRACE_DEFINE_ENUM(__REQ_SYNC);
> +TRACE_DEFINE_ENUM(__REQ_NOIDLE);
> +TRACE_DEFINE_ENUM(__REQ_FLUSH);
> +TRACE_DEFINE_ENUM(__REQ_FUA);
> +TRACE_DEFINE_ENUM(__REQ_PRIO);
> +TRACE_DEFINE_ENUM(__REQ_META);
> +
>  #define show_block_type(type)
> \
>   __print_symbolic(type,  \
>   { NODE, "NODE" },   \
> -- 
> 2.1.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next 2/2] hv_netvsc: Eliminate memory allocation in the packet send path

[K. Y. Srinivasan]

The network protocol used to communicate with the host is the remote ndis 
(rndis)
protocol. We need to decorate each outgoing packet with a rndis header and
additional rndis state (rndis per-packet state). To manage this state, we
currently allocate memory in the transmit path. Eliminate this allocation by
requesting additional head room in the skb.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/net/hyperv/hyperv_net.h   |3 +-
 drivers/net/hyperv/netvsc.c   |   10 --
 drivers/net/hyperv/netvsc_drv.c   |   67 +++--
 drivers/net/hyperv/rndis_filter.c |2 +
 4 files changed, 60 insertions(+), 22 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 384f057..309adee 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -128,6 +128,7 @@ struct ndis_tcp_ip_checksum_info;
 struct hv_netvsc_packet {
/* Bookkeeping stuff */
u32 status;
+   bool part_of_skb;
 
struct hv_device *device;
bool is_data_pkt;
@@ -150,7 +151,7 @@ struct hv_netvsc_packet {
/* Points to the send/receive buffer where the ethernet frame is */
void *data;
u32 page_buf_cnt;
-   struct hv_page_buffer page_buf[0];
+   struct hv_page_buffer *page_buf;
 };
 
 struct netvsc_device_info {
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index ecbd813..f699236 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -866,11 +866,15 @@ int netvsc_send(struct hv_device *device,
netvsc_copy_to_send_buf(net_device,
section_index, msd_len,
packet);
-   skb = (struct sk_buff *)
-  (unsigned long)packet->send_completion_tid;
+   if (!packet->part_of_skb) {
+   skb = (struct sk_buff *)
+   (unsigned long)
+   packet->send_completion_tid;
+
+   packet->send_completion_tid = 0;
+   }
 
packet->page_buf_cnt = 0;
-   packet->send_completion_tid = 0;
packet->send_buf_index = section_index;
packet->total_data_buflen += msd_len;
 
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 75beb89..f9db6bc 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -235,7 +235,8 @@ static void netvsc_xmit_completion(void *context)
struct sk_buff *skb = (struct sk_buff *)
(unsigned long)packet->send_completion_tid;
 
-   kfree(packet);
+   if (!packet->part_of_skb)
+   kfree(packet);
 
if (skb)
dev_kfree_skb_any(skb);
@@ -383,6 +384,9 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct 
net_device *net)
u32 net_trans_info;
u32 hash;
u32 skb_length = skb->len;
+   u32 head_room = skb_headroom(skb);
+   u32 pkt_sz;
+   struct hv_page_buffer page_buf[MAX_PAGE_BUFFER_COUNT];
 
 
/* We will atmost need two pages to describe the rndis
@@ -397,24 +401,32 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct 
net_device *net)
return NETDEV_TX_OK;
}
 
-   /* Allocate a netvsc packet based on # of frags. */
-   packet = kzalloc(sizeof(struct hv_netvsc_packet) +
-(num_data_pgs * sizeof(struct hv_page_buffer)) +
-sizeof(struct rndis_message) +
-NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
-NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE, GFP_ATOMIC);
-   if (!packet) {
-   /* out of memory, drop packet */
-   netdev_err(net, "unable to allocate hv_netvsc_packet\n");
-
-   dev_kfree_skb(skb);
-   net->stats.tx_dropped++;
-   return NETDEV_TX_OK;
+   pkt_sz = sizeof(struct hv_netvsc_packet) +
+   sizeof(struct rndis_message) +
+   NDIS_VLAN_PPI_SIZE + NDIS_CSUM_PPI_SIZE +
+   NDIS_LSO_PPI_SIZE + NDIS_HASH_PPI_SIZE;
+
+   if (head_room < pkt_sz) {
+   packet = kmalloc(pkt_sz, GFP_ATOMIC);
+   if (!packet) {
+   /* out of memory, drop packet */
+   netdev_err(net, "unable to alloc hv_netvsc_packet\n");
+   dev_kfree_skb(skb);
+   net->stats.tx_dropped++;
+   return NETDEV_TX_OK;
+   }
+   packet->part_of_skb = false;
+   } else {
+   /* Use the headroom for building up the packet */
+   packet = (struct hv_netvsc_packet *)skb->head;
+   packet->part_of_skb = true;
}
 
+   packet->status = 0;
packet->xmit_more = skb->xmit_more;
 

[PATCH net-next 1/2] hv_netvsc: Cleanup the test for freeing skb when we use sendbuf mechanism

[K. Y. Srinivasan]

In preparation for embedding the rndis state and other packet state into
the skb, cleanup the test for freeing the skb.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/net/hyperv/netvsc.c |1 +
 drivers/net/hyperv/netvsc_drv.c |3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index b81bd37..ecbd813 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -870,6 +870,7 @@ int netvsc_send(struct hv_device *device,
   (unsigned long)packet->send_completion_tid;
 
packet->page_buf_cnt = 0;
+   packet->send_completion_tid = 0;
packet->send_buf_index = section_index;
packet->total_data_buflen += msd_len;
 
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 0c99818..75beb89 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -234,11 +234,10 @@ static void netvsc_xmit_completion(void *context)
struct hv_netvsc_packet *packet = (struct hv_netvsc_packet *)context;
struct sk_buff *skb = (struct sk_buff *)
(unsigned long)packet->send_completion_tid;
-   u32 index = packet->send_buf_index;
 
kfree(packet);
 
-   if (skb && (index == NETVSC_INVALID_INDEX))
+   if (skb)
dev_kfree_skb_any(skb);
 }
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next 0/2] hv_netvsc: Eliminate memory allocation in the send path

[K. Y. Srinivasan]

The network protocol used to communicate with the host is the remote ndis 
(rndis)
protocol. We need to decorate each outgoing packet with a rndis header and
additional rndis state (rndis per-packet state). To manage this state, we
currently allocate memory in the transmit path. Eliminate this allocation by
requesting additional head room in the skb.


K. Y. Srinivasan (2):
  hyperv: Cleanup the test for freeing skb when we use sendbuf
mechanism
  hyperv: Eliminate memory allocation in the packet send path

 drivers/net/hyperv/hyperv_net.h   |3 +-
 drivers/net/hyperv/netvsc.c   |9 -
 drivers/net/hyperv/netvsc_drv.c   |   70 ++--
 drivers/net/hyperv/rndis_filter.c |2 +
 4 files changed, 61 insertions(+), 23 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] sched: Add cpu based entries to debugfs

[David Ahern]

On 3/29/15 8:32 PM, Mike Galbraith wrote:

On Sun, 2015-03-29 at 22:13 -0400, David Ahern wrote:


diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 62671f53202a..b4d8d0c8260e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -268,12 +268,173 @@ static const struct file_operations sched_feat_fops = {
.release= single_release,
  };

+static const char * const sd_flag_names[] = {
+   "load-balance",
+   "new-idle",
+   "exec",
+   "fork",
+   "wake",
+   "affine",
+   "",
+   "cpu-capacity",
+   "power-domain",
+   "share-pkg-resources",
+   "serialize",
+   "asym-packing",
+   "prefer-sibling",
+   "overlap",
+   "numa",
+   "",
+};


That's wrong with the names readers will want to grep for?


I just found lower-case easier on the eyes. I could change this list to 
correspond to the SD_X defines. Certainly something that more 
programmatically correlates the macros (bit positions) and the names 
would be better.


David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 02/10] tracing: Allow for modules to export their trace enums as well

[Namhyung Kim]

On Fri, Mar 27, 2015 at 05:37:06PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)" 
> 
> Update the infrastructure such that modules that declare TRACE_DEFINE_ENUM()
> will have those enums shown in the enum_map files in the tracing directory.
> 
> Cc: Rusty Russell 
> Signed-off-by: Steven Rostedt 
> ---
>  include/linux/module.h |   2 +
>  kernel/module.c|   3 +
>  kernel/trace/trace.c   | 184 
> -
>  3 files changed, 173 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 42999fe2dbd0..53dc41dd5c62 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -338,6 +338,8 @@ struct module {
>  #ifdef CONFIG_EVENT_TRACING
>   struct ftrace_event_call **trace_events;
>   unsigned int num_trace_events;
> + struct trace_enum_map **trace_enums;
> + unsigned int num_trace_enums;
>  #endif
>  #ifdef CONFIG_FTRACE_MCOUNT_RECORD
>   unsigned int num_ftrace_callsites;
> diff --git a/kernel/module.c b/kernel/module.c
> index b3d634ed06c9..d8f8ab271c2b 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2753,6 +2753,9 @@ static int find_module_sections(struct module *mod, 
> struct load_info *info)
>   mod->trace_events = section_objs(info, "_ftrace_events",
>sizeof(*mod->trace_events),
>>num_trace_events);
> + mod->trace_enums = section_objs(info, "_ftrace_enum_map",
> + sizeof(*mod->trace_enums),
> + >num_trace_enums);
>  #endif
>  #ifdef CONFIG_TRACING
>   mod->trace_bprintk_fmt_start = section_objs(info, "__trace_printk_fmt",
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 53b449c522a7..97031878eb3d 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -124,7 +124,38 @@ enum ftrace_dump_mode ftrace_dump_on_oops;
>  int __disable_trace_on_warning;
>  
>  /* Map of enums to their values, for "enum_map" file */
> -static struct trace_enum_map *trace_enum_maps;
> +struct trace_enum_map_head {
> + struct module   *mod;
> + unsigned long   length;
> +};
> +
> +union trace_enum_map_item;
> +
> +struct trace_enum_map_tail {
> + /*
> +  * "end" is first and points to NULL as it must be different
> +  * than "mod" or "enum_string"
> +  */
> + const char  *end;   /* points to NULL */
> + union trace_enum_map_item   *next;
> +};
> +
> +static DEFINE_MUTEX(trace_enum_mutex);
> +
> +/*
> + * The trace_enum_maps are saved in an array whith two extra elements,

s/whith/with/

> + * one at the beginning, and one at the end. The beginning item contains
> + * the count of the saved maps (head.length), and the module they
> + * belong to if not built in (head.mod). The ending item contains a
> + * pointer to the next array of saved enum_map items.
> + */
> +union trace_enum_map_item {
> + struct trace_enum_map   map;
> + struct trace_enum_map_head  head;
> + struct trace_enum_map_tail  tail;
> +};
> +
> +static union trace_enum_map_item *trace_enum_maps;
>  
>  static int tracing_set_tracer(struct trace_array *tr, const char *buf);
>  
> @@ -3911,29 +3942,47 @@ static const struct file_operations 
> tracing_saved_cmdlines_size_fops = {
>   .write  = tracing_saved_cmdlines_size_write,
>  };
>  
> +static union trace_enum_map_item *
> +update_enum_map(union trace_enum_map_item *ptr)
> +{
> + if (!ptr->map.enum_string) {
> + if (ptr->tail.next) {
> + ptr = ptr->tail.next;
> + ptr++;

I guess this additional increment is to skip head item.  Maybe it
deserves a comment. :)


> + } else
> + return NULL;
> + }
> + return ptr;
> +}
> +
>  static void *enum_map_next(struct seq_file *m, void *v, loff_t *pos)
>  {
> - struct trace_enum_map *ptr = v;
> + union trace_enum_map_item *ptr = v;
>  
> - if (!ptr->enum_string)
> + ptr = update_enum_map(ptr);

Again, is this necessary?


> + if (!ptr)
>   return NULL;
>  
>   ptr++;
>  
>   (*pos)++;
>  
> - if (!ptr->enum_string)
> - return NULL;
> + ptr = update_enum_map(ptr);
>  
>   return ptr;
>  }
>  
>  static void *enum_map_start(struct seq_file *m, loff_t *pos)
>  {
> - struct trace_enum_map *v;
> + union trace_enum_map_item *v;
>   loff_t l = 0;
>  
> + mutex_lock(_enum_mutex);
> +
>   v = trace_enum_maps;
> + if (v)
> + v++;
> +
>   while (v && l < *pos) {
>   v = enum_map_next(m, v, );
>   }
> @@ -3943,13 +3992,15 @@ static void *enum_map_start(struct seq_file *m, 
> loff_t *pos)
>  
>  static void enum_map_stop(struct seq_file *m, void *v)
>  {
> + mutex_unlock(_enum_mutex);
>  }
>  
>  

[Bugfix v3] x86/PCI/ACPI: Fix regression caused by commit 63f1789ec716

[Jiang Liu]

Before commit 593669c2ac0f("Use common ACPI resource interfaces to
simplify implementation"), arch/x86/pci/acpi.c applies following
rules when parsing ACPI resources for PCI host bridge:
1) Ignore IO port resources defined by acpi_resource_io and
   acpi_resource_fixed_io, which should be used to define resource
   for PCI device instead of PCI bridge.
2) Accept IOMEM resource defined by acpi_resource_memory24,
   acpi_resource_memory32 and acpi_resource_fixed_memory32.
   These IOMEM resources are accepted to workaround some BIOS issue,
   though they should be ignored. For example, PC Engines APU.1C
   platform defines PCI host bridge IOMEM resources as:
Memory32Fixed (ReadOnly,
0x000A, // Address Base
0x0002, // Address Length
)
Memory32Fixed (ReadOnly,
0x, // Address Base
0x, // Address Length
_Y00)
3) Accept all IO port and IOMEM resources defined by
   acpi_resource_address{16,32,64,extended64}, no matter it's marked as
   ACPI_CONSUMER or ACPI_PRODUCER.

Commit 593669c2ac0f("Use common ACPI resource interfaces to
simplify implementation") accept all IO port and IOMEM resources
defined by acpi_resource_io, acpi_resource_fixed_io,
acpi_resource_memory24, acpi_resource_memory32,
acpi_resource_fixed_memory32 and
acpi_resource_address{16,32,64,extended64}, which causes IO port
resources consumed by host bridge itself are listed in to host bridge
resource list.

Then commit 63f1789ec716("Ignore resources consumed by host bridge
itself") ignores resources consumed by host bridge itself by checking
IORESOURCE_WINDOW flag, which accidently removed the workaround in 2)
above for BIOS bug .

It's really costed us much time to figure out this whole picture.
So we refine interface acpi_dev_filter_resource_type as below,
which should be easier for maintence:
1) Caller specifies IORESOURCE_WINDOW flag to explicitly query resource
   for bridge(PRODUCER), otherwise it's querying resource for
   device(CONSUMER).
2) Ignore IO port resources defined by acpi_resource_io and
   acpi_resource_fixed_io if IORESOURCE_WINDOW is specified.
3) Accpet IOMEM resource defined by acpi_resource_memory24,
   acpi_resource_memory32 and acpi_resource_fixed_memory32 for BIOS
   bugs, with comment to state it's workaround for BIOS bug.
4) Accept IO port and IOMEM defined by acpi_resource_addressxx if
   a) IORESOURCE_WINDOW is specified and ACPI_PRODUCER is true
   b) IORESOURCE_WINDOW is not specified and ACPI_PRODUCER is false

Currently acpi_dev_filter_resource_type() is only used by ACPI pci
host bridge and IOAPIC driver, so it shouldn't affect other drivers.

Another possible fix is to only ignore IO resource consumed by host
bridge and keep IOMEM resource consumed by host bridge, please refer to:
http://www.spinics.net/lists/linux-pci/msg39706.html

Sample ACPI table are archived at:
https://bugzilla.kernel.org/show_bug.cgi?id=94221

V2->V3:
Refine function acpi_dev_match_producer_consumer() as suggested by Rafael

Fixes: 63f1789ec716("Ignore resources consumed by host bridge itself")
Reported-and-Tested-by: Bernhard Thaler 
Signed-off-by: Jiang Liu 
---
 arch/x86/pci/acpi.c |5 ++---
 drivers/acpi/resource.c |   33 +
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index e4695985f9de..8c4b1201f340 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -337,7 +337,7 @@ static void probe_pci_root_info(struct pci_root_info *info,
info->bridge = device;
ret = acpi_dev_get_resources(device, list,
 acpi_dev_filter_resource_type_cb,
-(void *)(IORESOURCE_IO | IORESOURCE_MEM));
+(void *)(IORESOURCE_IO | IORESOURCE_MEM | 
IORESOURCE_WINDOW));
if (ret < 0)
dev_warn(>dev,
 "failed to parse _CRS method, error code %d\n", ret);
@@ -346,8 +346,7 @@ static void probe_pci_root_info(struct pci_root_info *info,
"no IO and memory resources present in _CRS\n");
else
resource_list_for_each_entry_safe(entry, tmp, list) {
-   if ((entry->res->flags & IORESOURCE_WINDOW) == 0 ||
-   (entry->res->flags & IORESOURCE_DISABLED))
+   if (entry->res->flags & IORESOURCE_DISABLED)
resource_list_destroy_entry(entry);
else
entry->res->name = info->name;
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 5589a6e2a023..e761a868bdba 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -567,6 +567,12 @@ int acpi_dev_get_resources(struct acpi_device *adev, 

Re: [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel

[AKASHI Takahiro]

Thank you, Geoff.

On 03/27/2015 01:43 PM, Geoff Levand wrote:

Hi Takahiro,

On Thu, 2015-03-26 at 17:28 +0900, AKASHI Takahiro wrote:

On system kernel, the memory region used by crash dump kernel must be
specified by "crashkernel=X@Y" boot parameter. reserve_crashkernel()
will allocate the region in "System RAM" and reserve it for later use.

On crash dump kernel, memory region information in system kernel is
described in a specific region specified by "elfcorehdr=X@Y" boot parameter.
reserve_elfcorehdr() will set aside the region to avoid data destruction
by the kernel.

Crash dump kernel will access memory regions in system kernel via
copy_oldmem_page(), which reads a page with ioremap'ing it assuming that


s/page with/page by/


Fix it.


such pages are not part of main memory of crash dump kernel.
This is true under non-UEFI environment because kexec-tools modifies
a device tree adding "usablemem" attributes to memory sections.
Under UEFI, however, this is not true because UEFI remove memory sections
in a device tree and export all the memory regions, even though they belong
to system kernel.

So we should add "mem=X[MG]" boot parameter to limit the meory size and


s/meory/memory/


Fix it.


avoid hitting the following assertion in ioremap():
if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr
return NULL;

Signed-off-by: AKASHI Takahiro 
---
  arch/arm64/kernel/Makefile |1 +
  arch/arm64/kernel/crash_dump.c |   71 
  arch/arm64/kernel/setup.c  |   78 
  3 files changed, 150 insertions(+)
  create mode 100644 arch/arm64/kernel/crash_dump.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index da9a7ee..3c24d4e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -36,6 +36,7 @@ arm64-obj-$(CONFIG_EFI)   += efi.o 
efi-stub.o efi-entry.o
  arm64-obj-$(CONFIG_PCI)   += pci.o
  arm64-obj-$(CONFIG_ARMV8_DEPRECATED)  += armv8_deprecated.o
  arm64-obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
+arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o

  obj-y += $(arm64-obj-y) vdso/
  obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
new file mode 100644
index 000..dd31b2e
--- /dev/null
+++ b/arch/arm64/kernel/crash_dump.c
@@ -0,0 +1,71 @@
+/*
+ * arch/arm64/kernel/crash_dump.c


I would recommend against adding paths in source files.  It often
happens that files with paths are moved, but the file comments are not
updated.


Yeah, will fix it.


+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * copy_oldmem_page() - copy one page from old kernel memory
+ * @pfn: page frame number to be copied
+ * @buf: buffer where the copied page is placed
+ * @csize: number of bytes to copy
+ * @offset: offset in bytes into the page
+ * @userbuf: if set, @buf is int he user address space


s/is int he user/is a user/


Fix it. Sorry for bunch of typos.


+ *
+ * This function copies one page from old kernel memory into buffer pointed by
+ * @buf. If @buf is in userspace, set @userbuf to %1. Returns number of bytes
+ * copied or negative error in case of failure.
+ */
+ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
+size_t csize, unsigned long offset,
+int userbuf)


Since userbuf is a binary flag, I think type bool would be better.
Change the comments from 'set' and '1' to 'true'.

Should offset be type size_t?


No. The prototype is already there in include/linux/crash_dump.h.


+{
+   void *vaddr;
+
+   if (!csize)
+   return 0;
+
+   vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
+   if (!vaddr)
+   return -ENOMEM;
+
+   if (userbuf) {
+   if (copy_to_user(buf, vaddr + offset, csize)) {
+   iounmap(vaddr);
+   return -EFAULT;
+   }
+   } else {
+   memcpy(buf, vaddr + offset, csize);
+   }
+
+   iounmap(vaddr);
+
+   return csize;
+}
+
+/**
+ * elfcorehdr_read - read from ELF core header
+ * @buf: buffer where the data is placed
+ * @csize: number of bytes to read
+ * @ppos: address in the memory
+ *
+ * This function reads @count bytes from elf core header which exists
+ * on crash dump kernel's memory.
+ */
+ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)


Should ppos be type phys_addr_t *?


No. The prototype is already there in include/linux/crash_dump.h.


+{
+   memcpy(buf, 

Re: [RFC][PATCH 01/10] tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values

[Namhyung Kim]

Hi Steve,

On Fri, Mar 27, 2015 at 05:37:05PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)" 
> 
> Several tracepoints use the helper functions __print_symbolic() or
> __print_flags() and pass in enums that do the mapping between the
> binary data stored and the value to print. This works well for reading
> the ASCII trace files, but when the data is read via userspace tools
> such as perf and trace-cmd, the conversion of the binary value to a
> human string format is lost if an enum is used, as userspace does not
> have access to what the ENUM is.
> 
> For example, the tracepoint trace_tlb_flush() has:
> 
>  __print_symbolic(REC->reason,
> { TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" },
> { TLB_REMOTE_SHOOTDOWN, "remote shootdown" },
> { TLB_LOCAL_SHOOTDOWN, "local shootdown" },
> { TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" })
> 
> Which maps the enum values to the strings they represent. But perf and
> trace-cmd do no know what value TLB_LOCAL_MM_SHOOTDOWN is, and would
> not be able to map it.
> 
> With TRACE_DEFINE_ENUM(), developers can place these in the event header
> files and ftrace will export the value of the enum via the file:
> 
>  tracing/enum_map
> 
> By adding:
> 
>  TRACE_DEFINE_ENUM(TLB_FLUSH_ON_TASK_SWITCH);
>  TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN);
>  TRACE_DEFINE_ENUM(TLB_LOCAL_SHOOTDOWN);
>  TRACE_DEFINE_ENUM(TLB_LOCAL_MM_SHOOTDOWN);
> 
>  $ cat /sys/kernel/debug/tracing/enum_map
> TLB_FLUSH_ON_TASK_SWITCH 0
> TLB_REMOTE_SHOOTDOWN 1
> TLB_LOCAL_SHOOTDOWN 2
> TLB_LOCAL_MM_SHOOTDOWN 3
> 
> The above can be easily parsed by userspace and it can be able to
> convert the enums to their values and properly parse the enums within
> the __print_symbolic() and __print_flags() helper functions.
> 
> Cc: Guilherme Cox 
> Cc: Tony Luck 
> Cc: Xie XiuQi 
> Signed-off-by: Steven Rostedt 
> ---

[SNIP]
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 62c6506d663f..53b449c522a7 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -123,6 +123,9 @@ enum ftrace_dump_mode ftrace_dump_on_oops;
>  /* When set, tracing will stop when a WARN*() is hit */
>  int __disable_trace_on_warning;
>  
> +/* Map of enums to their values, for "enum_map" file */
> +static struct trace_enum_map *trace_enum_maps;
> +
>  static int tracing_set_tracer(struct trace_array *tr, const char *buf);
>  
>  #define MAX_TRACER_SIZE  100
> @@ -3908,6 +3911,96 @@ static const struct file_operations 
> tracing_saved_cmdlines_size_fops = {
>   .write  = tracing_saved_cmdlines_size_write,
>  };
>  
> +static void *enum_map_next(struct seq_file *m, void *v, loff_t *pos)
> +{
> + struct trace_enum_map *ptr = v;
> +
> + if (!ptr->enum_string)
> + return NULL;

Do we really need to check NULL string here?  Seems like duplicated..

Thanks,
Namhyung


> +
> + ptr++;
> +
> + (*pos)++;
> +
> + if (!ptr->enum_string)
> + return NULL;
> +
> + return ptr;
> +}
> +
> +static void *enum_map_start(struct seq_file *m, loff_t *pos)
> +{
> + struct trace_enum_map *v;
> + loff_t l = 0;
> +
> + v = trace_enum_maps;
> + while (v && l < *pos) {
> + v = enum_map_next(m, v, );
> + }
> +
> + return v;
> +}
> +
> +static void enum_map_stop(struct seq_file *m, void *v)
> +{
> +}
> +
> +static int enum_map_show(struct seq_file *m, void *v)
> +{
> + struct trace_enum_map *ptr = v;
> +
> + seq_printf(m, "%s %ld\n", ptr->enum_string, ptr->enum_value);
> + return 0;
> +}
> +
> +static const struct seq_operations tracing_enum_map_seq_ops = {
> + .start  = enum_map_start,
> + .next   = enum_map_next,
> + .stop   = enum_map_stop,
> + .show   = enum_map_show,
> +};
> +
> +static int tracing_enum_map_open(struct inode *inode, struct file *filp)
> +{
> + if (tracing_disabled)
> + return -ENODEV;
> +
> + return seq_open(filp, _enum_map_seq_ops);
> +}
> +
> +static const struct file_operations tracing_enum_map_fops = {
> + .open   = tracing_enum_map_open,
> + .read   = seq_read,
> + .llseek = seq_lseek,
> + .release= seq_release,
> +};
> +
> +static void
> +trace_insert_enum_map(struct trace_enum_map **start, struct trace_enum_map 
> **stop)
> +{
> + struct trace_enum_map **map;
> + struct trace_enum_map *map_array;
> + int len = stop - start;
> +
> + if (len <= 0)
> + return;
> +
> + map_array = kmalloc(sizeof(*map_array) * (len + 1), GFP_KERNEL);
> + if (!map_array) {
> + pr_warning("Unable to allocate trace enum mapping\n");
> + return;
> + }
> +
> + trace_enum_maps = map_array;
> +
> + for (map = start; (unsigned long)map < (unsigned long)stop; map++) {
> + *map_array = **map;
> + map_array++;
> + }
> + memset(map_array, 0, sizeof(*map_array));
> +}
> +
> +
>  

Re: [RFC PATCH] sched: Add cpu based entries to debugfs

[Mike Galbraith]

On Sun, 2015-03-29 at 22:13 -0400, David Ahern wrote:

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 62671f53202a..b4d8d0c8260e 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -268,12 +268,173 @@ static const struct file_operations sched_feat_fops = {
>   .release= single_release,
>  };
>  
> +static const char * const sd_flag_names[] = {
> + "load-balance",
> + "new-idle",
> + "exec",
> + "fork",
> + "wake",
> + "affine",
> + "",
> + "cpu-capacity",
> + "power-domain",
> + "share-pkg-resources",
> + "serialize",
> + "asym-packing",
> + "prefer-sibling",
> + "overlap",
> + "numa",
> + "",
> +};

That's wrong with the names readers will want to grep for?

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] kernel/reboot.c: Add orderly_reboot for graceful reboot

[Joel Stanley]

The kernel has orderly_poweroff which allows the kernel to initiate a
graceful shutdown of userspace, by running /sbin/poweroff. This adds
orderly_reboot that will cause userspace to shut itself down by calling
/sbin/reboot.

This will be used for shutdown initiated by a system controller on
platforms that do not use ACPI.

Signed-off-by: Joel Stanley 
---
 include/linux/reboot.h |  1 +
 kernel/reboot.c| 51 +++---
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 48bf152..a4ffcd9 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -68,6 +68,7 @@ void ctrl_alt_del(void);
 extern char poweroff_cmd[POWEROFF_CMD_PATH_LEN];
 
 extern int orderly_poweroff(bool force);
+extern int orderly_reboot(void);
 
 /*
  * Emergency restart, callable from an interrupt handler.
diff --git a/kernel/reboot.c b/kernel/reboot.c
index a3a9e24..d0aa1ec 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -306,8 +306,9 @@ void ctrl_alt_del(void)
 }
 
 char poweroff_cmd[POWEROFF_CMD_PATH_LEN] = "/sbin/poweroff";
+char reboot_cmd[POWEROFF_CMD_PATH_LEN] = "/sbin/reboot";
 
-static int __orderly_poweroff(bool force)
+static int run_cmd(const char *cmd)
 {
char **argv;
static char *envp[] = {
@@ -316,8 +317,7 @@ static int __orderly_poweroff(bool force)
NULL
};
int ret;
-
-   argv = argv_split(GFP_KERNEL, poweroff_cmd, NULL);
+   argv = argv_split(GFP_KERNEL, cmd, NULL);
if (argv) {
ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
argv_free(argv);
@@ -325,8 +325,33 @@ static int __orderly_poweroff(bool force)
ret = -ENOMEM;
}
 
+   return ret;
+}
+
+static int __orderly_reboot(void)
+{
+   int ret;
+
+   ret = run_cmd(reboot_cmd);
+
+   if (ret) {
+   pr_warn("Failed to start orderly reboot: forcing the issue\n");
+   emergency_sync();
+   kernel_restart(NULL);
+   }
+
+   return ret;
+}
+
+static int __orderly_poweroff(bool force)
+{
+   int ret;
+
+   ret = run_cmd(reboot_cmd);
+
if (ret && force) {
pr_warn("Failed to start orderly shutdown: forcing the 
issue\n");
+
/*
 * I guess this should try to kick off some daemon to sync and
 * poweroff asap.  Or not even bother syncing if we're doing an
@@ -364,6 +389,26 @@ int orderly_poweroff(bool force)
 }
 EXPORT_SYMBOL_GPL(orderly_poweroff);
 
+static void reboot_work_func(struct work_struct *work)
+{
+   __orderly_reboot();
+}
+
+static DECLARE_WORK(reboot_work, reboot_work_func);
+
+/**
+ * orderly_reboot - Trigger an orderly system reboot
+ *
+ * This may be called from any context to trigger a system reboot.
+ * If the orderly reboot fails, it will force an immediate reboot.
+ */
+int orderly_reboot(void)
+{
+   schedule_work(_work);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(orderly_reboot);
+
 static int __init reboot_setup(char *str)
 {
for (;;) {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] powerpc/powernv: Reboot when requested by firmware

[Joel Stanley]

Use orderly_reboot so userspace will to shut itself down via the reboot
path. This is required for graceful reboot initiated by the BMC, such
as when a user uses ipmitool to issue a 'chassis power cycle' command.

Signed-off-by: Joel Stanley 
---
 arch/powerpc/platforms/powernv/opal-power.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-power.c 
b/arch/powerpc/platforms/powernv/opal-power.c
index 48bf5b0..ac46c2c 100644
--- a/arch/powerpc/platforms/powernv/opal-power.c
+++ b/arch/powerpc/platforms/powernv/opal-power.c
@@ -29,8 +29,9 @@ static int opal_power_control_event(struct notifier_block *nb,
 
switch (type) {
case SOFT_REBOOT:
-   /* Fall through. The service processor is responsible for
-* bringing the machine back up */
+   pr_info("OPAL: reboot requested\n");
+   orderly_reboot();
+   break;
case SOFT_OFF:
pr_info("OPAL: poweroff requested\n");
orderly_poweroff(true);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH] sched: Add cpu based entries to debugfs

[David Ahern]

Currently sched_debug can be added to the kernel commandline parameters
to dump domain information during boot. This method is not practical with
a large number of CPUs.

This patch adds per-cpu entries to debugfs under a sched directory.
Reading the per-cpu file shows the domain information in a human-readable
format:

$ cat /sys/kernel/debug/sched/cpu0
domain 0 / SMT:
flags: 0x2af:  load-balance new-idle exec fork affine cpu-capacity 
share-pkg-resources
span: 0-7
groups:
0 (cpu_capacity = 147)
1 (cpu_capacity = 147)
2 (cpu_capacity = 147)
3 (cpu_capacity = 147)
4 (cpu_capacity = 147)
5 (cpu_capacity = 147)
6 (cpu_capacity = 147)
7 (cpu_capacity = 147)

domain 2 / DIE:
flags: 0x102f:  load-balance new-idle exec fork affine prefer-sibling
span: 0-127
groups:
0-7 (cpu_capacity = 1176)
8-15 (cpu_capacity = 1176)
16-23 (cpu_capacity = 1176)
24-31 (cpu_capacity = 1176)
32-39 (cpu_capacity = 1176)
40-47 (cpu_capacity = 1176)
48-55 (cpu_capacity = 1176)
56-63 (cpu_capacity = 1176)
64-71 (cpu_capacity = 1176)
72-79 (cpu_capacity = 1176)
80-87 (cpu_capacity = 1176)
88-95 (cpu_capacity = 1176)
96-103 (cpu_capacity = 1176)
104-111 (cpu_capacity = 1176)
112-119 (cpu_capacity = 1176)
120-127 (cpu_capacity = 1176)

domain 3 / NUMA:
flags: 0x642f:  load-balance new-idle exec fork affine serialize overlap 
numa
span: 0-1023
groups:
0-127 (cpu_capacity = 18816)
128-255 (cpu_capacity = 18816)
256-383 (cpu_capacity = 18816)
384-511 (cpu_capacity = 18816)
512-639 (cpu_capacity = 18816)
640-767 (cpu_capacity = 18816)
768-895 (cpu_capacity = 18816)
896-1023 (cpu_capacity = 18816)

Before spending too much time formalizing this I wanted to see if you guys
would entertain the idea of making this info available via debugfs. It does
move the existing sched_features file to sched/features -- not sure how 
acceptable it is to move files in debugfs.

TO-DO: handle hotplug

Signed-off-by: David Ahern 
---
 kernel/sched/core.c | 167 +++-
 1 file changed, 164 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 62671f53202a..b4d8d0c8260e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -268,12 +268,173 @@ static const struct file_operations sched_feat_fops = {
.release= single_release,
 };
 
+static const char * const sd_flag_names[] = {
+   "load-balance",
+   "new-idle",
+   "exec",
+   "fork",
+   "wake",
+   "affine",
+   "",
+   "cpu-capacity",
+   "power-domain",
+   "share-pkg-resources",
+   "serialize",
+   "asym-packing",
+   "prefer-sibling",
+   "overlap",
+   "numa",
+   "",
+};
+static void sched_cpu_domain_show(struct seq_file *m, struct sched_domain *sd,
+ int cpu)
+{
+   struct cpumask groupmask;
+   struct sched_group *group = sd->groups;
+   int i;
+
+   cpumask_clear();
+
+   seq_printf(m, "domain %d / %s:\n", sd->level, sd->name);
+   seq_printf(m, "flags: 0x%x: ", sd->flags);
+
+   for (i = 0; i < ARRAY_SIZE(sd_flag_names); ++i) {
+   if (sd->flags & (1 << i))
+   seq_printf(m, " %s", sd_flag_names[i]);
+   }
+   seq_puts(m, "\n");
+
+   if (!(sd->flags & SD_LOAD_BALANCE) && sd->parent)
+   seq_puts(m, "   ERROR: !SD_LOAD_BALANCE domain has 
parent\n");
+
+   seq_printf(m, "span: %*pbl\n",
+  cpumask_pr_args(sched_domain_span(sd)));
+
+   if (!cpumask_test_cpu(cpu, sched_domain_span(sd)))
+   seq_printf(m, "ERROR: domain->span does not contain 
CPU%d\n", cpu);
+
+   if (!cpumask_test_cpu(cpu, sched_group_cpus(group)))
+   seq_printf(m, "ERROR: domain->groups does not contain 
CPU%d\n", cpu);
+
+   seq_puts(m, "groups:\n");
+   do {
+   if (!group) {
+   seq_puts(m, "ERROR: group is NULL\n");
+   break;
+   }
+
+   /*
+* Even though we initialize ->capacity to something semi-sane,
+* we leave capacity_orig unset. This allows us to detect if
+* domain iteration is still funny without causing /0 traps.
+*/
+   if (!group->sgc->capacity_orig) {
+   seq_puts(m, "ERROR: domain->cpu_capacity not 
set\n");
+   break;
+   }
+
+   if (!cpumask_weight(sched_group_cpus(group))) {
+   seq_puts(m, "ERROR: empty group\n");
+   break;
+   }
+
+   if (!(sd->flags & 

[PATCH RESEND] perf tools: introduce arm64 support unwind test.

[Wang Nan]

Newest libunwind does support ARM64, and perf is able to utilize it
also. This patch enables the missing perf test dwarf unwind for arm64.

 Test result:
  # ./perf test unwind
  25: Test dwarf unwind  : Ok

Signed-off-by: Wang Nan 
---
 tools/perf/arch/arm64/Build|  1 +
 tools/perf/arch/arm64/include/perf_regs.h  |  3 ++
 tools/perf/arch/arm64/tests/Build  |  2 +
 tools/perf/arch/arm64/tests/dwarf-unwind.c | 61 ++
 tools/perf/arch/arm64/tests/regs_load.S| 46 ++
 tools/perf/tests/Build |  2 +-
 tools/perf/tests/builtin-test.c|  2 +-
 tools/perf/tests/tests.h   |  2 +-
 8 files changed, 116 insertions(+), 3 deletions(-)
 create mode 100644 tools/perf/arch/arm64/tests/Build
 create mode 100644 tools/perf/arch/arm64/tests/dwarf-unwind.c
 create mode 100644 tools/perf/arch/arm64/tests/regs_load.S

diff --git a/tools/perf/arch/arm64/Build b/tools/perf/arch/arm64/Build
index 54afe4a..41bf61d 100644
--- a/tools/perf/arch/arm64/Build
+++ b/tools/perf/arch/arm64/Build
@@ -1 +1,2 @@
 libperf-y += util/
+libperf-$(CONFIG_DWARF_UNWIND) += tests/
diff --git a/tools/perf/arch/arm64/include/perf_regs.h 
b/tools/perf/arch/arm64/include/perf_regs.h
index 1d3f39c..4e5af27 100644
--- a/tools/perf/arch/arm64/include/perf_regs.h
+++ b/tools/perf/arch/arm64/include/perf_regs.h
@@ -5,8 +5,11 @@
 #include 
 #include 
 
+void perf_regs_load(u64 *regs);
+
 #define PERF_REGS_MASK ((1ULL << PERF_REG_ARM64_MAX) - 1)
 #define PERF_REGS_MAX  PERF_REG_ARM64_MAX
+#define PERF_SAMPLE_REGS_ABI   PERF_SAMPLE_REGS_ABI_64
 
 #define PERF_REG_IPPERF_REG_ARM64_PC
 #define PERF_REG_SPPERF_REG_ARM64_SP
diff --git a/tools/perf/arch/arm64/tests/Build 
b/tools/perf/arch/arm64/tests/Build
new file mode 100644
index 000..b30eff9
--- /dev/null
+++ b/tools/perf/arch/arm64/tests/Build
@@ -0,0 +1,2 @@
+libperf-y += regs_load.o
+libperf-y += dwarf-unwind.o
diff --git a/tools/perf/arch/arm64/tests/dwarf-unwind.c 
b/tools/perf/arch/arm64/tests/dwarf-unwind.c
new file mode 100644
index 000..cf04a4c
--- /dev/null
+++ b/tools/perf/arch/arm64/tests/dwarf-unwind.c
@@ -0,0 +1,61 @@
+#include 
+#include "perf_regs.h"
+#include "thread.h"
+#include "map.h"
+#include "event.h"
+#include "debug.h"
+#include "tests/tests.h"
+
+#define STACK_SIZE 8192
+
+static int sample_ustack(struct perf_sample *sample,
+   struct thread *thread, u64 *regs)
+{
+   struct stack_dump *stack = >user_stack;
+   struct map *map;
+   unsigned long sp;
+   u64 stack_size, *buf;
+
+   buf = malloc(STACK_SIZE);
+   if (!buf) {
+   pr_debug("failed to allocate sample uregs data\n");
+   return -1;
+   }
+
+   sp = (unsigned long) regs[PERF_REG_ARM64_SP];
+
+   map = map_groups__find(thread->mg, MAP__VARIABLE, (u64) sp);
+   if (!map) {
+   pr_debug("failed to get stack map\n");
+   free(buf);
+   return -1;
+   }
+
+   stack_size = map->end - sp;
+   stack_size = stack_size > STACK_SIZE ? STACK_SIZE : stack_size;
+
+   memcpy(buf, (void *) sp, stack_size);
+   stack->data = (char *) buf;
+   stack->size = stack_size;
+   return 0;
+}
+
+int test__arch_unwind_sample(struct perf_sample *sample,
+   struct thread *thread)
+{
+   struct regs_dump *regs = >user_regs;
+   u64 *buf;
+
+   buf = calloc(1, sizeof(u64) * PERF_REGS_MAX);
+   if (!buf) {
+   pr_debug("failed to allocate sample uregs data\n");
+   return -1;
+   }
+
+   perf_regs_load(buf);
+   regs->abi  = PERF_SAMPLE_REGS_ABI;
+   regs->regs = buf;
+   regs->mask = PERF_REGS_MASK;
+
+   return sample_ustack(sample, thread, buf);
+}
diff --git a/tools/perf/arch/arm64/tests/regs_load.S 
b/tools/perf/arch/arm64/tests/regs_load.S
new file mode 100644
index 000..025b46e
--- /dev/null
+++ b/tools/perf/arch/arm64/tests/regs_load.S
@@ -0,0 +1,46 @@
+#include 
+
+.text
+.type perf_regs_load,%function
+#define STR_REG(r) str x##r, [x0, 8 * r]
+#define LDR_REG(r) ldr x##r, [x0, 8 * r]
+#define SP (8 * 31)
+#define PC (8 * 32)
+ENTRY(perf_regs_load)
+   STR_REG(0)
+   STR_REG(1)
+   STR_REG(2)
+   STR_REG(3)
+   STR_REG(4)
+   STR_REG(5)
+   STR_REG(6)
+   STR_REG(7)
+   STR_REG(8)
+   STR_REG(9)
+   STR_REG(10)
+   STR_REG(11)
+   STR_REG(12)
+   STR_REG(13)
+   STR_REG(14)
+   STR_REG(15)
+   STR_REG(16)
+   STR_REG(17)
+   STR_REG(18)
+   STR_REG(19)
+   STR_REG(20)
+   STR_REG(21)
+   STR_REG(22)
+   STR_REG(23)
+   STR_REG(24)
+   STR_REG(25)
+   STR_REG(26)
+   STR_REG(27)
+   STR_REG(28)
+   STR_REG(29)
+   STR_REG(30)
+   mov x1, sp
+   str x1, [x0, #SP]
+   str x30, [x0, #PC]
+   LDR_REG(1)
+   

[PATCH RESEND] perf: .gitignore: ignore .config-detected.

[Wang Nan]

Commit fcfd6611fbccdbf2593bd949097a5c0e45cd96da ("tools build: Add
detected config support") dynamically creates .config-detected. Add it
to .gitignore.

Signed-off-by: Wang Nan 
---
 tools/perf/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
index 812f904..09db62b 100644
--- a/tools/perf/.gitignore
+++ b/tools/perf/.gitignore
@@ -28,3 +28,4 @@ config.mak.autogen
 *-flex.*
 *.pyc
 *.pyo
+.config-detected
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/2] ARM: EXYNOS: Make sure that the Exynos5420 MDMA0 clock is enabled during suspend

[Chanwoo Choi]

Hi Javier,

On 03/27/2015 11:21 PM, Javier Martinez Canillas wrote:
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this clock needs to remain enabled in order to make
> the system resume from a system suspend state.
> 
> To make sure that the clock is enabled during suspend, enable it prior
> to entering a suspend state and disable it once the system has resumed.
> 
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
> 
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management 
> support v12")
> Signed-off-by: Javier Martinez Canillas 
> ---
>  arch/arm/mach-exynos/suspend.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index 1521eaf99265..6dbc0a6d1bb5 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -79,6 +80,7 @@ static const struct exynos_pm_data *pm_data;
>  
>  static int exynos5420_cpu_state;
>  static unsigned int exynos_pmu_spare3;
> +static struct clk *clk;
>  
>  /*
>   * GIC wake-up support
> @@ -374,6 +376,16 @@ static void exynos5420_pm_prepare(void)
>  {
>   unsigned int tmp;
>  
> + /*
> +  * Exynos5420 requires the MDMA0 controller clock to be
> +  * ungated on suspend in order to be resumed correctly.
> +  */
> + clk = clk_get(NULL, "mdma0");
> + if (IS_ERR(clk))
> + pr_warn("Failed to get mdma0 clk (%ld)\n", PTR_ERR(clk));
> + else
> + clk_prepare_enable(clk);
> +

I faced on the similiar issue. If some clock was disabled,
Exynos SoC could not enter the suspend mode

But, I think it is not prpper method to resolve this issue.
about that that specific clock (e.g., mdma0) is handled in this dirver.
Also, ARM-64bit don't include any '../mach-exynos' directory.

IMHO, some clock issue have to be handled in SoC clk driver or others.

[snip]

Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: arm/ksm: Unable to handle kernel paging request in get_ksm_page() and ksm_scan_thread()

[Xishi Qiu]

On 2015/3/30 8:43, Hugh Dickins wrote:

> On Sat, 28 Mar 2015, Xishi Qiu wrote:
>> On 2015/3/26 21:23, Xishi Qiu wrote:
>>
>>> Here are two panic logs from smart phone test, and the kernel version is 
>>> v3.10.
>>>
>>> log1 is "Unable to handle kernel paging request at virtual address 
>>> c0704da020", it should be ffc0704da020, right?
> 
> That one was an oops at get_ksm_page+0x34/0x150: I'm pretty sure that
> comes from the "kpfn = ACCESS_ONCE(stable_node->kpfn)" line, that the
> stable_node pointer (in x21 or x22) has upper bits cleared; which
> suggests corruption of the rmap_item supposed to point to it.
> 
> get_ksm_page() is tricky with ACCESS_ONCEs against page migration,
> and the structures tricky with unions; but pointers overlay pointers
> in those unions, I don't see any way we might pick up an address with
> the upper 24 or 32 bits cleared due to that.
> 
>>> and log2 is "Unable to handle kernel paging request at virtual address 
>>> 1e000796", it should be ffc01e000796, right?
> 
> And this one was an oops at ksm_scan_thread+0x4ac/0xce0; as is the oops
> you posted below.  Which contains lots of hex numbers, but very little
> info I can work from.
> 
> Please make a CONFIG_DEBUG_INFO=y build of one of the kernels you're
> hitting this with, then use the disassembler (objdump -ld perhaps) to
> identify precisely which line of ksm.c that is oopsing on: the compiler
> will have inlined more interesting functions into ksm_scan_thread, so
> I haven't a clue where it's actually oopsing.
> 
> Maybe we'll find that it's also oopsing on a kernel virtual address
> from an rmap_item, maybe we won't.
> 
> And I don't read arm64 assembler at all, so I shall be rather limited
> in what I can tell you, I'm afraid.
> 
>>>
>>> I cann't repeat the panic by test, so could anyone tell me this is the 
>>> bug of ksm or other reason?
> 
> I've not heard of any problem like this with KSM on other architectures.
> Maybe it is making some assumption which is invalid on arm64, but I'd
> have thought we'd have heard about that before now.  My guess is that
> something in your kernel is stamping on KSM's structures.
> 
> A relevant experiment (after identifying the oops line in your current
> kernel) might be to switch from CONFIG_SLAB=y to CONFIG_SLUB=y or vice
> versa.  I doubt SLAB or SLUB is to blame, but changing allocator might
> shake things up in a way that either hides the problem, or shifts it
> elsewhere.
> 
> Hugh
> 

Hi Hugh,

Thanks for your reply. There are 3 cases as follows, at first I think maybe
something causes the oops, but all of the cases are relevant to "rmap_item",
so I have no idea.

1. ksm_scan_thread+0xa88/0xce0 -> unstable_tree_search_insert() -> 
tree_rmap_item = rb_entry(*new, struct rmap_item, node);

2. ksm_scan_thread+0x4ac/0xce0 -> get_next_rmap_item() -> if 
((rmap_item->address & PAGE_MASK) == addr)

3. get_ksm_page+0x34/0x150 -> get_ksm_page() -> kpfn = 
ACCESS_ONCE(stable_node->kpfn);

Thanks,
Xishi Qiu


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] wireless: Use bool function returns of true/false instead of 1/0

[Joe Perches]

On Sun, 2015-03-29 at 20:46 -0500, Larry Finger wrote:
> On 03/29/2015 08:29 PM, Joe Perches wrote:
> > Use bool constants as the return values instead of 1 and 0.
> >
> > Signed-off-by: Joe Perches 
> > ---
> >> To be honest I'd might rather get bunches of these, there has to be a ton
> >> of them, than a slow trickle of one every few weeks/days.
> >
> > There aren't too many here either...
> >
> >   drivers/net/wireless/b43/dma.c| 12 ++--
> >   drivers/net/wireless/b43legacy/dma.c  |  6 +++---
> >   drivers/net/wireless/b43legacy/rfkill.c   |  8 
> >   drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c |  2 +-
> >   drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c |  2 +-
> >   drivers/net/wireless/iwlwifi/iwl-config.h |  4 ++--
> >   6 files changed, 17 insertions(+), 17 deletions(-)
> 
> Please split these into separate patches for each driver. That way it will be 
> possible to search 'git log' for the contributions to each driver. Otherwise, 
> the patches are OK.

It's still possible.

git log  shows the individual patches.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] wireless: Use bool function returns of true/false instead of 1/0

[Larry Finger]

On 03/29/2015 08:29 PM, Joe Perches wrote:

Use bool constants as the return values instead of 1 and 0.

Signed-off-by: Joe Perches 
---

To be honest I'd might rather get bunches of these, there has to be a ton
of them, than a slow trickle of one every few weeks/days.


There aren't too many here either...

  drivers/net/wireless/b43/dma.c| 12 ++--
  drivers/net/wireless/b43legacy/dma.c  |  6 +++---
  drivers/net/wireless/b43legacy/rfkill.c   |  8 
  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c |  2 +-
  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c |  2 +-
  drivers/net/wireless/iwlwifi/iwl-config.h |  4 ++--
  6 files changed, 17 insertions(+), 17 deletions(-)


Please split these into separate patches for each driver. That way it will be 
possible to search 'git log' for the contributions to each driver. Otherwise, 
the patches are OK.


Thanks,

Larry



diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index 1d7982a..6837064 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -553,7 +553,7 @@ static bool b43_dma_mapping_error(struct b43_dmaring *ring,
  size_t buffersize, bool dma_to_device)
  {
if (unlikely(dma_mapping_error(ring->dev->dev->dma_dev, addr)))
-   return 1;
+   return true;

switch (ring->type) {
case B43_DMA_30BIT:
@@ -571,13 +571,13 @@ static bool b43_dma_mapping_error(struct b43_dmaring 
*ring,
}

/* The address is OK. */
-   return 0;
+   return false;

  address_error:
/* We can't support this address. Unmap it again. */
unmap_descbuffer(ring, addr, buffersize, dma_to_device);

-   return 1;
+   return true;
  }

  static bool b43_rx_buffer_is_poisoned(struct b43_dmaring *ring, struct 
sk_buff *skb)
@@ -1099,16 +1099,16 @@ static bool b43_dma_translation_in_low_word(struct 
b43_wldev *dev,
enum b43_dmatype type)
  {
if (type != B43_DMA_64BIT)
-   return 1;
+   return true;

  #ifdef CONFIG_B43_SSB
if (dev->dev->bus_type == B43_BUS_SSB &&
dev->dev->sdev->bus->bustype == SSB_BUSTYPE_PCI &&
!(pci_is_pcie(dev->dev->sdev->bus->host_pci) &&
  ssb_read32(dev->dev->sdev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64))
-   return 1;
+   return true;
  #endif
-   return 0;
+   return false;
  }

  int b43_dma_init(struct b43_wldev *dev)
diff --git a/drivers/net/wireless/b43legacy/dma.c 
b/drivers/net/wireless/b43legacy/dma.c
index b2ed179..f9dd892 100644
--- a/drivers/net/wireless/b43legacy/dma.c
+++ b/drivers/net/wireless/b43legacy/dma.c
@@ -427,7 +427,7 @@ static bool b43legacy_dma_mapping_error(struct 
b43legacy_dmaring *ring,
 bool dma_to_device)
  {
if (unlikely(dma_mapping_error(ring->dev->dev->dma_dev, addr)))
-   return 1;
+   return true;

switch (ring->type) {
case B43legacy_DMA_30BIT:
@@ -441,13 +441,13 @@ static bool b43legacy_dma_mapping_error(struct 
b43legacy_dmaring *ring,
}

/* The address is OK. */
-   return 0;
+   return false;

  address_error:
/* We can't support this address. Unmap it again. */
unmap_descbuffer(ring, addr, buffersize, dma_to_device);

-   return 1;
+   return true;
  }

  static int setup_rx_descbuffer(struct b43legacy_dmaring *ring,
diff --git a/drivers/net/wireless/b43legacy/rfkill.c 
b/drivers/net/wireless/b43legacy/rfkill.c
index c4559bc..7c1bdbc 100644
--- a/drivers/net/wireless/b43legacy/rfkill.c
+++ b/drivers/net/wireless/b43legacy/rfkill.c
@@ -32,7 +32,7 @@ bool b43legacy_is_hw_radio_enabled(struct b43legacy_wldev 
*dev)
if (dev->dev->id.revision >= 3) {
if (!(b43legacy_read32(dev, B43legacy_MMIO_RADIO_HWENABLED_HI)
  & B43legacy_MMIO_RADIO_HWENABLED_HI_MASK))
-   return 1;
+   return true;
} else {
/* To prevent CPU fault on PPC, do not read a register
 * unless the interface is started; however, on resume
@@ -40,12 +40,12 @@ bool b43legacy_is_hw_radio_enabled(struct b43legacy_wldev 
*dev)
 * that happens, unconditionally return TRUE.
 */
if (b43legacy_status(dev) < B43legacy_STAT_STARTED)
-   return 1;
+   return true;
if (b43legacy_read16(dev, B43legacy_MMIO_RADIO_HWENABLED_LO)
& B43legacy_MMIO_RADIO_HWENABLED_LO_MASK)
-   return 1;
+   return true;
}
-   return 0;
+   return false;
  }

  /* The poll callback for the hardware button. */
diff --git 

[PATCH] MAINTAINERS: CREDITS: Remove Stefano Brivio from B43

[Joe Perches]

This email address isn't working anymore

Signed-off-by: Joe Perches 
---

Nearly 5 years on...
https://lkml.org/lkml/2010/6/24/315
his email address is still dead.

 CREDITS | 4 
 MAINTAINERS | 4 +---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/CREDITS b/CREDITS
index a0060bd..2ef5dce 100644
--- a/CREDITS
+++ b/CREDITS
@@ -508,6 +508,10 @@ E: p...@paulbristow.net
 W: http://paulbristow.net/linux/idefloppy.html
 D: Maintainer of IDE/ATAPI floppy driver
 
+N: Stefano Brivio
+E: stefano.bri...@polimi.it
+D: Broadcom B43 driver
+
 N: Dominik Brodowski
 E: li...@brodo.de
 W: http://www.brodo.de/
diff --git a/MAINTAINERS b/MAINTAINERS
index 201280a..4af2945 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1924,16 +1924,14 @@ S:  Maintained
 F: drivers/media/radio/radio-aztech*
 
 B43 WIRELESS DRIVER
-M: Stefano Brivio 
 L: linux-wirel...@vger.kernel.org
 L: b43-...@lists.infradead.org
 W: http://wireless.kernel.org/en/users/Drivers/b43
-S: Maintained
+S: Odd Fixes
 F: drivers/net/wireless/b43/
 
 B43LEGACY WIRELESS DRIVER
 M: Larry Finger 
-M: Stefano Brivio 
 L: linux-wirel...@vger.kernel.org
 L: b43-...@lists.infradead.org
 W: http://wireless.kernel.org/en/users/Drivers/b43


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Len,

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

In file included from arch/x86/include/asm/msr.h:131:0,
 from arch/x86/include/asm/processor.h:20,
 from arch/x86/include/asm/thread_info.h:23,
 from include/linux/thread_info.h:54,
 from arch/x86/include/asm/preempt.h:6,
 from include/linux/preempt.h:18,
 from include/linux/smp.h:55,
 from include/linux/kernel_stat.h:4,
 from drivers/cpufreq/intel_pstate.c:14:
drivers/cpufreq/intel_pstate.c: In function 'core_get_turbo_pstate':
drivers/cpufreq/intel_pstate.c:593:9: error: 'MSR_NHM_TURBO_RATIO_LIMIT' 
undeclared (first use in this function)
  rdmsrl(MSR_NHM_TURBO_RATIO_LIMIT, value);
 ^
arch/x86/include/asm/paravirt.h:153:26: note: in definition of macro 'rdmsrl'
  val = paravirt_read_msr(msr, &_err); \
  ^
drivers/cpufreq/intel_pstate.c:593:9: note: each undeclared identifier is 
reported only once for each function it appears in
  rdmsrl(MSR_NHM_TURBO_RATIO_LIMIT, value);
 ^
arch/x86/include/asm/paravirt.h:153:26: note: in definition of macro 'rdmsrl'
  val = paravirt_read_msr(msr, &_err); \
  ^

Caused by commit ce62fbaf893c ("tools/power turbostat: define and dump
MSR_TURBO_RATIO_LIMIT2").  Grep is your friend ...

I have used the idle tree from next-20150327 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpgNUAvMnH6k.pgp
Description: OpenPGP digital signature

Re: [RFC v2 0/5] arm64: kvm: reset hyp context for kexec

[AKASHI Takahiro]

On 03/28/2015 02:40 AM, Kyle McMartin wrote:

On Fri, Mar 27, 2015 at 03:37:04PM +, Marc Zyngier wrote:

[  236.260863] Kernel panic - not syncing: HYP panic:
[  236.260863] PS:63c9 PC:03ff0830 ESR:9606


It would be interesting if you could find out what you have at offset
0x830 of hyp-init.o (the stack trace is for EL1, and is not going to
help much).



Given the alignment, i'm going to assume i'm looking at the right thing:

0820 <__kvm_hyp_reset>:
  820:   d51c2000msr ttbr0_el2, x0
  824:   d5033fdfisb
  828:   d50c871ftlbialle2
  82c:   d5033f9fdsb sy
  830:   1060adr x0, 83c <__kvm_hyp_reset+0x1c>
  834:   b3403c01bfxil   x1, x0, #0, #16
  838:   d61f0020br  x1
  83c:   d53c1000mrs x0, sctlr_el2

but it seems fairly implausible to be trapping on ADR x0, 1f...



I've never seen this panic on fast model...

ESR shows that
  - Exception class: Data abort taken without a change in Exception level
  - Data fault status code: Translation fault at EL2

and FAR seems not to be a proper address.

-Takahiro AKASHI


--Kyle


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/2] mm, doc: cleanup and clarify munmap behavior for hugetlb memory

[Hugh Dickins]

On Thu, 26 Mar 2015, David Rientjes wrote:

> munmap(2) of hugetlb memory requires a length that is hugepage aligned,
> otherwise it may fail.  Add this to the documentation.

Thanks for taking this on, David.  But although munmap(2) is the one
Davide called out, it goes beyond that, doesn't it?  To mprotect and
madvise and ...

I don't want to work out the list myself: is_vm_hugetlb_page() is
special-cased all over, and different syscalls react differently.

Which is another reason why, like you, I much prefer not to interfere
with the long established behavior: it would be very easy to introduce
bugs and worse inconsistencies.

And mprotect(2) is a good example of why we should not mess around
with the long established API here: changing an mprotect from failing
on a particular size to acting on a larger size is not a safe change.

Eric, I apologize for bringing you in to the discussion, and then
ignoring your input.  I understand that you would like MAP_HUGETLB
to behave more understandably.  We can all agree that the existing
behavior is unsatisfying.  But it's many years too late now to 
change it around - and I suspect that a full exercise to do so would
actually discover some good reasons why the original choices were made.

> 
> This also cleans up the documentation and separates it into logical
> units: one part refers to MAP_HUGETLB and another part refers to
> requirements for shared memory segments.
> 
> Signed-off-by: David Rientjes 
> ---
>  Documentation/vm/hugetlbpage.txt | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/vm/hugetlbpage.txt 
> b/Documentation/vm/hugetlbpage.txt
> --- a/Documentation/vm/hugetlbpage.txt
> +++ b/Documentation/vm/hugetlbpage.txt
> @@ -289,15 +289,20 @@ file systems, write system calls are not.
>  Regular chown, chgrp, and chmod commands (with right permissions) could be
>  used to change the file attributes on hugetlbfs.
>  
> -Also, it is important to note that no such mount command is required if the
> +Also, it is important to note that no such mount command is required if
>  applications are going to use only shmat/shmget system calls or mmap with
> -MAP_HUGETLB.  Users who wish to use hugetlb page via shared memory segment
> -should be a member of a supplementary group and system admin needs to
> -configure that gid into /proc/sys/vm/hugetlb_shm_group.  It is possible for
> -same or different applications to use any combination of mmaps and shm*
> -calls, though the mount of filesystem will be required for using mmap calls
> -without MAP_HUGETLB.  For an example of how to use mmap with MAP_HUGETLB see
> -map_hugetlb.c.
> +MAP_HUGETLB.  For an example of how to use mmap with MAP_HUGETLB see 
> map_hugetlb
> +below.
> +
> +Users who wish to use hugetlb memory via shared memory segment should be a
> +member of a supplementary group and system admin needs to configure that gid
> +into /proc/sys/vm/hugetlb_shm_group.  It is possible for same or different
> +applications to use any combination of mmaps and shm* calls, though the 
> mount of
> +filesystem will be required for using mmap calls without MAP_HUGETLB.
> +
> +When using munmap(2) to unmap hugetlb memory, the length specified must be
> +hugepage aligned, otherwise it will fail with errno set to EINVAL.

Perhaps just adding something like "The same is true for mprotect(2)
and other such memory system calls." is good enough for here.

> +
>  
>  Examples
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next] wireless: Use bool function returns of true/false instead of 1/0

[Joe Perches]

Use bool constants as the return values instead of 1 and 0.

Signed-off-by: Joe Perches 
---
> To be honest I'd might rather get bunches of these, there has to be a ton
> of them, than a slow trickle of one every few weeks/days.

There aren't too many here either...

 drivers/net/wireless/b43/dma.c| 12 ++--
 drivers/net/wireless/b43legacy/dma.c  |  6 +++---
 drivers/net/wireless/b43legacy/rfkill.c   |  8 
 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c |  2 +-
 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c |  2 +-
 drivers/net/wireless/iwlwifi/iwl-config.h |  4 ++--
 6 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index 1d7982a..6837064 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -553,7 +553,7 @@ static bool b43_dma_mapping_error(struct b43_dmaring *ring,
  size_t buffersize, bool dma_to_device)
 {
if (unlikely(dma_mapping_error(ring->dev->dev->dma_dev, addr)))
-   return 1;
+   return true;
 
switch (ring->type) {
case B43_DMA_30BIT:
@@ -571,13 +571,13 @@ static bool b43_dma_mapping_error(struct b43_dmaring 
*ring,
}
 
/* The address is OK. */
-   return 0;
+   return false;
 
 address_error:
/* We can't support this address. Unmap it again. */
unmap_descbuffer(ring, addr, buffersize, dma_to_device);
 
-   return 1;
+   return true;
 }
 
 static bool b43_rx_buffer_is_poisoned(struct b43_dmaring *ring, struct sk_buff 
*skb)
@@ -1099,16 +1099,16 @@ static bool b43_dma_translation_in_low_word(struct 
b43_wldev *dev,
enum b43_dmatype type)
 {
if (type != B43_DMA_64BIT)
-   return 1;
+   return true;
 
 #ifdef CONFIG_B43_SSB
if (dev->dev->bus_type == B43_BUS_SSB &&
dev->dev->sdev->bus->bustype == SSB_BUSTYPE_PCI &&
!(pci_is_pcie(dev->dev->sdev->bus->host_pci) &&
  ssb_read32(dev->dev->sdev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64))
-   return 1;
+   return true;
 #endif
-   return 0;
+   return false;
 }
 
 int b43_dma_init(struct b43_wldev *dev)
diff --git a/drivers/net/wireless/b43legacy/dma.c 
b/drivers/net/wireless/b43legacy/dma.c
index b2ed179..f9dd892 100644
--- a/drivers/net/wireless/b43legacy/dma.c
+++ b/drivers/net/wireless/b43legacy/dma.c
@@ -427,7 +427,7 @@ static bool b43legacy_dma_mapping_error(struct 
b43legacy_dmaring *ring,
 bool dma_to_device)
 {
if (unlikely(dma_mapping_error(ring->dev->dev->dma_dev, addr)))
-   return 1;
+   return true;
 
switch (ring->type) {
case B43legacy_DMA_30BIT:
@@ -441,13 +441,13 @@ static bool b43legacy_dma_mapping_error(struct 
b43legacy_dmaring *ring,
}
 
/* The address is OK. */
-   return 0;
+   return false;
 
 address_error:
/* We can't support this address. Unmap it again. */
unmap_descbuffer(ring, addr, buffersize, dma_to_device);
 
-   return 1;
+   return true;
 }
 
 static int setup_rx_descbuffer(struct b43legacy_dmaring *ring,
diff --git a/drivers/net/wireless/b43legacy/rfkill.c 
b/drivers/net/wireless/b43legacy/rfkill.c
index c4559bc..7c1bdbc 100644
--- a/drivers/net/wireless/b43legacy/rfkill.c
+++ b/drivers/net/wireless/b43legacy/rfkill.c
@@ -32,7 +32,7 @@ bool b43legacy_is_hw_radio_enabled(struct b43legacy_wldev 
*dev)
if (dev->dev->id.revision >= 3) {
if (!(b43legacy_read32(dev, B43legacy_MMIO_RADIO_HWENABLED_HI)
  & B43legacy_MMIO_RADIO_HWENABLED_HI_MASK))
-   return 1;
+   return true;
} else {
/* To prevent CPU fault on PPC, do not read a register
 * unless the interface is started; however, on resume
@@ -40,12 +40,12 @@ bool b43legacy_is_hw_radio_enabled(struct b43legacy_wldev 
*dev)
 * that happens, unconditionally return TRUE.
 */
if (b43legacy_status(dev) < B43legacy_STAT_STARTED)
-   return 1;
+   return true;
if (b43legacy_read16(dev, B43legacy_MMIO_RADIO_HWENABLED_LO)
& B43legacy_MMIO_RADIO_HWENABLED_LO_MASK)
-   return 1;
+   return true;
}
-   return 0;
+   return false;
 }
 
 /* The poll callback for the hardware button. */
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c 
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
index 941b1e4..1c4e9dd 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -2949,5 

[PATCH v2 3/3] Documentation/ABI: Update sysfs-driver-toshiba_acpi entry

[Azael Avalos]

This patch updates the sysfs-driver-toshiba_acpi entry, adding the
missing entries for USB Sleep functions.

And also, while at the neighborhood, fix some typos and add a note
that some features require a reboot.

Signed-off-by: Azael Avalos 
---
 .../ABI/testing/sysfs-driver-toshiba_acpi  | 93 +++---
 1 file changed, 80 insertions(+), 13 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-toshiba_acpi 
b/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
index ca9c71a..eed922e 100644
--- a/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
+++ b/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
@@ -8,9 +8,11 @@ Description:   This file controls the keyboard backlight 
operation mode, valid
* 0x2  -> AUTO (also called TIMER)
* 0x8  -> ON
* 0x10 -> OFF
-   Note that the kernel 3.16 onwards this file accepts all listed
+   Note that from kernel 3.16 onwards this file accepts all listed
parameters, kernel 3.15 only accepts the first two (FN-Z and
AUTO).
+   Also note that toggling this value on type 1 devices, requires
+   a reboot for changes to take effect.
 Users: KToshiba
 
 What:  
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
@@ -67,15 +69,72 @@ Description:This file shows the current keyboard 
backlight type,
* 2 -> Type 2, supporting modes TIMER, ON and OFF
 Users: KToshiba
 
+What:  
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_charge
+Date:  January 23, 2015
+KernelVersion: 4.0
+Contact:   Azael Avalos 
+Description:   This file controls the USB Sleep & Charge charging mode, which
+   can be:
+   * 0 -> Disabled (0x00)
+   * 1 -> Alternate(0x09)
+   * 2 -> Auto (0x21)
+   * 3 -> Typical  (0x11)
+   Note that from kernel 4.1 onwards this file accepts all listed
+   values, kernel 4.0 only supports the first three.
+   Note that this feature only works when connected to power, if
+   you want to use it under battery, see the entry named
+   "sleep_functions_on_battery"
+Users: KToshiba
+
+What:  
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/sleep_functions_on_battery
+Date:  January 23, 2015
+KernelVersion: 4.0
+Contact:   Azael Avalos 
+Description:   This file controls the USB Sleep Functions under battery, and
+   set the level at which point they will be disabled, accepted
+   values can be:
+   * 0 -> Disabled
+   * 1-100 -> Battery level to disable sleep functions
+   Currently it prints two values, the first one indicates if the
+   feature is enabled or disabled, while the second one shows the
+   current battery level set.
+   Note that when the value is set to disabled, the sleep function
+   will only work when connected to power.
+Users: KToshiba
+
+What:  
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_rapid_charge
+Date:  January 23, 2015
+KernelVersion: 4.0
+Contact:   Azael Avalos 
+Description:   This file controls the USB Rapid Charge state, which can be:
+   * 0 -> Disabled
+   * 1 -> Enabled
+   Note that toggling this value requires a reboot for changes to
+   take effect.
+Users: KToshiba
+
+What:  
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_music
+Date:  January 23, 2015
+KernelVersion: 4.0
+Contact:   Azael Avalos 
+Description:   This file controls the Sleep & Music state, which values can be:
+   * 0 -> Disabled
+   * 1 -> Enabled
+   Note that this feature only works when connected to power, if
+   you want to use it under battery, see the entry named
+   "sleep_functions_on_battery"
+Users: KToshiba
+
 What:  
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
-Date:  February, 2015
-KernelVersion: 3.20
+Date:  February 12, 2015
+KernelVersion: 4.0
 Contact:   Azael Avalos 
 Description:   This file shows the current version of the driver
+Users: KToshiba
 
 What:  /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
-Date:  February, 2015
-KernelVersion: 3.20
+Date:  February 12, 2015
+KernelVersion: 4.0
 Contact:   Azael Avalos 
 Description:   This file controls the state of the internal fan, valid
values are:
@@ -83,8 +142,8 @@ 

[PATCH v2 1/3] toshiba_acpi: Update and fix USB Sleep and Charge modes

[Azael Avalos]

This patch fixes the USB Sleep and Charge mode on certain models
where the value returned by the BIOS is different, and thus, making
this feature not to work for those models.

Also, the "Typical" charging mode was added as a supported mode.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 69 -
 1 file changed, 60 insertions(+), 9 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 17a259e..c8ad61c 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -150,9 +150,10 @@ MODULE_LICENSE("GPL");
 #define SCI_KBD_MODE_OFF   0x10
 #define SCI_KBD_TIME_MAX   0x3c001a
 #define SCI_USB_CHARGE_MODE_MASK   0xff
-#define SCI_USB_CHARGE_DISABLED0x3
-#define SCI_USB_CHARGE_ALTERNATE   0x30009
-#define SCI_USB_CHARGE_AUTO0x30021
+#define SCI_USB_CHARGE_DISABLED0x00
+#define SCI_USB_CHARGE_ALTERNATE   0x09
+#define SCI_USB_CHARGE_TYPICAL 0x11
+#define SCI_USB_CHARGE_AUTO0x21
 #define SCI_USB_CHARGE_BAT_MASK0x7
 #define SCI_USB_CHARGE_BAT_LVL_OFF 0x1
 #define SCI_USB_CHARGE_BAT_LVL_ON  0x4
@@ -177,6 +178,7 @@ struct toshiba_acpi_dev {
int kbd_mode;
int kbd_time;
int usbsc_bat_level;
+   int usbsc_mode_base;
int hotkey_event_type;
 
unsigned int illumination_supported:1;
@@ -800,6 +802,52 @@ static int toshiba_accelerometer_get(struct 
toshiba_acpi_dev *dev,
 }
 
 /* Sleep (Charge and Music) utilities support */
+static void toshiba_usb_sleep_charge_available(struct toshiba_acpi_dev *dev)
+{
+   u32 in[TCI_WORDS] = { SCI_GET, SCI_USB_SLEEP_CHARGE, 0, 0, 0, 0 };
+   u32 out[TCI_WORDS];
+   acpi_status status;
+
+   /* Set the feature to "not supported" in case of error */
+   dev->usb_sleep_charge_supported = 0;
+
+   if (!sci_open(dev))
+   return;
+
+   status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
+   pr_err("ACPI call to get USB Sleep and Charge mode failed\n");
+   sci_close(dev);
+   return;
+   } else if (out[0] == TOS_NOT_SUPPORTED) {
+   pr_info("USB Sleep and Charge not supported\n");
+   sci_close(dev);
+   return;
+   }
+   dev->usbsc_mode_base = out[4];
+
+   in[5] = SCI_USB_CHARGE_BAT_LVL;
+   status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
+   pr_err("ACPI call to get USB Sleep and Charge mode failed\n");
+   sci_close(dev);
+   return;
+   } else if (out[0] == TOS_NOT_SUPPORTED) {
+   pr_info("USB Sleep and Charge not supported\n");
+   sci_close(dev);
+   return;
+   }
+   dev->usbsc_bat_level = out[2];
+   /*
+* If we reach this point, it means that the laptop has support for
+* this feature and all values are initialized.
+* Set it as supported.
+*/
+   dev->usb_sleep_charge_supported = 1;
+
+   sci_close(dev);
+}
+
 static int toshiba_usb_sleep_charge_get(struct toshiba_acpi_dev *dev,
u32 *mode)
 {
@@ -1976,17 +2024,21 @@ static ssize_t usb_sleep_charge_store(struct device 
*dev,
 * 0 - Disabled
 * 1 - Alternate (Non USB conformant devices that require more power)
 * 2 - Auto (USB conformant devices)
+* 3 - Typical
 */
-   if (state != 0 && state != 1 && state != 2)
+   if (state != 0 && state != 1 && state != 2 && state != 3)
return -EINVAL;
 
/* Set the USB charging mode to internal value */
+   mode = toshiba->usbsc_mode_base;
if (state == 0)
-   mode = SCI_USB_CHARGE_DISABLED;
+   mode |= SCI_USB_CHARGE_DISABLED;
else if (state == 1)
-   mode = SCI_USB_CHARGE_ALTERNATE;
+   mode |= SCI_USB_CHARGE_ALTERNATE;
else if (state == 2)
-   mode = SCI_USB_CHARGE_AUTO;
+   mode |= SCI_USB_CHARGE_AUTO;
+   else if (state == 3)
+   mode |= SCI_USB_CHARGE_TYPICAL;
 
ret = toshiba_usb_sleep_charge_set(toshiba, mode);
if (ret)
@@ -2756,8 +2808,7 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
ret = toshiba_accelerometer_supported(dev);
dev->accelerometer_supported = !ret;
 
-   ret = toshiba_usb_sleep_charge_get(dev, );
-   dev->usb_sleep_charge_supported = !ret;
+   toshiba_usb_sleep_charge_available(dev);
 
ret = toshiba_usb_rapid_charge_get(dev, );
dev->usb_rapid_charge_supported = !ret;
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH v2 2/3] toshiba_acpi: Fix pr_* messages from USB Sleep Functions

[Azael Avalos]

This patch fixes the messages displayed by the USB Sleep Functions,
they were printing wrong messages not associated to the feature
currently queried.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index c8ad61c..be755606 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -963,11 +963,11 @@ static int toshiba_usb_rapid_charge_get(struct 
toshiba_acpi_dev *dev,
status = tci_raw(dev, in, out);
sci_close(dev);
if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
-   pr_err("ACPI call to get USB S battery level failed\n");
+   pr_err("ACPI call to get USB Rapid Charge failed\n");
return -EIO;
} else if (out[0] == TOS_NOT_SUPPORTED ||
   out[0] == TOS_INPUT_DATA_ERROR) {
-   pr_info("USB Sleep and Charge not supported\n");
+   pr_info("USB Rapid Charge not supported\n");
return -ENODEV;
}
 
@@ -991,10 +991,10 @@ static int toshiba_usb_rapid_charge_set(struct 
toshiba_acpi_dev *dev,
status = tci_raw(dev, in, out);
sci_close(dev);
if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
-   pr_err("ACPI call to set USB S battery level failed\n");
+   pr_err("ACPI call to set USB Rapid Charge failed\n");
return -EIO;
} else if (out[0] == TOS_NOT_SUPPORTED) {
-   pr_info("USB Sleep and Charge not supported\n");
+   pr_info("USB Rapid Charge not supported\n");
return -ENODEV;
} else if (out[0] == TOS_INPUT_DATA_ERROR) {
return -EIO;
@@ -1013,10 +1013,10 @@ static int toshiba_usb_sleep_music_get(struct 
toshiba_acpi_dev *dev, u32 *state)
result = sci_read(dev, SCI_USB_SLEEP_MUSIC, state);
sci_close(dev);
if (result == TOS_FAILURE) {
-   pr_err("ACPI call to set USB S mode failed\n");
+   pr_err("ACPI call to get Sleep and Music failed\n");
return -EIO;
} else if (result == TOS_NOT_SUPPORTED) {
-   pr_info("USB Sleep and Charge not supported\n");
+   pr_info("Sleep and Music not supported\n");
return -ENODEV;
} else if (result == TOS_INPUT_DATA_ERROR) {
return -EIO;
@@ -1035,10 +1035,10 @@ static int toshiba_usb_sleep_music_set(struct 
toshiba_acpi_dev *dev, u32 state)
result = sci_write(dev, SCI_USB_SLEEP_MUSIC, state);
sci_close(dev);
if (result == TOS_FAILURE) {
-   pr_err("ACPI call to set USB S mode failed\n");
+   pr_err("ACPI call to set Sleep and Music failed\n");
return -EIO;
} else if (result == TOS_NOT_SUPPORTED) {
-   pr_info("USB Sleep and Charge not supported\n");
+   pr_info("Sleep and Music not supported\n");
return -ENODEV;
} else if (result == TOS_INPUT_DATA_ERROR) {
return -EIO;
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/3] toshiba_acpi: Fix USB Sleep & Charge mode and documentation updates

[Azael Avalos]

This patch fixes the USB Sleep & Charge charging mode on certain
models, fixes pr_* messages and also adds the missing entries in the
documentation file.

Changes since v1:
- Set the default supported value of sleep and charge to zero in case
  of an error and added comments.
- Updated the title and commit message of second patch to better
  reflect what the patch is doing.

Azael Avalos (3):
  toshiba_acpi: Update and fix USB Sleep and Charge modes
  toshiba_acpi: Fix pr_* messages from USB Sleep Functions
  Documentation/ABI: Update sysfs-driver-toshiba_acpi entry

 .../ABI/testing/sysfs-driver-toshiba_acpi  | 93 +++---
 drivers/platform/x86/toshiba_acpi.c| 85 
 2 files changed, 148 insertions(+), 30 deletions(-)

-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next] ethernet: Use bool function returns of true/false instead of 1/0

[Joe Perches]

Use bool constants as the return values instead of 1 and 0.

Signed-off-by: Joe Perches 
---
> To be honest I'd might rather get bunches of these, there has to be a ton
> of them, than a slow trickle of one every few weeks/days.

There aren't too many...

 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4 ++--
 drivers/net/ethernet/xilinx/xilinx_emaclite.c| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 039b0c1..9980912 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -11610,7 +11610,7 @@ static bool bnx2x_get_dropless_info(struct bnx2x *bp)
u32 cfg;
 
if (IS_VF(bp))
-   return 0;
+   return false;
 
if (IS_MF(bp) && !CHIP_IS_E1x(bp)) {
/* Take function: tmp = func */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 02ffb30..ccaecb1 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1351,7 +1351,7 @@ static bool reg_pattern_test(struct ixgbe_adapter 
*adapter, u64 *data, int reg,
 
if (ixgbe_removed(adapter->hw.hw_addr)) {
*data = 1;
-   return 1;
+   return true;
}
for (pat = 0; pat < ARRAY_SIZE(test_pattern); pat++) {
before = ixgbe_read_reg(>hw, reg);
@@ -1376,7 +1376,7 @@ static bool reg_set_and_check(struct ixgbe_adapter 
*adapter, u64 *data, int reg,
 
if (ixgbe_removed(adapter->hw.hw_addr)) {
*data = 1;
-   return 1;
+   return true;
}
before = ixgbe_read_reg(>hw, reg);
ixgbe_write_reg(>hw, reg, write & mask);
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c 
b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 2111b91..6008eee 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1062,7 +1062,7 @@ static bool get_bool(struct platform_device *ofdev, const 
char *s)
} else {
dev_warn(>dev, "Parameter %s not found,"
"defaulting to false\n", s);
-   return 0;
+   return false;
}
 }
 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf, record: Add clockid parameter

[David Ahern]

On 3/28/15 1:55 AM, Peter Zijlstra wrote:

Subject: perf, record: Add clockid parameter
From: Peter Zijlstra 
Date: Fri, 27 Mar 2015 15:32:01 +0100

Teach perf-record about the new perf_event_attr::{use_clockid, clockid}
fields. Add a simple parameter to set the clock (if any) to be used for
the events to be recorded into the data file.

Since we store the entire perf_event_attr in the EVENT_DESC section we
also already store the used clockid in the data file.



I am clearly missing some kernel patch to try out this perf patch. I 
have the 4 timekeeper ones; none of those modify perf_event code. What 
other patches are needed? Was this one (or some variant) accepted:


https://lkml.org/lkml/2015/2/20/236

Perhaps a better question is what tree has all of the kernel side patches?

David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 tip 6/9] samples: bpf: simple non-portable kprobe filter example

[Alexei Starovoitov]

On 3/29/15 5:34 PM, Jovi Zhangwei wrote:

+   snprintf(buf, sizeof(buf),
+"echo '%c:%s %s' >> 
/sys/kernel/debug/tracing/kprobe_events",
+is_kprobe ? 'p' : 'r', event, event);
+   err = system(buf);


Maybe we need to remember cleanup the kprobe_events in debugfs?


the real tracing tool should be cleaning it up. This is sample code.
I didn't want to overcomplicate it with a chain of ctrl-c handlers.
Notice patch 7 is simply doing signal(SIGINT, int_exit) and prints
histogram when process is terminated. The kprobe cleaning logic would
have interfere with this and overall would have made these samples
unnecessary complex.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

[Jaehoon Chung]

Dear Doug,

I'm considering to control HLE error..So holding this patch.
If this is absolutely necessary patch, let me know, plz.

Best Regards,
Jaehoon Chung

On 03/16/2015 02:56 PM, Jaehoon Chung wrote:
> Hi, Doug.
> 
> On 03/14/2015 05:27 AM, Doug Anderson wrote:
>> Hi,
>>
>> On Fri, Mar 13, 2015 at 4:30 AM, Jaehoon Chung  
>> wrote:
>>> Hi, Doug.
>>>
>>> On 03/11/2015 12:48 AM, Doug Anderson wrote:
 The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but
 nothing in the interrupt handler actually handles them and ACKs them.
 That means that if we ever get an HLE error we'll just keep getting
 interrupts and we'll wedge things.

 We really don't expect HLE errors but if we ever get them we shouldn't
 silently ignore them.

 Note that I have seen HLE errors while constantly ejecting and
 inserting cards (ejecting while inserting, etc).
>>>
>>> Right, It is occurred when card inserting/ejecting.(This case is the case 
>>> of removable card.)
>>> Did you test with eMMC? We needs to consider how control HLE error.
>>
>> I'm running it on systems with eMMC, SD Cards, and SDIO WiFi.  HLE
>> doesn't show up in normal circumstances, only in ejecting the SD card
>> at the wrong time.  ...since you can't eject eMMC, I didn't see
>> problems there.
> 
> When card is inserting/removing, HLE is often occurred.
> Since there is some request into queue when card is removed.(in my 
> understanding.)
> It's also related with controlling clock.
> 
>>
>>> But I think this patch can't solve all of HLE problem.
>>
>> Agreed.  HLE means that the controller is pretty wedged and (as I
>> understand it) means that there's something else we're doing wrong
>> elsewhere in the dw_mmc driver (like writing more data to an already
>> busy controller).  We should probably track down and find those cases,
>> too.
>>
>> I agree also that this code probably won't fix the controller in all
>> cases of HLE errors.  ...but I'm not 100% certain of the best way to
>> really do that, do you know?
>>
>> ...but in any case the absolute worst thing to do is what the driver
>> is already doing: unmask the HLE interrupt but never handle it
>> anywhere...  My patch is at least better than that...
> 
> Agreed, your patch should be at least better than now.
> But if pending is set HLE error bit,
> it should hit the cases of DW_MCI_DATA_ERROR_FLAGS & DW_MCI_CMD_ERROR_FLAGS.
> and i think send_stop_abort() can't run, doesn't?
> (If HLE is occurred at non-removable card, controller can't do anything.)
> 
> If i can reproduce HLE error, i can check more detailedly.(Trying to 
> reproduce it.)
> I don't find fully solution yet. But finding the solution is my or our(?) 
> part/role in future.
> Actually, i'm using the ctrl reset at my local tree, when HLE error is 
> occurred.
> (Also it's not solution..)
> According to TRM, "HLE is raised, software then has to reload the command."
> We needs to consider how reload the command without lost previous request.
> 
>>
>> If you have another suggested way to make HLE error handling better
>> (or avoid them to begin with) I'm happy to test!  :)
> 
> I will try to find HLE error handling..if you also have other opinion, let me 
> know, plz.
> I needs to listen other opinion, it's great helpful to me.. :)
> 
> Thank you a lot!
> 
> Best Regards,
> Jaehoon Chung
> 
>>
>>
>> -Doug
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: arm/ksm: Unable to handle kernel paging request in get_ksm_page() and ksm_scan_thread()

[Hugh Dickins]

On Sat, 28 Mar 2015, Xishi Qiu wrote:
> On 2015/3/26 21:23, Xishi Qiu wrote:
> 
> > Here are two panic logs from smart phone test, and the kernel version is 
> > v3.10.
> > 
> > log1 is "Unable to handle kernel paging request at virtual address 
> > c0704da020", it should be ffc0704da020, right?

That one was an oops at get_ksm_page+0x34/0x150: I'm pretty sure that
comes from the "kpfn = ACCESS_ONCE(stable_node->kpfn)" line, that the
stable_node pointer (in x21 or x22) has upper bits cleared; which
suggests corruption of the rmap_item supposed to point to it.

get_ksm_page() is tricky with ACCESS_ONCEs against page migration,
and the structures tricky with unions; but pointers overlay pointers
in those unions, I don't see any way we might pick up an address with
the upper 24 or 32 bits cleared due to that.

> > and log2 is "Unable to handle kernel paging request at virtual address 
> > 1e000796", it should be ffc01e000796, right?

And this one was an oops at ksm_scan_thread+0x4ac/0xce0; as is the oops
you posted below.  Which contains lots of hex numbers, but very little
info I can work from.

Please make a CONFIG_DEBUG_INFO=y build of one of the kernels you're
hitting this with, then use the disassembler (objdump -ld perhaps) to
identify precisely which line of ksm.c that is oopsing on: the compiler
will have inlined more interesting functions into ksm_scan_thread, so
I haven't a clue where it's actually oopsing.

Maybe we'll find that it's also oopsing on a kernel virtual address
from an rmap_item, maybe we won't.

And I don't read arm64 assembler at all, so I shall be rather limited
in what I can tell you, I'm afraid.

> > 
> > I cann't repeat the panic by test, so could anyone tell me this is the 
> > bug of ksm or other reason?

I've not heard of any problem like this with KSM on other architectures.
Maybe it is making some assumption which is invalid on arm64, but I'd
have thought we'd have heard about that before now.  My guess is that
something in your kernel is stamping on KSM's structures.

A relevant experiment (after identifying the oops line in your current
kernel) might be to switch from CONFIG_SLAB=y to CONFIG_SLUB=y or vice
versa.  I doubt SLAB or SLUB is to blame, but changing allocator might
shake things up in a way that either hides the problem, or shifts it
elsewhere.

Hugh

> > 
> > Thanks,
> > Xishi Qiu
> > 
> 
> Here is another one.
> 
> [145556.775726s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]Unable to handle 
> kernel paging request at virtual address ff18
> [145556.775817s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]pgd = ffc07f5e4000
> [145556.775817s][2015:03:24 20:07:00][pid:864,cpu0,ksmd][ff18] 
> *pgd=80808003, *pmd=
> [145556.775878s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]Internal error: Oops: 
> 9606 [#1] PREEMPT SMP
> [145556.775909s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]Modules linked in:
> [145556.776000s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]CPU: 0 PID: 864 Comm: 
> ksmd Tainted: GW3.10.61-g2aca0a6-dirty #2
> [145556.776031s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]task: 
> ffc0bc06ee00 ti: ffc0baae4000 task.ti: ffc0baae4000
> [145556.776092s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]PC is at 
> ksm_scan_thread+0x4ac/0xce0
> [145556.776123s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]LR is at 
> ksm_scan_thread+0x49c/0xce0
> [145556.776153s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]pc : 
> [] lr : [] pstate: 8145
> [145556.776153s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]sp : ffc0baae7d50
> [145556.776184s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x29: ffc0baae7d50 
> x28: 75a4 
> [145556.776214s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x27: ffbc02308260 
> x26: ffc0010ab000 
> [145556.776245s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x25: ffc0599392a0 
> x24: ffc0baae4000 
> [145556.776306s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x23: ffc001a0aa90 
> x22: ffc0baae7df8 
> [145556.776336s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x21: ffc084150080 
> x20: ff00 
> [145556.776367s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x19: ffc0018ddb88 
> x18:  
> [145556.776397s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x17: 007f7f28a974 
> x16: ffc0007ca16c 
> [145556.776428s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x15: 0873 
> x14: 0001 
> [145556.776458s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x13: 0001 
> x12: 0848 
> [145556.776489s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x11: 0848 
> x10: 6995fcb1 
> [145556.776519s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x9 : c72311f7 
> x8 : 09050501 
> [145556.776550s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x7 : 05aeda8e 
> x6 : fa9a48df 
> [145556.776611s][2015:03:24 20:07:00][pid:864,cpu0,ksmd]x5 : ffc095e7abb0 
> x4 : 000b 
> [145556.776641s][2015:03:24 

Re: [PATCH v11 tip 6/9] samples: bpf: simple non-portable kprobe filter example

[Jovi Zhangwei]

On Wed, Mar 25, 2015 at 12:49 PM, Alexei Starovoitov  wrote:
> tracex1_kern.c - C program compiled into BPF.
> It attaches to kprobe:netif_receive_skb
> When skb->dev->name == "lo", it prints sample debug message into trace_pipe
> via bpf_trace_printk() helper function.
>
> tracex1_user.c - corresponding user space component that:
> - loads bpf program via bpf() syscall
> - opens kprobes:netif_receive_skb event via perf_event_open() syscall
> - attaches the program to event via ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, 
> prog_fd);
> - prints from trace_pipe
>
> Note, this bpf program is non-portable. It must be recompiled with current
> kernel headers. kprobe is not a stable ABI and bpf+kprobe scripts
> may no longer be meaningful when kernel internals change.
>
> No matter in what way the kernel changes, neither the kprobe, nor the bpf
> program can ever crash or corrupt the kernel, assuming the kprobes, perf and
> bpf subsystem has no bugs.
>
> The verifier will detect that the program is using bpf_trace_printk() and
> the kernel will print 'this is a DEBUG kernel' warning banner, which means 
> that
> bpf_trace_printk() should be used for debugging of the bpf program only.
>
> Usage:
> $ sudo tracex1
> ping-19826 [000] d.s2 63103.382648: : skb 880466b1ca00 len 84
> ping-19826 [000] d.s2 63103.382684: : skb 880466b1d300 len 84
>
> ping-19826 [000] d.s2 63104.382533: : skb 880466b1ca00 len 84
> ping-19826 [000] d.s2 63104.382594: : skb 880466b1d300 len 84
>
> Signed-off-by: Alexei Starovoitov 
> ---
>  samples/bpf/Makefile|4 ++
>  samples/bpf/bpf_helpers.h   |6 +++
>  samples/bpf/bpf_load.c  |  125 
> ---
>  samples/bpf/bpf_load.h  |3 ++
>  samples/bpf/libbpf.c|   14 -
>  samples/bpf/libbpf.h|5 +-
>  samples/bpf/sock_example.c  |2 +-
>  samples/bpf/test_verifier.c |2 +-
>  samples/bpf/tracex1_kern.c  |   50 +
>  samples/bpf/tracex1_user.c  |   25 +
>  10 files changed, 224 insertions(+), 12 deletions(-)
>  create mode 100644 samples/bpf/tracex1_kern.c
>  create mode 100644 samples/bpf/tracex1_user.c
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index b5b3600dcdf5..51f6f01e5a3a 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -6,23 +6,27 @@ hostprogs-y := test_verifier test_maps
>  hostprogs-y += sock_example
>  hostprogs-y += sockex1
>  hostprogs-y += sockex2
> +hostprogs-y += tracex1
>
>  test_verifier-objs := test_verifier.o libbpf.o
>  test_maps-objs := test_maps.o libbpf.o
>  sock_example-objs := sock_example.o libbpf.o
>  sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
>  sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
> +tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
>
>  # Tell kbuild to always build the programs
>  always := $(hostprogs-y)
>  always += sockex1_kern.o
>  always += sockex2_kern.o
> +always += tracex1_kern.o
>
>  HOSTCFLAGS += -I$(objtree)/usr/include
>
>  HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
>  HOSTLOADLIBES_sockex1 += -lelf
>  HOSTLOADLIBES_sockex2 += -lelf
> +HOSTLOADLIBES_tracex1 += -lelf
>
>  # point this to your LLVM backend with bpf support
>  LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
> diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
> index ca0333146006..1c872bcf5a80 100644
> --- a/samples/bpf/bpf_helpers.h
> +++ b/samples/bpf/bpf_helpers.h
> @@ -15,6 +15,12 @@ static int (*bpf_map_update_elem)(void *map, void *key, 
> void *value,
> (void *) BPF_FUNC_map_update_elem;
>  static int (*bpf_map_delete_elem)(void *map, void *key) =
> (void *) BPF_FUNC_map_delete_elem;
> +static int (*bpf_probe_read)(void *dst, int size, void *unsafe_ptr) =
> +   (void *) BPF_FUNC_probe_read;
> +static unsigned long long (*bpf_ktime_get_ns)(void) =
> +   (void *) BPF_FUNC_ktime_get_ns;
> +static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
> +   (void *) BPF_FUNC_trace_printk;
>
>  /* llvm builtin functions that eBPF C program may use to
>   * emit BPF_LD_ABS and BPF_LD_IND instructions
> diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
> index 1831d236382b..38dac5a53b51 100644
> --- a/samples/bpf/bpf_load.c
> +++ b/samples/bpf/bpf_load.c
> @@ -8,29 +8,70 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include "libbpf.h"
>  #include "bpf_helpers.h"
>  #include "bpf_load.h"
>
> +#define DEBUGFS "/sys/kernel/debug/tracing/"
> +
>  static char license[128];
> +static int kern_version;
>  static bool processed_sec[128];
>  int map_fd[MAX_MAPS];
>  int prog_fd[MAX_PROGS];
> +int event_fd[MAX_PROGS];
>  int prog_cnt;
>
>  static int load_and_attach(const char *event, struct bpf_insn *prog, int 
> size)
>  {
> -   int fd;
> bool is_socket 

Re: [patch 00/12] mm: page_alloc: improve OOM mechanism and policy

[Dave Chinner]

On Fri, Mar 27, 2015 at 11:05:09AM -0400, Johannes Weiner wrote:
> On Fri, Mar 27, 2015 at 06:58:22AM +1100, Dave Chinner wrote:
> > On Wed, Mar 25, 2015 at 02:17:04AM -0400, Johannes Weiner wrote:
> > > Hi everybody,
> > > 
> > > in the recent past we've had several reports and discussions on how to
> > > deal with allocations hanging in the allocator upon OOM.
> > > 
> > > The idea of this series is mainly to make the mechanism of detecting
> > > OOM situations reliable enough that we can be confident about failing
> > > allocations, and then leave the fallback strategy to the caller rather
> > > than looping forever in the allocator.
> > > 
> > > The other part is trying to reduce the __GFP_NOFAIL deadlock rate, at
> > > least for the short term while we don't have a reservation system yet.
> > 
> > A valid goal, but I think this series goes about it the wrong way.
> > i.e. it forces us to use __GFP_NOFAIL rather than providing us a
> > valid fallback mechanism to access reserves.
> 
> I think you misunderstood the goal.
> 
> While I agree that reserves would be the optimal fallback strategy,
> this series is about avoiding deadlocks in existing callsites that
> currently can not fail.  This is about getting the best out of our
> existing mechanisms until we have universal reservation coverage,
> which will take time to devise and transition our codebase to.

That might be the goal, but it looks like the wrong path to me.

> GFP_NOFS sites are currently one of the sites that can deadlock inside
> the allocator, even though many of them seem to have fallback code.
> My reasoning here is that if you *have* an exit strategy for failing
> allocations that is smarter than hanging, we should probably use that.

We already do that for allocations where we can handle failure in
GFP_NOFS conditions. It is, however, somewhat useless if we can't
tell the allocator to try really hard if we've already had a failure
and we are already in memory reclaim conditions (e.g. a shrinker
trying to clean dirty objects so they can be reclaimed).

>From that perspective, I think that this patch set aims force us
away from handling fallbacks ourselves because a) it makes GFP_NOFS
more likely to fail, and b) provides no mechanism to "try harder"
when we really need the allocation to succeed.

> > >  mm: page_alloc: emergency reserve access for __GFP_NOFAIL allocations
> > > 
> > > An exacerbation of the victim-stuck-behind-allocation scenario are
> > > __GFP_NOFAIL allocations, because they will actually deadlock.  To
> > > avoid this, or try to, give __GFP_NOFAIL allocations access to not
> > > just the OOM reserves but also the system's emergency reserves.
> > > 
> > > This is basically a poor man's reservation system, which could or
> > > should be replaced later on with an explicit reservation system that
> > > e.g. filesystems have control over for use by transactions.
> > > 
> > > It's obviously not bulletproof and might still lock up, but it should
> > > greatly reduce the likelihood.  AFAIK Andrea, whose idea this was, has
> > > been using this successfully for some time.
> > 
> > So, if we want GFP_NOFS allocations to be able to dip into a
> > small extra reservation to make progress at ENOMEM, we have to use
> > use __GFP_NOFAIL because looping ourselves won't allow use of these
> > extra reserves?
> 
> As I said, this series is not about providing reserves just yet.  It
> is about using the fallback strategies you already implemented.  And
> where you don't have any, it's about making the allocator's last way
> of forward progress, the OOM killer, more reliable.

Sure - but you're doing that by adding a special reserve for
GFP_NOFAIL allocations to dip into when the OOM killer is active.
That can only be accessed by GFP_NOFAIL allocations - anyone who
has a fallback but really needs the allocation to succeed if at all
possible (i.e. should only fail to avoid a deadlock situation) can't
communicate that fact to the allocator



> > > This patch makes NOFS allocations fail if reclaim can't free anything.
> > > 
> > > It would be good if the filesystem people could weigh in on whether
> > > they can deal with failing GFP_NOFS allocations, or annotate the
> > > exceptions with __GFP_NOFAIL etc.  It could well be that a middle
> > > ground is required that allows using the OOM killer before giving up.
> > 
> > ... which looks to me like a catch-22 situation for us: We
> > have reserves, but callers need to use __GFP_NOFAIL to access them.
> > GFP_NOFS is going to fail more often, so callers need to handle that
> > in some way, either by looping or erroring out.
> > 
> > But if we loop manually because we try to handle ENOMEM situations
> > gracefully (e.g. try a number of times before erroring out) we can't
> > dip into the reserves because the only semantics being provided are
> > "try-once-without-reserves" or "try-forever-with-reserves".  i.e.
> > what we actually need here is "try-once-with-reserves" semantics 

Re: [PATCH 2/3] toshiba_acpi: Fix typos in pr_* messages from USB Fleep Functions

[Azael Avalos]

Hi Darren,

2015-03-27 20:58 GMT-06:00 Darren Hart :
> On Fri, Mar 27, 2015 at 03:09:25PM -0600, Azael Avalos wrote:
>> This patch fixes typos in the pr_* messages from the USB Sleep
>> Functions.
>>
>> Signed-off-by: Azael Avalos 
>> ---
>>  drivers/platform/x86/toshiba_acpi.c | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/platform/x86/toshiba_acpi.c 
>> b/drivers/platform/x86/toshiba_acpi.c
>> index 595f12c..3bb456c 100644
>> --- a/drivers/platform/x86/toshiba_acpi.c
>> +++ b/drivers/platform/x86/toshiba_acpi.c
>> @@ -955,11 +955,11 @@ static int toshiba_usb_rapid_charge_get(struct 
>> toshiba_acpi_dev *dev,
>>   status = tci_raw(dev, in, out);
>>   sci_close(dev);
>>   if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
>> - pr_err("ACPI call to get USB S battery level failed\n");
>> + pr_err("ACPI call to get USB Rapid Charge failed\n");
>>   return -EIO;
>>   } else if (out[0] == TOS_NOT_SUPPORTED ||
>>  out[0] == TOS_INPUT_DATA_ERROR) {
>> - pr_info("USB Sleep and Charge not supported\n");
>> + pr_info("USB Rapid Charge not supported\n");
>
> This is a name change, not a typo fix. You added a comment in 1/3 using Sleep
> and Charge, should this patch perhaps come first?
>
> Or... hrm... this is using the correct name for each state, and 1/3 added 
> Sleep
> and Charge to the correct one... right, probably just need a better commit
> message. Not a type, but fixing the messages reporting the wrong states.

Ok, will change in v2 and resend in a few minutes.

>
> --
> Darren Hart
> Intel Open Source Technology Center


Cheers
Azael


-- 
-- El mundo apesta y vosotros apestais tambien --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] toshiba_acpi: Update and fix USB Sleep and Charge modes

[Azael Avalos]

Hi Darren,


2015-03-27 20:53 GMT-06:00 Darren Hart :
> On Fri, Mar 27, 2015 at 03:09:24PM -0600, Azael Avalos wrote:
>> This patch fixes the USB Sleep and Charge mode on certain models
>> where the value returned by the BIOS is different, and thus, making
>> this feature not to work for those models.
>>
>> Also, the "Typical" charging mode was added as a supported mode.
>
> What does typical mean?

Can't really help you here :-(

Toshiba does not provide specifics as to what each mode does or
represent, they simply state that if one mode does not work, try
another...

There are more charging modes but I will add them as soon as I
find their values, the following list the charging modes currently
not known.

- Mode 1
- Mode 2
- Tablet

One can infer what the "Tablet" mode does, but as for the rest...

>
>>
>> Signed-off-by: Azael Avalos 
>> ---
>>  drivers/platform/x86/toshiba_acpi.c | 61 
>> +++--
>>  1 file changed, 52 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/platform/x86/toshiba_acpi.c 
>> b/drivers/platform/x86/toshiba_acpi.c
>> index 17a259e..595f12c 100644
>> --- a/drivers/platform/x86/toshiba_acpi.c
>> +++ b/drivers/platform/x86/toshiba_acpi.c
>> @@ -150,9 +150,10 @@ MODULE_LICENSE("GPL");
>>  #define SCI_KBD_MODE_OFF 0x10
>>  #define SCI_KBD_TIME_MAX 0x3c001a
>>  #define SCI_USB_CHARGE_MODE_MASK 0xff
>> -#define SCI_USB_CHARGE_DISABLED  0x3
>> -#define SCI_USB_CHARGE_ALTERNATE 0x30009
>> -#define SCI_USB_CHARGE_AUTO  0x30021
>> +#define SCI_USB_CHARGE_DISABLED  0x00
>> +#define SCI_USB_CHARGE_ALTERNATE 0x09
>> +#define SCI_USB_CHARGE_TYPICAL   0x11
>> +#define SCI_USB_CHARGE_AUTO  0x21
>>  #define SCI_USB_CHARGE_BAT_MASK  0x7
>>  #define SCI_USB_CHARGE_BAT_LVL_OFF   0x1
>>  #define SCI_USB_CHARGE_BAT_LVL_ON0x4
>> @@ -177,6 +178,7 @@ struct toshiba_acpi_dev {
>>   int kbd_mode;
>>   int kbd_time;
>>   int usbsc_bat_level;
>> + int usbsc_mode_base;
>>   int hotkey_event_type;
>>
>>   unsigned int illumination_supported:1;
>> @@ -800,6 +802,44 @@ static int toshiba_accelerometer_get(struct 
>> toshiba_acpi_dev *dev,
>>  }
>>
>>  /* Sleep (Charge and Music) utilities support */
>> +static void toshiba_usb_sleep_charge_available(struct toshiba_acpi_dev *dev)
>> +{
>> + u32 in[TCI_WORDS] = { SCI_GET, SCI_USB_SLEEP_CHARGE, 0, 0, 0, 0 };
>> + u32 out[TCI_WORDS];
>> + acpi_status status;
>> +
>> + if (!sci_open(dev))
>> + return;
>> +
>
> Hrm, might be a good idea to set usb_sleep_charge_supported to 0 first so if 
> we
> error out here, it is disabled.

Ok, will do in v2.

>
>> + status = tci_raw(dev, in, out);
>> + if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
>> + pr_err("ACPI call to get USB S mode failed\n");
>> + sci_close(dev);
>> + return;
>> + } else if (out[0] == TOS_NOT_SUPPORTED) {
>> + pr_info("USB Sleep and Charge not supported\n");
>> + sci_close(dev);
>> + return;
>> + }
>> + dev->usbsc_mode_base = out[4];
>> +
>> + in[5] = SCI_USB_CHARGE_BAT_LVL;
>> + status = tci_raw(dev, in, out);
>> + if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
>> + pr_err("ACPI call to get USB S battery level failed\n");
>
> Sleep and Charge here too please. This keeps it consistent with the other
> messages as well as explicit for those who may not map S to Sleep and 
> Charge.

Ok, will do in v2.

>
>> + sci_close(dev);
>> + return;
>> + } else if (out[0] == TOS_NOT_SUPPORTED) {
>> + pr_info("USB Sleep and Charge not supported\n");
>> + sci_close(dev);
>> + return;
>> + }
>> + dev->usbsc_bat_level = out[2];
>> + dev->usb_sleep_charge_supported = 1;
>> +
>> + sci_close(dev);
>> +}
>> +
>>  static int toshiba_usb_sleep_charge_get(struct toshiba_acpi_dev *dev,
>>   u32 *mode)
>>  {
>> @@ -1976,17 +2016,21 @@ static ssize_t usb_sleep_charge_store(struct device 
>> *dev,
>>* 0 - Disabled
>>* 1 - Alternate (Non USB conformant devices that require more power)
>>* 2 - Auto (USB conformant devices)
>> +  * 3 - Typical
>>*/
>> - if (state != 0 && state != 1 && state != 2)
>> + if (state != 0 && state != 1 && state != 2 && state != 3)
>>   return -EINVAL;
>>
>>   /* Set the USB charging mode to internal value */
>> + mode = toshiba->usbsc_mode_base;
>>   if (state == 0)
>> - mode = SCI_USB_CHARGE_DISABLED;
>> + mode |= SCI_USB_CHARGE_DISABLED;
>>   else if (state == 1)
>> - mode = SCI_USB_CHARGE_ALTERNATE;
>> + mode |= SCI_USB_CHARGE_ALTERNATE;
>>   else if (state == 2)
>> - mode = SCI_USB_CHARGE_AUTO;
>> + mode |= SCI_USB_CHARGE_AUTO;

[PATCH] kvm: mmu: lazy collapse small sptes into large sptes

[Wanpeng Li]

There are two scenarios for the requirement of collapsing small sptes
into large sptes.
- dirty logging tracks sptes in 4k granularity, so large sptes are splitted,
  the large sptes will be reallocated in the destination machine and the
  guest in the source machine will be destroyed when live migration 
successfully.
  However, the guest in the source machine will continue to run if live 
migration
  fail due to some reasons, the sptes still keep small which lead to bad
  performance.
- our customers write tools to track the dirty speed of guests by EPT D bit/PML
  in order to determine the most appropriate one to be live migrated, however
  sptes will still keep small after tracking dirty speed.

This patch introduce lazy collapse small sptes into large sptes, the memory 
region 
will be scanned on the ioctl context when dirty log is stopped, the ones which 
can 
be collapsed into large pages will be dropped during the scan, it depends the 
on 
later #PF to reallocate all large sptes.

Signed-off-by: Wanpeng Li 
---
 arch/x86/include/asm/kvm_host.h |  2 ++
 arch/x86/kvm/mmu.c  | 66 +
 arch/x86/kvm/x86.c  |  5 
 3 files changed, 73 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a236e39..73de5d3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -859,6 +859,8 @@ void kvm_mmu_set_mask_ptes(u64 user_mask, u64 accessed_mask,
 void kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
 void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
  struct kvm_memory_slot *memslot);
+void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
+   struct kvm_memory_slot *memslot);
 void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
   struct kvm_memory_slot *memslot);
 void kvm_mmu_slot_largepage_remove_write_access(struct kvm *kvm,
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index cee7592..d25ced1 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4465,6 +4465,72 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
kvm_flush_remote_tlbs(kvm);
 }
 
+static int kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
+   unsigned long *rmapp)
+{
+   u64 *sptep;
+   struct rmap_iterator iter;
+   int need_tlb_flush = 0;
+   pfn_t pfn;
+   struct kvm_mmu_page *sp;
+
+   for (sptep = rmap_get_first(*rmapp, ); sptep;) {
+   BUG_ON(!(*sptep & PT_PRESENT_MASK));
+
+   sp = page_header(__pa(sptep));
+   pfn = spte_to_pfn(*sptep);
+   if (sp->role.direct &&
+   !kvm_is_reserved_pfn(pfn) &&
+   PageTransCompound(pfn_to_page(pfn))) {
+   drop_spte(kvm, sptep);
+   need_tlb_flush = 1;
+   }
+   sptep = rmap_get_next();
+   }
+
+   return need_tlb_flush;
+}
+
+void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
+   struct kvm_memory_slot *memslot)
+{
+   bool flush = false;
+   unsigned long *rmapp;
+   unsigned long last_index, index;
+   gfn_t gfn_start, gfn_end;
+
+   spin_lock(>mmu_lock);
+
+   gfn_start = memslot->base_gfn;
+   gfn_end = memslot->base_gfn + memslot->npages - 1;
+
+   if (gfn_start >= gfn_end)
+   goto out;
+
+   rmapp = memslot->arch.rmap[0];
+   last_index = gfn_to_index(gfn_end, memslot->base_gfn,
+   PT_PAGE_TABLE_LEVEL);
+
+   for (index = 0; index <= last_index; ++index, ++rmapp) {
+   if (*rmapp)
+   flush |= kvm_mmu_zap_collapsible_spte(kvm, rmapp);
+
+   if (need_resched() || spin_needbreak(>mmu_lock)) {
+   if (flush) {
+   kvm_flush_remote_tlbs(kvm);
+   flush = false;
+   }
+   cond_resched_lock(>mmu_lock);
+   }
+   }
+
+   if (flush)
+   kvm_flush_remote_tlbs(kvm);
+
+out:
+   spin_unlock(>mmu_lock);
+}
+
 void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
   struct kvm_memory_slot *memslot)
 {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5f7e03..6037389 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7618,6 +7618,11 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
/* It's OK to get 'new' slot here as it has already been installed */
new = id_to_memslot(kvm->memslots, mem->slot);
 
+   if ((change != KVM_MR_DELETE) &&
+   (old->flags & KVM_MEM_LOG_DIRTY_PAGES) &&
+   !(new->flags & KVM_MEM_LOG_DIRTY_PAGES))
+   kvm_mmu_zap_collapsible_sptes(kvm, new);
+
/*
 * Set up write protection and/or dirty 

Re: [PATCH 2/2] xen/grant: introduce func gnttab_unmap_refs_async_wait_completion()

[Bob Liu]

On 03/28/2015 08:44 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 26, 2015 at 04:32:45PM +0100, Roger Pau Monné wrote:
>> El 26/03/15 a les 13.16, Bob Liu ha escrit:
>>> There are several place using gnttab async unmap and wait for
>>> completion, so move the common code to a function
>>> gnttab_unmap_refs_async_wait_completion().
>>>
>>> Signed-off-by: Bob Liu 
>>
>> For the blkback parts:
>>
>> Acked-by: Roger Pau Monné 
>>
>> Although, as David already said, I think we should do better than BUG_ON
>> on error.
> 

This patch only keeps the existing behaviour the same as before. I
prefer to make new patches(based on this one) if want to change the
behaviour.

> Have an 'stuck deferred pages' list and an timer to occasionally
> flush them out? Something similar to 569ca5b3f94cd0b3295ec5943aa457cf4a4f6a3a
> "xen/gnttab: add deferred freeing logic" ?

Sounds like a good idea.

-- 
Regards,
-Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 56/86] intel/ixgb: use uapi/linux/pci_ids.h directly

[Jeff Kirsher]

On Sun, 2015-03-29 at 15:41 +0200, Michael S. Tsirkin wrote:
> Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h,
> use the new header directly so we can drop
> the wrapper in include/linux/pci_ids.h.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/net/ethernet/intel/ixgb/ixgb_hw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks Michael, I will add your patch to my queue.
-- 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
dev-queue


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

Re: [PATCH] ACPI/PMIC: Fix typo in MODULE_DESCRIPTION in intel_pmic_crc.c

[Rafael J. Wysocki]

On Wednesday, March 25, 2015 11:13:08 PM Masanari Iida wrote:
> This patch fix a spelling typo in MODULE_DESCRIPTION within intel_pmic_crc.c
> 
> Signed-off-by: Masanari Iida 

Queued up for 4.1, thanks!

> ---
>  drivers/acpi/pmic/intel_pmic_crc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/pmic/intel_pmic_crc.c 
> b/drivers/acpi/pmic/intel_pmic_crc.c
> index ef7d8ff..42df46a 100644
> --- a/drivers/acpi/pmic/intel_pmic_crc.c
> +++ b/drivers/acpi/pmic/intel_pmic_crc.c
> @@ -207,5 +207,5 @@ static int __init 
> intel_crc_pmic_opregion_driver_init(void)
>  }
>  module_init(intel_crc_pmic_opregion_driver_init);
>  
> -MODULE_DESCRIPTION("CrystalCove ACPI opration region driver");
> +MODULE_DESCRIPTION("CrystalCove ACPI operation region driver");
>  MODULE_LICENSE("GPL");
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] selftest/futex: Update Makefile to use lib.mk

[Michael Ellerman]

On Fri, 2015-03-27 at 15:17 -0700, Darren Hart wrote:
> Adapt the futextest Makefiles to use lib.mk macros for RUN_TESTS and
> EMIT_TESTS. For now, we reuse the run.sh mechanism provided by
> futextest. This doesn't provide the standard selftests: [PASS|FAIL]
> format, but the tests provide very similar output already.
> 
> This results in the run_kselftest.sh script for futexes including a
> single line: ./run.sh
> 
> Cc: Shuah Khan 
> Cc: linux-...@vger.kernel.org
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Davidlohr Bueso 
> Cc: KOSAKI Motohiro 
> Signed-off-by: Darren Hart 
> ---
>  tools/testing/selftests/futex/Makefile| 21 +
>  tools/testing/selftests/futex/functional/Makefile |  4 
>  2 files changed, 25 insertions(+)
> 
> diff --git a/tools/testing/selftests/futex/Makefile 
> b/tools/testing/selftests/futex/Makefile
> index 8629187..6a17529 100644
> --- a/tools/testing/selftests/futex/Makefile
> +++ b/tools/testing/selftests/futex/Makefile
> @@ -1,8 +1,29 @@
>  SUBDIRS := functional
>  
> +TEST_PROGS := run.sh
> +
>  .PHONY: all clean

lib.mk defines all & clean as PHONY for you.

>  all:
>   for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done
>  
> +include ../lib.mk
> +
> +override define RUN_TESTS
> + ./run.sh
> +endef

Do you need to do this override? The standard logic should work AFAICS, or do
you not want the echo logic?

> +override define INSTALL_RULE
> + mkdir -p $(INSTALL_PATH)
> + install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) 
> $(TEST_FILES)
> +
> + @for SUBDIR in $(SUBDIRS); do \
> + $(MAKE) -C $$SUBDIR INSTALL_PATH=$(INSTALL_PATH)/$$SUBDIR 
> install; \
> + done;
> +endef
> +
> +override define EMIT_TESTS
> + echo "./run.sh"
> +endef

Ditto.

cheers




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] kselftest: Add exit code defines

[Michael Ellerman]

On Fri, 2015-03-27 at 16:09 -0700, Darren Hart wrote:
> 
> On 3/27/15 3:59 PM, Michael Ellerman wrote:
> > On Fri, 2015-03-27 at 15:17 -0700, Darren Hart wrote:
> >> Define the exit codes with KSFT_PASS and similar so tests can use these
> >> directly if they choose. Also enable harnesses and other tooling to use
> >> the defines instead of hardcoding the return codes.
> >  
> > +1
> > 
> >> diff --git a/tools/testing/selftests/kselftest.h 
> >> b/tools/testing/selftests/kselftest.h
> >> index 572c888..ef1c80d 100644
> >> --- a/tools/testing/selftests/kselftest.h
> >> +++ b/tools/testing/selftests/kselftest.h
> >> @@ -13,6 +13,13 @@
> >>  #include 
> >>  #include 
> >>  
> >> +/* define kselftest exit codes */
> >> +#define KSFT_PASS  0
> >> +#define KSFT_FAIL  1
> >> +#define KSFT_XFAIL 2
> >> +#define KSFT_XPASS 3
> >> +#define KSFT_SKIP  4
> >> +
> >>  /* counters */
> >>  struct ksft_count {
> >>unsigned int ksft_pass;
> >> @@ -40,23 +47,23 @@ static inline void ksft_print_cnts(void)
> >>  
> >>  static inline int ksft_exit_pass(void)
> >>  {
> >> -  exit(0);
> >> +  exit(KSFT_PASS);
> >>  }
> > 
> > Am I the only person who's bothered by the fact that these don't actually
> > return int?
> 
> That bothered me to, but I couldn't be bothered to go read the manuals
> apparently to come up with a compelling argument :-)

Yeah, obviously the compiler accepts it, but it's still a bit weird.

> I also think the ksft_exit* routines should go ahead and increment the
> counters (at least optionally) so we don't have to call two functions.

But the ksft_exit_*() routines exit, so there's no point incrementing the
counters. Unless they *also* print the counters before exiting?

To be honest I think we need to decide if the selftests are going to speak TAP
or xUnit or whatever, and then switch to that. In their current form these
helpers don't help much.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/11] staging: rtl8192e: Decrease nesting of rtllib_rx_auth_resp()

[Joe Perches]

On Mon, 2015-03-30 at 01:21 +0200, Mateusz Kulikowski wrote:
> On 30.03.2015 01:13, Joe Perches wrote:
> > On Mon, 2015-03-30 at 00:41 +0200, Mateusz Kulikowski wrote:
> >> Return from rtllib_rx_auth_resp() if auth_parse() fails.
> >> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
> >> b/drivers/staging/rtl8192e/rtllib_softmac.c
> > []
> >> +  /* Dummy wirless mode setting to avoid
> >> +   * encryption issue */
> > 
> > Please use the typical networking comment style
> > (and correct the typo too)
> > 
> > /* Dummy wireless mode setting to avoid
> >  * encryption issue
> >  */
> 
> It was like that already - is it ok with you if I fix all the comments (in 
> whole rtl8192e) in separate patch 
> (I can add it as #12 to v2) ?

Of course.

> > 
> >> +  if (bSupportNmode) {
> >> +  ieee->SetWirelessMode(ieee->dev,
> >> + ieee->current_network.mode);
> >> +  } else {
> >> +  /*TODO*/
> >> +  ieee->SetWirelessMode(ieee->dev,
> >> +IEEE_G);
> > 
> > Many of these multiple line statements can be single line.
> 
> I wanted to split change of logic and re-indentation;
> If you insist - I can merge patches #10 and #11 (#11 does what you ask for)

No worries, do what you think appropriate.
I think it's appropriate to fix one way or another.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sched/deadline: Use IPI to trigger DL task push migration instead of pulling

[Wanpeng Li]

This design the same as rt class to send out only one IPI to the 
first overloaded CPU. It tries to push any tasks that it can, and 
then looks for the next overloaded CPU that can push to the source 
CPU. The IPIs stop when all overloaded CPUs that have pushable tasks 
that have deadlines earlier than the source CPU are covered. In case 
the source CPU has later deadline again, a flag is set to tell the 
IPI traversal to restart with the first RT overloaded CPU after the 
source CPU.

Signed-off-by: Wanpeng Li 
---
 kernel/sched/deadline.c | 177 
 kernel/sched/sched.h|   6 ++
 2 files changed, 183 insertions(+)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 24c18dc..4d203e0 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -17,6 +17,7 @@
 #include "sched.h"
 
 #include 
+#include 
 
 struct dl_bandwidth def_dl_bandwidth;
 
@@ -69,6 +70,10 @@ void init_dl_bw(struct dl_bw *dl_b)
dl_b->total_bw = 0;
 }
 
+#ifdef CONFIG_SMP
+static void push_irq_work_func(struct irq_work *work);
+#endif
+
 void init_dl_rq(struct dl_rq *dl_rq, struct rq *rq)
 {
dl_rq->rb_root = RB_ROOT;
@@ -80,6 +85,12 @@ void init_dl_rq(struct dl_rq *dl_rq, struct rq *rq)
dl_rq->dl_nr_migratory = 0;
dl_rq->overloaded = 0;
dl_rq->pushable_dl_tasks_root = RB_ROOT;
+#ifdef HAVE_RT_PUSH_IPI
+   dl_rq->push_flags = 0;
+   dl_rq->push_cpu = nr_cpu_ids;
+   raw_spin_lock_init(_rq->push_lock);
+   init_irq_work(_rq->push_work, push_irq_work_func);
+#endif
 #else
init_dl_bw(_rq->dl_bw);
 #endif
@@ -1416,6 +1427,165 @@ static void push_dl_tasks(struct rq *rq)
;
 }
 
+#ifdef HAVE_RT_PUSH_IPI
+/*
+ * The search for the next cpu always starts at rq->cpu and ends
+ * when we reach rq->cpu again. It will never return rq->cpu.
+ * This returns the next cpu to check, or nr_cpu_ids if the loop
+ * is complete.
+ *
+ * rq->dl.push_cpu holds the last cpu returned by this function,
+ * or if this is the first instance, it must hold rq->cpu.
+ */
+static int dlo_next_cpu(struct rq *rq)
+{
+   int prev_cpu = rq->dl.push_cpu;
+   int cpu;
+
+   cpu = cpumask_next(prev_cpu, rq->rd->dlo_mask);
+
+   /*
+* If the previous cpu is less than the rq's CPU, then it already
+* passed the end of the mask, and has started from the beginning.
+* We end if the next CPU is greater or equal to rq's CPU.
+*/
+   if (prev_cpu < rq->cpu) {
+   if (cpu >= rq->cpu)
+   return nr_cpu_ids;
+
+   } else if (cpu >= nr_cpu_ids) {
+   /*
+* We passed the end of the mask, start at the beginning.
+* If the result is greater or equal to the rq's CPU, then
+* the loop is finished.
+*/
+   cpu = cpumask_first(rq->rd->dlo_mask);
+   if (cpu >= rq->cpu)
+   return nr_cpu_ids;
+   }
+   rq->dl.push_cpu = cpu;
+
+   /* Return cpu to let the caller know if the loop is finished or not */
+   return cpu;
+}
+
+static int find_next_push_cpu(struct rq *rq)
+{
+   struct rq *next_rq;
+   int cpu;
+
+   while (1) {
+   cpu = dlo_next_cpu(rq);
+   if (cpu >= nr_cpu_ids)
+   break;
+   next_rq = cpu_rq(cpu);
+
+   /* Make sure the next rq can push to this rq */
+   if (dl_time_before(next_rq->dl.earliest_dl.next,
+   rq->dl.earliest_dl.curr))
+   break;
+   }
+
+   return cpu;
+}
+
+#define RT_PUSH_IPI_EXECUTING  1
+#define RT_PUSH_IPI_RESTART2
+
+static void tell_cpu_to_push(struct rq *rq)
+{
+   int cpu;
+
+   if (rq->dl.push_flags & RT_PUSH_IPI_EXECUTING) {
+   raw_spin_lock(>dl.push_lock);
+   /* Make sure it's still executing */
+   if (rq->dl.push_flags & RT_PUSH_IPI_EXECUTING) {
+   /*
+* Tell the IPI to restart the loop as things have
+* changed since it started.
+*/
+   rq->dl.push_flags |= RT_PUSH_IPI_RESTART;
+   raw_spin_unlock(>dl.push_lock);
+   return;
+   }
+   raw_spin_unlock(>dl.push_lock);
+   }
+
+   /* When here, there's no IPI going around */
+
+   rq->dl.push_cpu = rq->cpu;
+   cpu = find_next_push_cpu(rq);
+   if (cpu >= nr_cpu_ids)
+   return;
+
+   rq->dl.push_flags = RT_PUSH_IPI_EXECUTING;
+
+   irq_work_queue_on(>dl.push_work, cpu);
+}
+
+/* Called from hardirq context */
+static void try_to_push_tasks(void *arg)
+{
+   struct dl_rq *dl_rq = arg;
+   struct rq *rq, *src_rq;
+   int this_cpu;
+   int cpu;
+
+   this_cpu = dl_rq->push_cpu;
+
+   /* 

Re: [PATCH 10/11] staging: rtl8192e: Decrease nesting of rtllib_rx_auth_resp()

[Mateusz Kulikowski]

Hi Joe, 

Thanks for reviewing my patches.

On 30.03.2015 01:13, Joe Perches wrote:
> On Mon, 2015-03-30 at 00:41 +0200, Mateusz Kulikowski wrote:
>> Return from rtllib_rx_auth_resp() if auth_parse() fails.
> 
> Hello Mateusz.  Here are some trivial notes.
> 
>> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
>> b/drivers/staging/rtl8192e/rtllib_softmac.c
> []
>> +/* Dummy wirless mode setting to avoid
>> + * encryption issue */
> 
> Please use the typical networking comment style
> (and correct the typo too)
> 
>   /* Dummy wireless mode setting to avoid
>* encryption issue
>*/

It was like that already - is it ok with you if I fix all the comments (in 
whole rtl8192e) in separate patch 
(I can add it as #12 to v2) ?

> 
>> +if (bSupportNmode) {
>> +ieee->SetWirelessMode(ieee->dev,
>> +   ieee->current_network.mode);
>> +} else {
>> +/*TODO*/
>> +ieee->SetWirelessMode(ieee->dev,
>> +  IEEE_G);
> 
> Many of these multiple line statements can be single line.

I wanted to split change of logic and re-indentation;
If you insist - I can merge patches #10 and #11 (#11 does what you ask for)


Regards,
Mateusz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14] sched/deadline: support dl task migration during cpu hotplug

[Wanpeng Li]

Ping Ingo, ;)
On Fri, Mar 27, 2015 at 07:08:35AM +0800, Wanpeng Li wrote:
>I observe that dl task can't be migrated to other cpus during cpu hotplug,
>in addition, task may/may not be running again if cpu is added back. The
>root cause which I found is that dl task will be throtted and removed from
>dl rq after comsuming all budget, which leads to stop task can't pick it up
>from dl rq and migrate to other cpus during hotplug.
>
>The method to reproduce:
>schedtool -E -t 5:10 -e ./test
>Actually test is just a simple for loop. Then observe which cpu the test
>task is on.
>echo 0 > /sys/devices/system/cpu/cpuN/online
>
>This patch adds the dl task migration during cpu hotplug by finding a most
>suitable later deadline rq after dl timer fire if current rq is offline,
>if fail to find a suitable later deadline rq then fallback to any eligible
>online cpu in order that the deadline task will come back to us, and the
>push/pull mechanism should then move it around properly.
>
>Suggested-and-acked-by: Juri Lelli 
>Signed-off-by: Wanpeng Li 
>---
>v13 -> 14:
> * have better naming
> * simply the BUG_ON part
>v12 -> 13:
> * move hotplug stuff to CONFIG_SMP in order to fix the error reported by 
> kbuild test robot
>v11 -> v12:
> * s/WARN_ON/BUG_ON
>v10 -> v11:
> * fix codes comments
> * tsk_cpus_allowed(p) shouldn't be on separate lines
> * introduce a helper function to fold dl task migration during cpu hotplug 
> support
>v9 -> v10:
> * fix the "WARNING: line over 80 characters"
> * handle no admission control
>v8 -> v9:
> * align tsk_cpus_allowed(p) to cpu_active_mask
> * add WARN_ON(1)
> * don't resched_curr if later_rq come from the cpumask_any_and()
>v7 -> v8:
> * remove rd->span related modification since Pang's commit 16b269436b72
>   (sched/deadline: Modify cpudl::free_cpus to reflect rd->online) merged
>   upstream, which Juri pointed out can handle the exclusive cpusets.
> * rebase
>v6 -> v7:
> * rebase
>v5 -> v6:
> * add double_lock_balance in the fallback path
>v4 -> v5:
> * remove raw_spin_unlock(>lock)
> * cleanup codes, spotted by Peterz
> * cleanup patch description
>v3 -> v4:
> * use tsk_cpus_allowed wrapper
> * fix compile error
>v2 -> v3:
> * don't get_task_struct
> * if cannot preempt any rq, fallback to pick any online cpus
> * use cpu_active_mask as original later_mask if cpu is offline
>v1 -> v2:
> * push the task to another cpu in dl_task_timer() if rq is offline.
>
> kernel/sched/deadline.c | 57 +
> 1 file changed, 57 insertions(+)
>
>diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
>index 24c18dc..12eb314 100644
>--- a/kernel/sched/deadline.c
>+++ b/kernel/sched/deadline.c
>@@ -218,6 +218,52 @@ static inline void set_post_schedule(struct rq *rq)
>   rq->post_schedule = has_pushable_dl_tasks(rq);
> }
> 
>+static struct rq *find_lock_later_rq(struct task_struct *task, struct rq *rq);
>+
>+static void dl_task_offline_migration(struct rq *rq, struct task_struct *p)
>+{
>+  struct rq *later_rq = NULL;
>+  bool fallback = false;
>+
>+  later_rq = find_lock_later_rq(p, rq);
>+
>+  if (!later_rq) {
>+  int cpu;
>+
>+  /*
>+   * If we cannot preempt any rq, fall back to pick any
>+   * online cpu.
>+   */
>+  fallback = true;
>+  cpu = cpumask_any_and(cpu_active_mask, tsk_cpus_allowed(p));
>+  if (cpu >= nr_cpu_ids) {
>+  /*
>+   * Fail to find any suitable cpu.
>+   * The task will never come back!
>+   */
>+  BUG_ON(dl_bandwidth_enabled());
>+
>+  /*
>+   * If admission control is disabled we
>+   * try a little harder to let the task
>+   * run.
>+   */
>+  cpu = cpumask_any(cpu_active_mask);
>+  }
>+  later_rq = cpu_rq(cpu);
>+  double_lock_balance(rq, later_rq);
>+  }
>+
>+  deactivate_task(rq, p, 0);
>+  set_task_cpu(p, later_rq->cpu);
>+  activate_task(later_rq, p, ENQUEUE_REPLENISH);
>+
>+  if (!fallback)
>+  resched_curr(later_rq);
>+
>+  double_unlock_balance(rq, later_rq);
>+}
>+
> #else
> 
> static inline
>@@ -536,6 +582,17 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
>*timer)
>   sched_clock_tick();
>   update_rq_clock(rq);
> 
>+#ifdef CONFIG_SMP
>+  /*
>+   * If we find that the rq the task was on is no longer
>+   * available, we need to select a new rq.
>+   */
>+  if (unlikely(!rq->online)) {
>+  dl_task_offline_migration(rq, p);
>+  goto unlock;
>+  }
>+#endif
>+
>   /*
>* If the throttle happened during sched-out; like:
>*
>-- 
>1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 

Re: [PATCH 37/86] firewire/ohci: use uapi/linux/pci_ids.h directly

[Stefan Richter]

On Mar 29 Michael S. Tsirkin wrote:
> Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h,
> use the new header directly so we can drop
> the wrapper in include/linux/pci_ids.h.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/firewire/ohci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
> index f51d376..131076b 100644
> --- a/drivers/firewire/ohci.c
> +++ b/drivers/firewire/ohci.c
> @@ -36,7 +36,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 

As mentioned in my reply to 00/86, this does not seem useful to me.
-- 
Stefan Richter
-=-= --== -
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups

[Stefan Richter]

On Mar 29 Michael S. Tsirkin wrote:
> The macros in pci_ids.h are pretty useful for userspace
> using the pci sysfs interface, e.g. to decode class
> device and vendor sysfs files.
> 
> At the moment userspace is forced to duplicate these macros (e.g. QEMU does
> this, so does gpxe, seabios, etc), it is better to export them in
> /usr/include/linux/pci_ids.h so everyone can just include this header.
> 
> This patchset is structured as follows:
> 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h;
>a stub file is created in include/linux/pci_ids.h to avoid breaking
>bisect

Since linux' include/linux/pci_ids.h is incomplete, I am doubtful that it
is appropriate for userspace.

> 2. all users are converted to use the new header

This step should not be necessary.  It has not been done with other
headers which were moved to include/uapi.

> 3. include/linux/pci_ids.h is removed
> 4. cleanups for several issues detected during step 2

-- 
Stefan Richter
-=-= --== -
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/11] staging: rtl8192e: Decrease nesting of rtllib_rx_auth_resp()

[Joe Perches]

On Mon, 2015-03-30 at 00:41 +0200, Mateusz Kulikowski wrote:
> Return from rtllib_rx_auth_resp() if auth_parse() fails.

Hello Mateusz.  Here are some trivial notes.

> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
> b/drivers/staging/rtl8192e/rtllib_softmac.c
[]
> + /* Dummy wirless mode setting to avoid
> +  * encryption issue */

Please use the typical networking comment style
(and correct the typo too)

/* Dummy wireless mode setting to avoid
 * encryption issue
 */

> + if (bSupportNmode) {
> + ieee->SetWirelessMode(ieee->dev,
> +ieee->current_network.mode);
> + } else {
> + /*TODO*/
> + ieee->SetWirelessMode(ieee->dev,
> +   IEEE_G);

Many of these multiple line statements can be single line.

> + }
> +
> + if (ieee->current_network.mode ==
> + IEEE_N_24G && bHalfSupportNmode) {
> + netdev_info(ieee->dev,
> + "==>enter half N mode\n");
> + ieee->bHalfWirelessN24GMode =
> +  true;
> + } else
> + ieee->bHalfWirelessN24GMode =
> +  false;

Single line and better with braces.

> +
> + rtllib_associate_step2(ieee);
> + } else {
> + rtllib_auth_challenge(ieee, challenge,
> +   chlen);
>   }
>  }

Single line.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/11] staging: rtl8192e: Fix UNNECESSARY_ELSE warning

[Mateusz Kulikowski]

Fix checkpatch warnings 'else is not generally useful after a break or return'

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c |  72 +++---
 drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c |  10 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_cam.c|   7 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c   | 213 -
 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 307 -
 drivers/staging/rtl8192e/rtl8192e/rtl_ps.c |   9 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_wx.c |  24 +-
 drivers/staging/rtl8192e/rtl819x_HTProc.c  |  31 ++-
 drivers/staging/rtl8192e/rtl819x_TSProc.c  | 120 +-
 drivers/staging/rtl8192e/rtllib_rx.c   | 118 +-
 drivers/staging/rtl8192e/rtllib_softmac.c  |  11 +-
 drivers/staging/rtl8192e/rtllib_tx.c   |  78 ---
 12 files changed, 482 insertions(+), 518 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index 170ff12..9222e42 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -2025,6 +2025,7 @@ bool rtl8192_rx_query_status_desc(struct net_device *dev,
  struct sk_buff *skb)
 {
struct r8192_priv *priv = rtllib_priv(dev);
+   struct rx_fwinfo *pDrvInfo = NULL;
 
stats->bICV = pdesc->ICV;
stats->bCRC = pdesc->CRC32;
@@ -2046,51 +2047,49 @@ bool rtl8192_rx_query_status_desc(struct net_device 
*dev,
priv->stats.rxcrcerrmid++;
}
return false;
-   } else {
-   struct rx_fwinfo *pDrvInfo = NULL;
+   }
 
-   stats->RxDrvInfoSize = pdesc->RxDrvInfoSize;
-   stats->RxBufShift = ((pdesc->Shift)&0x03);
-   stats->Decrypted = !pdesc->SWDec;
+   stats->RxDrvInfoSize = pdesc->RxDrvInfoSize;
+   stats->RxBufShift = ((pdesc->Shift)&0x03);
+   stats->Decrypted = !pdesc->SWDec;
 
-   pDrvInfo = (struct rx_fwinfo *)(skb->data + stats->RxBufShift);
+   pDrvInfo = (struct rx_fwinfo *)(skb->data + stats->RxBufShift);
 
-   stats->rate = HwRateToMRate90((bool)pDrvInfo->RxHT,
-(u8)pDrvInfo->RxRate);
-   stats->bShortPreamble = pDrvInfo->SPLCP;
+   stats->rate = HwRateToMRate90((bool)pDrvInfo->RxHT,
+(u8)pDrvInfo->RxRate);
+   stats->bShortPreamble = pDrvInfo->SPLCP;
 
-   rtl8192_UpdateReceivedRateHistogramStatistics(dev, stats);
+   rtl8192_UpdateReceivedRateHistogramStatistics(dev, stats);
 
-   stats->bIsAMPDU = (pDrvInfo->PartAggr == 1);
-   stats->bFirstMPDU = (pDrvInfo->PartAggr == 1) &&
-   (pDrvInfo->FirstAGGR == 1);
+   stats->bIsAMPDU = (pDrvInfo->PartAggr == 1);
+   stats->bFirstMPDU = (pDrvInfo->PartAggr == 1) &&
+   (pDrvInfo->FirstAGGR == 1);
 
-   stats->TimeStampLow = pDrvInfo->TSFL;
-   stats->TimeStampHigh = read_nic_dword(dev, TSFR+4);
+   stats->TimeStampLow = pDrvInfo->TSFL;
+   stats->TimeStampHigh = read_nic_dword(dev, TSFR+4);
 
-   rtl819x_UpdateRxPktTimeStamp(dev, stats);
+   rtl819x_UpdateRxPktTimeStamp(dev, stats);
 
-   if ((stats->RxBufShift + stats->RxDrvInfoSize) > 0)
-   stats->bShift = 1;
+   if ((stats->RxBufShift + stats->RxDrvInfoSize) > 0)
+   stats->bShift = 1;
 
-   stats->RxIs40MHzPacket = pDrvInfo->BW;
+   stats->RxIs40MHzPacket = pDrvInfo->BW;
 
-   rtl8192_TranslateRxSignalStuff(dev, skb, stats, pdesc,
-  pDrvInfo);
+   rtl8192_TranslateRxSignalStuff(dev, skb, stats, pdesc,
+  pDrvInfo);
 
-   if (pDrvInfo->FirstAGGR == 1 || pDrvInfo->PartAggr == 1)
-   RT_TRACE(COMP_RXDESC,
-"pDrvInfo->FirstAGGR = %d, pDrvInfo->PartAggr 
= %d\n",
-pDrvInfo->FirstAGGR, pDrvInfo->PartAggr);
-   skb_trim(skb, skb->len - 4/*sCrcLng*/);
+   if (pDrvInfo->FirstAGGR == 1 || pDrvInfo->PartAggr == 1)
+   RT_TRACE(COMP_RXDESC,
+"pDrvInfo->FirstAGGR = %d, pDrvInfo->PartAggr = %d\n",
+pDrvInfo->FirstAGGR, pDrvInfo->PartAggr);
+   skb_trim(skb, skb->len - 4/*sCrcLng*/);
 
 
-   stats->packetlength = stats->Length-4;
-   stats->fraglength = stats->packetlength;
-   stats->fragoffset = 0;
-   stats->ntotalfrag = 1;
-   return true;
-   }
+   stats->packetlength = stats->Length-4;
+   stats->fraglength = stats->packetlength;
+   stats->fragoffset = 0;
+   

[PATCH 02/11] staging: rtl8192e: Fix RETURN_VOID warnings

[Mateusz Kulikowski]

Fix 'void function return statements are not generally useful'
checkpatch.pl warnings

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 2 --
 drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 8 
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c   | 7 ---
 drivers/staging/rtl8192e/rtllib_rx.c   | 1 -
 drivers/staging/rtl8192e/rtllib_softmac.c  | 1 -
 5 files changed, 19 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index 9222e42..cb74e55 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -2137,7 +2137,6 @@ void rtl8192_halt_adapter(struct net_device *dev, bool 
reset)
skb_queue_purge(>rtllib->skb_aggQ[i]);
 
skb_queue_purge(>skb_queue);
-   return;
 }
 
 void rtl8192_update_ratr_table(struct net_device *dev)
@@ -2415,5 +2414,4 @@ void ActUpdateChannelAccessSetting(struct net_device *dev,
enum wireless_mode WirelessMode,
struct channel_access_setting *ChnlAccessSetting)
 {
-   return;
 }
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
index 312979f..28b44c9 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c
@@ -94,7 +94,6 @@ void rtl8192_setBBreg(struct net_device *dev, u32 dwRegAddr, 
u32 dwBitMask,
write_nic_dword(dev, dwRegAddr, NewValue);
} else
write_nic_dword(dev, dwRegAddr, dwData);
-   return;
 }
 
 u32 rtl8192_QueryBBReg(struct net_device *dev, u32 dwRegAddr, u32 dwBitMask)
@@ -215,7 +214,6 @@ static void rtl8192_phy_RFSerialWrite(struct net_device 
*dev,
}
rtl8192_setBBreg(dev, rFPGA0_AnalogParameter4, 0x300, 0x3);
}
-   return;
 }
 
 void rtl8192_phy_SetRFReg(struct net_device *dev, enum rf90_radio_path eRFPath,
@@ -256,7 +254,6 @@ void rtl8192_phy_SetRFReg(struct net_device *dev, enum 
rf90_radio_path eRFPath,
} else
rtl8192_phy_RFSerialWrite(dev, eRFPath, RegAddr, Data);
}
-   return;
 }
 
 u32 rtl8192_phy_QueryRFReg(struct net_device *dev, enum rf90_radio_path 
eRFPath,
@@ -399,7 +396,6 @@ void rtl8192_phyConfigBB(struct net_device *dev, u8 
ConfigType)
 Rtl819XAGCTAB_Array_Table[i+1]);
}
}
-   return;
 }
 
 static void rtl8192_InitBBRFRegDef(struct net_device *dev)
@@ -640,7 +636,6 @@ void rtl8192_phy_getTxPower(struct net_device *dev)
RT_TRACE(COMP_INIT, "Default framesync (0x%x) = 0x%x\n",
rOFDM0_RxDetector3, priv->framesync);
priv->SifsTime = read_nic_word(dev, SIFS);
-   return;
 }
 
 void rtl8192_phy_setTxPower(struct net_device *dev, u8 channel)
@@ -694,7 +689,6 @@ void rtl8192_phy_setTxPower(struct net_device *dev, u8 
channel)
 __func__);
break;
}
-   return;
 }
 
 bool rtl8192_phy_RFConfig(struct net_device *dev)
@@ -723,7 +717,6 @@ bool rtl8192_phy_RFConfig(struct net_device *dev)
 
 void rtl8192_phy_updateInitGain(struct net_device *dev)
 {
-   return;
 }
 
 u8 rtl8192_phy_ConfigRFWithHeaderFile(struct net_device *dev,
@@ -813,7 +806,6 @@ static void rtl8192_SetTxPowerLevel(struct net_device *dev, 
u8 channel)
 "unknown rf chip ID in rtl8192_SetTxPowerLevel()\n");
break;
}
-   return;
 }
 
 static u8 rtl8192_phy_SetSwChnlCmdArray(struct sw_chnl_cmd *CmdTable,
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 5f3e28b..3308b0d 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -741,8 +741,6 @@ static void rtl8192_prepare_beacon(struct r8192_priv *priv)
priv->ops->tx_fill_descriptor(dev, pdesc, tcb_desc, pnewskb);
__skb_queue_tail(>queue, pnewskb);
pdesc->OWN = 1;
-
-   return;
 }
 
 static void rtl8192_stop_beacon(struct net_device *dev)
@@ -856,7 +854,6 @@ static void rtl8192_refresh_supportrate(struct r8192_priv 
*priv)
} else {
memset(ieee->Regdot11HTOperationalRateSet, 0, 16);
}
-   return;
 }
 
 static u8 rtl8192_getSupportedWireleeMode(struct net_device *dev)
@@ -1901,8 +1898,6 @@ void rtl8192_hard_data_xmit(struct sk_buff *skb, struct 
net_device *dev,
 priv->rtllib->tx_headroom);
priv->rtllib->stats.tx_packets++;
}
-
-   return;
 }
 
 int rtl8192_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -1985,8 +1980,6 @@ void rtl8192_tx_cmd(struct net_device *dev, struct 
sk_buff *skb)
 
__skb_queue_tail(>queue, skb);
spin_unlock_irqrestore(>irq_th_lock, flags);
-
-   return;
 }
 
 short 

[PATCH 04/11] staging: rtl8192e: Fix UNNECESSARY_PARENTHESES warnings

[Mateusz Kulikowski]

Fix 'Unnecessary parentheses' checkpatch.pl warning

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c |  4 ++--
 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c   | 12 ++--
 drivers/staging/rtl8192e/rtllib_rx.c |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 3308b0d..fb3cb01e 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -608,7 +608,7 @@ static int rtl8192_qos_handle_probe_response(struct 
r8192_priv *priv,
if (priv->rtllib->state != RTLLIB_LINKED)
return ret;
 
-   if ((priv->rtllib->iw_mode != IW_MODE_INFRA))
+   if (priv->rtllib->iw_mode != IW_MODE_INFRA)
return ret;
 
if (network->flags & NETWORK_HAS_QOS_MASK) {
@@ -669,7 +669,7 @@ static int rtl8192_qos_association_resp(struct r8192_priv 
*priv,
if (priv->rtllib->state != RTLLIB_LINKED)
return 0;
 
-   if ((priv->rtllib->iw_mode != IW_MODE_INFRA))
+   if (priv->rtllib->iw_mode != IW_MODE_INFRA)
return 0;
 
spin_lock_irqsave(>rtllib->lock, flags);
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index b26dfcb..df4bbcf 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -498,7 +498,7 @@ static void dm_TXPowerTrackingCallback_TSSI(struct 
net_device *dev)
write_nic_byte(dev, FW_Busy_Flag, 0);
return;
}
-   if ((priv->rtllib->eRFPowerState != eRfOn)) {
+   if (priv->rtllib->eRFPowerState != eRfOn) {
RT_TRACE(COMP_POWER_TRACKING,
 "we are in power save, so 
return\n");
write_nic_byte(dev, Pw_Track_Flag, 0);
@@ -1824,7 +1824,7 @@ static void dm_ctrl_initgain_byrssi_by_fwfalse_alarm(
if ((priv->undecorated_smoothed_pwdb > dm_digtable.rssi_low_thresh) &&
(priv->undecorated_smoothed_pwdb < 
dm_digtable.rssi_high_thresh))
return;
-   if ((priv->undecorated_smoothed_pwdb <= dm_digtable.rssi_low_thresh)) {
+   if (priv->undecorated_smoothed_pwdb <= dm_digtable.rssi_low_thresh) {
if (dm_digtable.dig_state == DM_STA_DIG_OFF &&
(priv->reset_count == reset_cnt))
return;
@@ -1850,7 +1850,7 @@ static void dm_ctrl_initgain_byrssi_by_fwfalse_alarm(
return;
}
 
-   if ((priv->undecorated_smoothed_pwdb >= dm_digtable.rssi_high_thresh)) {
+   if (priv->undecorated_smoothed_pwdb >= dm_digtable.rssi_high_thresh) {
u8 reset_flag = 0;
 
if (dm_digtable.dig_state == DM_STA_DIG_ON &&
@@ -1998,7 +1998,7 @@ static void dm_pd_th(struct net_device *dev)
if (dm_digtable.CurSTAConnectState == DIG_STA_CONNECT) {
if (dm_digtable.rssi_val >= 
dm_digtable.rssi_high_power_highthresh)
dm_digtable.curpd_thstate = 
DIG_PD_AT_HIGH_POWER;
-   else if ((dm_digtable.rssi_val <= 
dm_digtable.rssi_low_thresh))
+   else if (dm_digtable.rssi_val <= 
dm_digtable.rssi_low_thresh)
dm_digtable.curpd_thstate = DIG_PD_AT_LOW_POWER;
else if ((dm_digtable.rssi_val >= 
dm_digtable.rssi_high_thresh) &&
(dm_digtable.rssi_val < 
dm_digtable.rssi_high_power_lowthresh))
@@ -2055,9 +2055,9 @@ staticvoid dm_cs_ratio(struct net_device *dev)
 
if (dm_digtable.PreSTAConnectState == dm_digtable.CurSTAConnectState) {
if (dm_digtable.CurSTAConnectState == DIG_STA_CONNECT) {
-   if ((dm_digtable.rssi_val <= 
dm_digtable.rssi_low_thresh))
+   if (dm_digtable.rssi_val <= dm_digtable.rssi_low_thresh)
dm_digtable.curcs_ratio_state = 
DIG_CS_RATIO_LOWER;
-   else if ((dm_digtable.rssi_val >= 
dm_digtable.rssi_high_thresh))
+   else if (dm_digtable.rssi_val >= 
dm_digtable.rssi_high_thresh)
dm_digtable.curcs_ratio_state = 
DIG_CS_RATIO_HIGHER;
else
dm_digtable.curcs_ratio_state = 
dm_digtable.precs_ratio_state;
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c 
b/drivers/staging/rtl8192e/rtllib_rx.c
index e2a748b..c1711239 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -1166,7 +1166,7 @@ static void rtllib_rx_check_leave_lps(struct 

[PATCH 07/11] staging: rtl8192e: Fix DO_WHILE_MACRO_WITH_TRAILING_SEMICOLON warning

[Mateusz Kulikowski]

Fix 'do {} while (0) macros should not be semicolon terminated'
checkpatch.pl warning

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtllib_debug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192e/rtllib_debug.h 
b/drivers/staging/rtl8192e/rtllib_debug.h
index 90cffab..119729d 100644
--- a/drivers/staging/rtl8192e/rtllib_debug.h
+++ b/drivers/staging/rtl8192e/rtllib_debug.h
@@ -83,6 +83,6 @@ do {  \
pr_info("Assertion failed! %s,%s,%s,line=%d\n", \
#expr, __FILE__, __func__, __LINE__); \
}   \
-} while (0);
+} while (0)
 
 #endif
-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/11] staging: rtl8192e: Divide rtllib_rx_auth()

[Mateusz Kulikowski]

Move authentication response processing to rtllib_rx_auth_resp() function.
No logic is affected.

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 112 --
 1 file changed, 58 insertions(+), 54 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index d3fc5a4..9266bc6 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -2314,73 +2314,77 @@ inline int rtllib_rx_assoc_resp(struct rtllib_device 
*ieee, struct sk_buff *skb,
return 0;
 }
 
-inline int rtllib_rx_auth(struct rtllib_device *ieee, struct sk_buff *skb,
- struct rtllib_rx_stats *rx_stats)
+static void rtllib_rx_auth_resp(struct rtllib_device *ieee, struct sk_buff 
*skb)
 {
u16 errcode;
u8 *challenge;
int chlen = 0;
bool bSupportNmode = true, bHalfSupportNmode = false;
 
-   if (ieee->softmac_features & IEEE_SOFTMAC_ASSOCIATE) {
-   if (ieee->state == RTLLIB_ASSOCIATING_AUTHENTICATING &&
-   (ieee->iw_mode == IW_MODE_INFRA)) {
-   RTLLIB_DEBUG_MGMT("Received authentication response");
-
-   errcode = auth_parse(skb, , );
-   if (0 == errcode) {
-   if (ieee->open_wep || !challenge) {
-   ieee->state = 
RTLLIB_ASSOCIATING_AUTHENTICATED;
-   ieee->softmac_stats.rx_auth_rs_ok++;
-   if (!(ieee->pHTInfo->IOTAction &
-   HT_IOT_ACT_PURE_N_MODE)) {
-   if 
(!ieee->GetNmodeSupportBySecCfg(ieee->dev)) {
-   if 
(IsHTHalfNmodeAPs(ieee)) {
-   bSupportNmode = 
true;
-   
bHalfSupportNmode = true;
-   } else {
-   bSupportNmode = 
false;
-   
bHalfSupportNmode = false;
-   }
-   }
-   }
-   /* Dummy wirless mode setting to avoid
-* encryption issue */
-   if (bSupportNmode) {
-   ieee->SetWirelessMode(ieee->dev,
-  ieee->current_network.mode);
+   errcode = auth_parse(skb, , );
+   if (0 == errcode) {
+   if (ieee->open_wep || !challenge) {
+   ieee->state = RTLLIB_ASSOCIATING_AUTHENTICATED;
+   ieee->softmac_stats.rx_auth_rs_ok++;
+   if (!(ieee->pHTInfo->IOTAction &
+   HT_IOT_ACT_PURE_N_MODE)) {
+   if (!ieee->GetNmodeSupportBySecCfg(ieee->dev)) {
+   if (IsHTHalfNmodeAPs(ieee)) {
+   bSupportNmode = true;
+   bHalfSupportNmode = true;
} else {
-   /*TODO*/
-   ieee->SetWirelessMode(ieee->dev,
- IEEE_G);
+   bSupportNmode = false;
+   bHalfSupportNmode = false;
}
-
-   if (ieee->current_network.mode ==
-   IEEE_N_24G && bHalfSupportNmode) {
-   netdev_info(ieee->dev,
-   "==>enter half 
N mode\n");
-   ieee->bHalfWirelessN24GMode =
-true;
-   } else
-   ieee->bHalfWirelessN24GMode =
-false;
-
-   rtllib_associate_step2(ieee);
-   } else {
-   rtllib_auth_challenge(ieee, challenge,
- chlen);
}
+   }
+   /* Dummy 

[PATCH 10/11] staging: rtl8192e: Decrease nesting of rtllib_rx_auth_resp()

[Mateusz Kulikowski]

Return from rtllib_rx_auth_resp() if auth_parse() fails.

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 89 ---
 1 file changed, 45 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 9266bc6..9a4179c 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -2322,57 +2322,58 @@ static void rtllib_rx_auth_resp(struct rtllib_device 
*ieee, struct sk_buff *skb)
bool bSupportNmode = true, bHalfSupportNmode = false;
 
errcode = auth_parse(skb, , );
-   if (0 == errcode) {
-   if (ieee->open_wep || !challenge) {
-   ieee->state = RTLLIB_ASSOCIATING_AUTHENTICATED;
-   ieee->softmac_stats.rx_auth_rs_ok++;
-   if (!(ieee->pHTInfo->IOTAction &
-   HT_IOT_ACT_PURE_N_MODE)) {
-   if (!ieee->GetNmodeSupportBySecCfg(ieee->dev)) {
-   if (IsHTHalfNmodeAPs(ieee)) {
-   bSupportNmode = true;
-   bHalfSupportNmode = true;
-   } else {
-   bSupportNmode = false;
-   bHalfSupportNmode = false;
-   }
-   }
-   }
-   /* Dummy wirless mode setting to avoid
-* encryption issue */
-   if (bSupportNmode) {
-   ieee->SetWirelessMode(ieee->dev,
-  ieee->current_network.mode);
-   } else {
-   /*TODO*/
-   ieee->SetWirelessMode(ieee->dev,
- IEEE_G);
-   }
 
-   if (ieee->current_network.mode ==
-   IEEE_N_24G && bHalfSupportNmode) {
-   netdev_info(ieee->dev,
-   "==>enter half N mode\n");
-   ieee->bHalfWirelessN24GMode =
-true;
-   } else
-   ieee->bHalfWirelessN24GMode =
-false;
-
-   rtllib_associate_step2(ieee);
-   } else {
-   rtllib_auth_challenge(ieee, challenge,
- chlen);
-   }
-   } else {
+   if (errcode) {
ieee->softmac_stats.rx_auth_rs_err++;
RTLLIB_DEBUG_MGMT("Authentication respose status code 0x%x",
  errcode);
 
netdev_info(ieee->dev,
-   "Authentication respose status code 0x%x",
-   errcode);
+   "Authentication respose status code 0x%x", 
errcode);
rtllib_associate_abort(ieee);
+   return;
+   }
+
+   if (ieee->open_wep || !challenge) {
+   ieee->state = RTLLIB_ASSOCIATING_AUTHENTICATED;
+   ieee->softmac_stats.rx_auth_rs_ok++;
+   if (!(ieee->pHTInfo->IOTAction &
+   HT_IOT_ACT_PURE_N_MODE)) {
+   if (!ieee->GetNmodeSupportBySecCfg(ieee->dev)) {
+   if (IsHTHalfNmodeAPs(ieee)) {
+   bSupportNmode = true;
+   bHalfSupportNmode = true;
+   } else {
+   bSupportNmode = false;
+   bHalfSupportNmode = false;
+   }
+   }
+   }
+   /* Dummy wirless mode setting to avoid
+* encryption issue */
+   if (bSupportNmode) {
+   ieee->SetWirelessMode(ieee->dev,
+  ieee->current_network.mode);
+   } else {
+   /*TODO*/
+   ieee->SetWirelessMode(ieee->dev,
+ IEEE_G);
+   }
+
+   if (ieee->current_network.mode ==
+   IEEE_N_24G && bHalfSupportNmode) {
+   netdev_info(ieee->dev,
+   "==>enter half N mode\n");
+   ieee->bHalfWirelessN24GMode =
+true;
+   } else
+   ieee->bHalfWirelessN24GMode =
+ 

[PATCH 05/11] staging: rtl8192e: Fix LINE_CONTINUATIONS warning

[Mateusz Kulikowski]

Fix 'Avoid unnecessary line continuations' checkpatch.pl warning

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 0f2ae35..d3fc5a4 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -2503,7 +2503,7 @@ void rtllib_softmac_xmit(struct rtllib_txb *txb, struct 
rtllib_device *ieee)
 * the wait queue */
for (i = 0; i < txb->nr_frags; i++) {
queue_len = skb_queue_len(>skb_waitQ[queue_index]);
-   if ((queue_len  != 0) ||\
+   if ((queue_len  != 0) ||
(!ieee->check_nic_enough_desc(ieee->dev, queue_index)) ||
(ieee->queue_stop)) {
/* insert the skb packet to the wait queue */
-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/11] staging: rtl8192e: Fix PRINTK_WITHOUT_KERN_LEVEL warnings

[Mateusz Kulikowski]

Replace custom hex dumping function with print_hex_dump_bytes()
to make checkpatch.pl happy

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtllib.h | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib.h 
b/drivers/staging/rtl8192e/rtllib.h
index 5363b6f..c748777 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -690,15 +690,9 @@ do {   
\
 #define RTLLIB_DEBUG_DATA(level, data, datalen)\
do {\
if ((rtllib_debug_level & (level)) == (level)) {\
-   int i;  \
-   u8 *pdata = (u8 *)data; \
printk(KERN_DEBUG "rtllib: %s()\n", __func__);  \
-   for (i = 0; i < (int)(datalen); i++){   \
-   printk("%2.2x ", pdata[i]); \
-   if ((i+1)%16 == 0)  \
-   printk("\n");   \
-   }   \
-   printk("\n");   \
+   print_hex_dump_bytes(KERN_DEBUG, DUMP_PREFIX_NONE, \
+data, datalen); \
}   \
} while (0)
 
-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/11] staging: rtl8192e: Fix BRACES warning

[Mateusz Kulikowski]

Fix 'braces {} are not necessary for single statement blocks'
checkpatch.pl warning

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
index 1f7077d..c465f87 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
@@ -301,13 +301,11 @@ bool init_firmware(struct net_device *dev)
file_length = pfirmware->firmware_buf_size[init_step];
 
rt_status = fw_download_code(dev, mapped_file, file_length);
-   if (!rt_status) {
+   if (!rt_status)
goto download_firmware_fail;
-   }
 
-   if (!firmware_check_ready(dev, init_step)) {
+   if (!firmware_check_ready(dev, init_step))
goto download_firmware_fail;
-   }
}
 
RT_TRACE(COMP_FIRMWARE, "Firmware Download Success\n");
-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/11] staging: rtl8192e: remove unused EXPORT_SYMBOL_RSL macro

[Mateusz Kulikowski]

This macro caused checkpatch.pl warning and is not used.

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtllib.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib.h 
b/drivers/staging/rtl8192e/rtllib.h
index dc9f675..5363b6f 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -68,9 +68,6 @@
 
 #define skb_tail_pointer_rsl(skb) skb_tail_pointer(skb)
 
-#define EXPORT_SYMBOL_RSL(x) EXPORT_SYMBOL(x)
-
-
 #define queue_delayed_work_rsl(x, y, z) queue_delayed_work(x, y, z)
 #define INIT_DELAYED_WORK_RSL(x, y, z) INIT_DELAYED_WORK(x, y)
 
-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 11/11] staging: rtl8192e: Fix indentation in rtllib_rx_auth_resp()

[Mateusz Kulikowski]

Signed-off-by: Mateusz Kulikowski 
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 9a4179c..c043d8c 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -2329,7 +2329,7 @@ static void rtllib_rx_auth_resp(struct rtllib_device 
*ieee, struct sk_buff *skb)
  errcode);
 
netdev_info(ieee->dev,
-   "Authentication respose status code 0x%x", 
errcode);
+   "Authentication respose status code 0x%x", errcode);
rtllib_associate_abort(ieee);
return;
}
@@ -2337,8 +2337,7 @@ static void rtllib_rx_auth_resp(struct rtllib_device 
*ieee, struct sk_buff *skb)
if (ieee->open_wep || !challenge) {
ieee->state = RTLLIB_ASSOCIATING_AUTHENTICATED;
ieee->softmac_stats.rx_auth_rs_ok++;
-   if (!(ieee->pHTInfo->IOTAction &
-   HT_IOT_ACT_PURE_N_MODE)) {
+   if (!(ieee->pHTInfo->IOTAction & HT_IOT_ACT_PURE_N_MODE)) {
if (!ieee->GetNmodeSupportBySecCfg(ieee->dev)) {
if (IsHTHalfNmodeAPs(ieee)) {
bSupportNmode = true;
@@ -2353,27 +2352,22 @@ static void rtllib_rx_auth_resp(struct rtllib_device 
*ieee, struct sk_buff *skb)
 * encryption issue */
if (bSupportNmode) {
ieee->SetWirelessMode(ieee->dev,
-  ieee->current_network.mode);
+ ieee->current_network.mode);
} else {
/*TODO*/
-   ieee->SetWirelessMode(ieee->dev,
- IEEE_G);
+   ieee->SetWirelessMode(ieee->dev, IEEE_G);
}
 
-   if (ieee->current_network.mode ==
-   IEEE_N_24G && bHalfSupportNmode) {
-   netdev_info(ieee->dev,
-   "==>enter half N mode\n");
-   ieee->bHalfWirelessN24GMode =
-true;
-   } else
-   ieee->bHalfWirelessN24GMode =
-false;
-
+   if ((ieee->current_network.mode == IEEE_N_24G) &&
+   bHalfSupportNmode) {
+   netdev_info(ieee->dev, "==>enter half N mode\n");
+   ieee->bHalfWirelessN24GMode = true;
+   } else {
+   ieee->bHalfWirelessN24GMode = false;
+   }
rtllib_associate_step2(ieee);
} else {
-   rtllib_auth_challenge(ieee, challenge,
- chlen);
+   rtllib_auth_challenge(ieee, challenge,  chlen);
}
 }
 
-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 4.0-rc6

[Linus Torvalds]

Things are calming down nicelly, and there are fixes all over. The
NUMA balancing performance regression is fixed, and things are looking
up again in general. There were a number of i915 issues and a KVM
double-fault thing that meant that for a while there I was pretty sure
that this would be a release that will go to rc8, but that may be
unnecessary.

Apart from the aforementioned issues, the bulk of this is mostly small
misc driver fixes and architecture updates. The shortlog gives more of
a flavor of what's been going on.

But please do give this a good testing, and holler if there's some
regression we've missed.

  Linus

---
Al Viro (1):
  net: validate the range we feed to iov_iter_init() in
sys_sendto/sys_recvfrom

Alexandru M Stan (1):
  ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

Ameya Palande (1):
  mfd: kempld-core: Fix callback return value check

Andy Lutomirski (1):
  x86/asm/entry: Check for syscall exit work with IRQs disabled

Andy Shevchenko (1):
  spi: dw-mid: clear BUSY flag fist and test other one

Axel Lin (1):
  regulator: Fix documentation for regmap in the config

Benjamin Herrenschmidt (1):
  powerpc: Add PVR for POWER8NVL processor

Brian Silverman (1):
  sched: Fix RLIMIT_RTTIME when PI-boosting to RT

Catalin Marinas (2):
  net: compat: Update get_compat_msghdr() to match
copy_msghdr_from_user() behaviour
  arm64: Use the reserved TTBR0 if context switching to the init_mm

Chen-Yu Tsai (3):
  ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage
  ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
  ARM: dts: sunxi: Remove overclocked/overvoltaged OPP

Chris Wilson (1):
  drm/i915: Keep ring->active_list and ring->requests_list consistent

Damien Lespiau (2):
  drm/i915: Don't try to reference the fb in get_initial_plane_config()
  drm/i915: Fix atomic state when reusing the firmware fb

Dan Carpenter (1):
  watchdog: mtk_wdt: signedness bug in mtk_wdt_start()

Daniel Vetter (2):
  drm: Fixup racy refcounting in plane_force_disable
  drm/i915: Fixup legacy plane->crtc link for initial fb config

Dave Martin (1):
  arm64: juno: Fix misleading name of UART reference clock

David Ahern (4):
  sparc: perf: Remove redundant perf_pmu_{en|dis}able calls
  sparc: perf: Make counting mode actually work
  sparc: perf: Add support M7 processor
  sparc: Touch NMI watchdog when walking cpus and calling printk

David S. Miller (1):
  sparc64: Fix several bugs in memmove().

Ed Cashin (1):
  aoe: update aoe maintainer information

Gu Zheng (1):
  mm/memory hotplug: postpone the reset of obsolete pgdat

Heiko Carstens (2):
  s390/ftrace: fix compile error if CONFIG_KPROBES is disabled
  s390/smp: reenable smt after resume

Heiko Stuebner (1):
  MAINTAINERS: add rockchip regexp to the ARM/Rockchip entry

Helge Deller (2):
  parisc: Add compile-time check when adding new syscalls
  parisc: Fix pmd code to depend on PT_NLEVELS value, not on CONFIG_64BIT

Hendrik Brueckner (1):
  s390/cpum_sf: add diagnostic sampling event only if it is authorized

Herbert Xu (1):
  netfilter: Fix potential crash in nft_hash walker

Hui Wang (1):
  ALSA: hda - Add one more node in the EAPD supporting candidate list

Ian Wilson (1):
  netfilter: Zero the tuple in nfnl_cthelper_parse_tuple()

Igor Mammedov (1):
  kvm: avoid page allocation failure in kvm_set_memory_region()

Ivan T. Ivanov (1):
  spi: qup: Fix cs-num DT property parsing

James Hogan (3):
  metag: Fix ioremap_wc/ioremap_cached build errors
  watchdog: imgpdc: Fix probe NULL pointer dereference
  watchdog: imgpdc: Fix default heartbeat

Jean Delvare (1):
  MAINTAINERS: add Jan as DMI/SMBIOS support maintainer

Joe Perches (2):
  selinux: fix sel_write_enforce broken return value
  MAINTAINERS: correct rtc armada38x pattern entry

Josh Hunt (1):
  tcp: fix tcp fin memory accounting

Keerthy (1):
  regulator: palmas: Correct TPS659038 register definition for REGEN2

Keith Busch (1):
  NVMe: Initialize device list head before starting

Kishon Vijay Abraham I (1):
  ARM: dts: dra7: remove ti,hwmod property from pcie phy

Lars-Peter Clausen (1):
  drivers/rtc/rtc-mrst: fix suspend/resume

Laura Abbott (1):
  mm/page_alloc.c: call kernel_map_pages in unset_migrateype_isolate

Leon Yu (1):
  mm: fix anon_vma->degree underflow in anon_vma endless growing prevention

Libin Yang (1):
  ALSA: hda_intel: apply the Seperate stream_tag for Sunrise Point

Linus Torvalds (1):
  Linux 4.0-rc6

Mahesh Salgaonkar (1):
  powerpc/book3s: Fix the MCE code to use CONFIG_KVM_BOOK3S_64_HANDLER

Mark James (1):
  ARM: socfpga: dts: fix spi1 interrupt

Mark Rutland (1):
  mm/slub: fix lockups on PREEMPT && !SMP kernels

Markos Chandras (1):
  net: ethernet: pcnet32: Setup the 

[PATCH 00/11] staging: rtl8192e: checkpatch.pl cleanups

[Mateusz Kulikowski]

This series of patches cleans bunch of checkpatch.pl warnings.
It should apply to staging-next (153fe946) and staging-testing (f8da055a).

Patch 10 changes code/logic a bit (but behaviour should not change).
Remaining patches are trivial.

Smoke tested on rtl8192e card vs staging-next:
- Module load/unload
- Interface up/down
For now I'm not able to do more tests as I don't have proper antennas :(

Mateusz Kulikowski (11):
  staging: rtl8192e: Fix UNNECESSARY_ELSE warning
  staging: rtl8192e: Fix RETURN_VOID warnings
  staging: rtl8192e: remove unused EXPORT_SYMBOL_RSL macro
  staging: rtl8192e: Fix UNNECESSARY_PARENTHESES warnings
  staging: rtl8192e: Fix LINE_CONTINUATIONS warning
  staging: rtl8192e: Fix BRACES warning
  staging: rtl8192e: Fix DO_WHILE_MACRO_WITH_TRAILING_SEMICOLON warning
  staging: rtl8192e: Fix PRINTK_WITHOUT_KERN_LEVEL warnings
  staging: rtl8192e: Divide rtllib_rx_auth()
  staging: rtl8192e: Decrease nesting of rtllib_rx_auth_resp()
  staging: rtl8192e: Fix indentation in rtllib_rx_auth_resp()

 drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c |  74 +++--
 .../staging/rtl8192e/rtl8192e/r8192E_firmware.c|   6 +-
 drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c |  18 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_cam.c|   7 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c   | 224 +++
 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 319 ++---
 drivers/staging/rtl8192e/rtl8192e/rtl_ps.c |   9 +-
 drivers/staging/rtl8192e/rtl8192e/rtl_wx.c |  24 +-
 drivers/staging/rtl8192e/rtl819x_HTProc.c  |  31 +-
 drivers/staging/rtl8192e/rtl819x_TSProc.c  | 120 
 drivers/staging/rtl8192e/rtllib.h  |  13 +-
 drivers/staging/rtl8192e/rtllib_debug.h|   2 +-
 drivers/staging/rtl8192e/rtllib_rx.c   | 121 
 drivers/staging/rtl8192e/rtllib_softmac.c  | 125 
 drivers/staging/rtl8192e/rtllib_tx.c   |  78 ++---
 15 files changed, 552 insertions(+), 619 deletions(-)

-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] perf tool: Refactor comm/tgid lookup

[David Ahern]

Rather than parsing /proc/pid/status file one line at a time, read
it into a buffer in one shot and search for all strings in one pass.

Signed-off-by: David Ahern 
Cc: Don Zickus 
Cc: Joe Mario 
Cc: Jiri Olsa 
---
 tools/perf/util/event.c | 80 +++--
 1 file changed, 51 insertions(+), 29 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index d5efa5092ce6..b49bee8a283d 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -49,48 +49,70 @@ static struct perf_sample synth_sample = {
.period= 1,
 };
 
+/*
+ * Assumes that the first 4095 bytes of /proc/pid/stat contains
+ * the comm and tgid.
+ */
 static pid_t perf_event__get_comm_tgid(pid_t pid, char *comm, size_t len)
 {
char filename[PATH_MAX];
-   char bf[BUFSIZ];
-   FILE *fp;
-   size_t size = 0;
+   char bf[4096];
+   int fd;
+   size_t size = 0, n;
pid_t tgid = -1;
+   char *nl, *name, *tgids;
 
snprintf(filename, sizeof(filename), "/proc/%d/status", pid);
 
-   fp = fopen(filename, "r");
-   if (fp == NULL) {
+   fd = open(filename, O_RDONLY);
+   if (fd < 0) {
pr_debug("couldn't open %s\n", filename);
return 0;
}
 
-   while (!comm[0] || (tgid < 0)) {
-   if (fgets(bf, sizeof(bf), fp) == NULL) {
-   pr_warning("couldn't get COMM and pgid, malformed %s\n",
-  filename);
-   break;
-   }
-
-   if (memcmp(bf, "Name:", 5) == 0) {
-   char *name = bf + 5;
-   while (*name && isspace(*name))
-   ++name;
-   size = strlen(name) - 1;
-   if (size >= len)
-   size = len - 1;
-   memcpy(comm, name, size);
-   comm[size] = '\0';
-
-   } else if (memcmp(bf, "Tgid:", 5) == 0) {
-   char *tgids = bf + 5;
-   while (*tgids && isspace(*tgids))
-   ++tgids;
-   tgid = atoi(tgids);
-   }
+   n = read(fd, bf, sizeof(bf) - 1);
+   close(fd);
+   if (n <= 0) {
+   pr_warning("Couldn't get COMM and tgid for pid %d\n",
+  pid);
+   return -1;
}
+   bf[n] = '\0';
 
-   fclose(fp);
+   name = strstr(bf, "Name:");
+   tgids = strstr(bf, "Tgid:");
+
+   if (name) {
+   name += 5;  /* strlen("Name:") */
+
+   while (*name && isspace(*name))
+   ++name;
+
+   nl = strchr(name, '\n');
+   if (nl)
+   *nl = '\0';
+
+   size = strlen(name);
+   if (size >= len)
+   size = len - 1;
+   memcpy(comm, name, size);
+   comm[size] = '\0';
+   } else
+   pr_debug("Name: string not found for pid %d\n", pid);
+
+   if (tgids) {
+   tgids += 5;  /* strlen("Tgid:") */
+   while (*tgids && isspace(*tgids))
+   ++tgids;
+
+   nl = strchr(tgids, '\n');
+   if (nl)
+   *nl = '\0';
+
+   tgid = atoi(tgids);
+
+   } else
+   pr_debug("Tgid: string not found for pid %d\n", pid);
 
return tgid;
 }
-- 
2.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] perf tool: Fix ppid for synthesized fork events

[David Ahern]

363b785f38 added synthesized fork events and set a thread's parent id
to itself. Since we are already processing /proc//status the ppid
can be determined properly. Make it so.

Signed-off-by: David Ahern 
Cc: Don Zickus 
Cc: Joe Mario 
Cc: Jiri Olsa 
---
 tools/perf/util/event.c | 106 
 1 file changed, 63 insertions(+), 43 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index b49bee8a283d..648744a21410 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -51,29 +51,32 @@ static struct perf_sample synth_sample = {
 
 /*
  * Assumes that the first 4095 bytes of /proc/pid/stat contains
- * the comm and tgid.
+ * the comm, tgid and ppid.
  */
-static pid_t perf_event__get_comm_tgid(pid_t pid, char *comm, size_t len)
+static int perf_event__get_comm_ids(pid_t pid, char *comm, size_t len,
+   pid_t *tgid, pid_t *ppid)
 {
char filename[PATH_MAX];
char bf[4096];
int fd;
size_t size = 0, n;
-   pid_t tgid = -1;
-   char *nl, *name, *tgids;
+   char *nl, *name, *tgids, *ppids;
+
+   *tgid = -1;
+   *ppid = -1;
 
snprintf(filename, sizeof(filename), "/proc/%d/status", pid);
 
fd = open(filename, O_RDONLY);
if (fd < 0) {
pr_debug("couldn't open %s\n", filename);
-   return 0;
+   return -1;
}
 
n = read(fd, bf, sizeof(bf) - 1);
close(fd);
if (n <= 0) {
-   pr_warning("Couldn't get COMM and tgid for pid %d\n",
+   pr_warning("Couldn't get COMM, tigd and ppid for pid %d\n",
   pid);
return -1;
}
@@ -81,6 +84,7 @@ static pid_t perf_event__get_comm_tgid(pid_t pid, char *comm, 
size_t len)
 
name = strstr(bf, "Name:");
tgids = strstr(bf, "Tgid:");
+   ppids = strstr(bf, "PPid:");
 
if (name) {
name += 5;  /* strlen("Name:") */
@@ -109,32 +113,51 @@ static pid_t perf_event__get_comm_tgid(pid_t pid, char 
*comm, size_t len)
if (nl)
*nl = '\0';
 
-   tgid = atoi(tgids);
+   *tgid = atoi(tgids);
 
} else
pr_debug("Tgid: string not found for pid %d\n", pid);
 
-   return tgid;
+   if (ppids) {
+   ppids += 5;  /* strlen("PPid:") */
+
+   while (*ppids && isspace(*ppids))
+   ++ppids;
+
+   nl = strchr(ppids, '\n');
+   if (nl)
+   *nl = '\0';
+
+   *ppid = atoi(ppids);
+   } else
+   pr_debug("PPid: string not found for pid %d\n", pid);
+
+   return 0;
 }
 
-static pid_t perf_event__prepare_comm(union perf_event *event, pid_t pid,
-struct machine *machine)
+static int perf_event__prepare_comm(union perf_event *event, pid_t pid,
+   struct machine *machine,
+   pid_t *tgid, pid_t *ppid)
 {
size_t size;
-   pid_t tgid;
+
+   *ppid = -1;
 
memset(>comm, 0, sizeof(event->comm));
 
-   if (machine__is_host(machine))
-   tgid = perf_event__get_comm_tgid(pid, event->comm.comm,
-sizeof(event->comm.comm));
-   else
-   tgid = machine->pid;
+   if (machine__is_host(machine)) {
+   if (perf_event__get_comm_ids(pid, event->comm.comm,
+sizeof(event->comm.comm),
+tgid, ppid) != 0) {
+   return -1;
+   }
+   } else
+   *tgid = machine->pid;
 
-   if (tgid < 0)
-   goto out;
+   if (*tgid < 0)
+   return -1;
 
-   event->comm.pid = tgid;
+   event->comm.pid = *tgid;
event->comm.header.type = PERF_RECORD_COMM;
 
size = strlen(event->comm.comm) + 1;
@@ -144,36 +167,35 @@ static pid_t perf_event__prepare_comm(union perf_event 
*event, pid_t pid,
(sizeof(event->comm.comm) - size) +
machine->id_hdr_size);
event->comm.tid = pid;
-out:
-   return tgid;
+
+   return 0;
 }
 
-static pid_t perf_event__synthesize_comm(struct perf_tool *tool,
-union perf_event *event, pid_t pid,
-perf_event__handler_t process,
-struct machine *machine)
+static int perf_event__synthesize_comm(struct perf_tool *tool,
+  union perf_event *event, pid_t pid,
+  perf_event__handler_t process,
+  struct machine *machine,
+  pid_t *tgid, 

Re: [PATCH] dmaengine: pl330: fix the race condition in pl330 driver.

[Scott Branden]

Adding original author Jaswinder Singh (3 email addresses) to email list.

On 15-03-26 04:55 PM, Scott Branden wrote:

From: ismail 

Update the thread running index before issuing the
GO command to the DMAC.

Tested-by: Mohamed Ismail Abdul Packir Mohamed 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
Signed-off-by: Scott Branden 
Signed-off-by: Mohamed Ismail Abdul Packir Mohamed 
---
  drivers/dma/pl330.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 0e1f567..631642d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1072,11 +1072,11 @@ static bool _trigger(struct pl330_thread *thrd)
/* Set to generate interrupts for SEV */
writel(readl(regs + INTEN) | (1 << thrd->ev), regs + INTEN);

+   thrd->req_running = idx;
+
/* Only manager can execute GO */
_execute_DBGINSN(thrd, insn, true);

-   thrd->req_running = idx;
-
return true;
  }




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 1/3] TTY: use class_find_device to find port in uart_suspend/resume.

[NeilBrown]

On Wed, 25 Mar 2015 12:20:20 -0400 Peter Hurley 
wrote:

> Hi Neil,
> 
> On 03/18/2015 01:58 AM, NeilBrown wrote:
> > uart_{suspend,resume}_port seach the children of a uart device
> > to find a particular tty device.
> > This requires all the ttys to be direct children of the uart.
> > 
> > A future patch will allow a 'tty_slave' to intervene between
> > the port and the uart, voiding this requirement.
> > 
> > So change to use class_find_device.  This is made possibly by
> > exporting a "tty_find_device" from tty_io.c
> 
> Comments below.
> 
> > Signed-off-by: NeilBrown 
> > ---
> >  drivers/tty/serial/serial_core.c |   21 -
> >  drivers/tty/tty_io.c |6 ++
> >  include/linux/tty.h  |1 +
> >  3 files changed, 15 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/serial_core.c 
> > b/drivers/tty/serial/serial_core.c
> > index 6a1055ae3437..7abb7474870a 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -1960,26 +1960,19 @@ struct uart_match {
> > struct uart_driver *driver;
> >  };
> >  
> > -static int serial_match_port(struct device *dev, void *data)
> > -{
> > -   struct uart_match *match = data;
> > -   struct tty_driver *tty_drv = match->driver->tty_driver;
> > -   dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
> > -   match->port->line;
> > -
> > -   return dev->devt == devt; /* Actually, only one tty per port */
> > -}
> >  
> >  int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
> >  {
> > struct uart_state *state = drv->state + uport->line;
> > struct tty_port *port = >port;
> > struct device *tty_dev;
> > -   struct uart_match match = {uport, drv};
> > +   dev_t devt = MKDEV(drv->tty_driver->major,
> > +  drv->tty_driver->minor_start) +
> > +   uport->line;
> >  
> > mutex_lock(>mutex);
> >  
> > -   tty_dev = device_find_child(uport->dev, , serial_match_port);
> > +   tty_dev = tty_find_device(devt);
> > if (device_may_wakeup(tty_dev)) {
> > if (!enable_irq_wake(uport->irq))
> > uport->irq_wake = 1;
> > @@ -2039,12 +2032,14 @@ int uart_resume_port(struct uart_driver *drv, 
> > struct uart_port *uport)
> > struct uart_state *state = drv->state + uport->line;
> > struct tty_port *port = >port;
> > struct device *tty_dev;
> > -   struct uart_match match = {uport, drv};
> > struct ktermios termios;
> > +   dev_t devt = MKDEV(drv->tty_driver->major,
> > +  drv->tty_driver->minor_start) +
> > +   uport->line;
> >  
> > mutex_lock(>mutex);
> >  
> > -   tty_dev = device_find_child(uport->dev, , serial_match_port);
> > +   tty_dev = tty_find_device(devt);
> > if (!uport->suspended && device_may_wakeup(tty_dev)) {
> > if (uport->irq_wake) {
> > disable_irq_wake(uport->irq);
> > diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> > index 51f066aa375e..27632ad17d6f 100644
> > --- a/drivers/tty/tty_io.c
> > +++ b/drivers/tty/tty_io.c
> > @@ -3077,6 +3077,12 @@ static struct device *tty_get_device(struct 
> > tty_struct *tty)
> > return class_find_device(tty_class, NULL, , dev_match_devt);
> >  }
> >
> > +struct device *tty_find_device(dev_t devt)
> > +{
> > +   return class_find_device(tty_class, NULL, , dev_match_devt);
> > +}
> > +EXPORT_SYMBOL(tty_find_device);
> > +
> 
> Would you please replace tty_get_device() usage with tty_find_device()
> (and keep the function comment from tty_get_device())?
> 

I was wondering what would be the best thing to do to tty_get_device.
As there is only one caller, replacing at you suggest seems best.
I've done that - thanks.

NeilBrown


pgpqSH09Qz1gQ.pgp
Description: OpenPGP digital signature

Re: [PATCH] x86/asm/entry/64: better check for canonical address

[Denys Vlasenko]

On Sun, Mar 29, 2015 at 11:12 PM, Andy Lutomirski  wrote:
> On Sun, Mar 29, 2015 at 12:36 PM, Denys Vlasenko
>  wrote:
>> The instruction would need a differentiator whether returned-to code
>> is 64-bit or 32-bit.
>> Then it probably can use the same approach SYSRET{O,L} uses:
>> with REX.W, return is to 64-bit; without it, return is to 32-bit.
>>
>> Interrupt return then can check pt_regs->cs and use
>> IRETL_FAST if it is USER32_CS; use IRETQ_FAST if it is USER_CS
>> or KERNEL_CS; otherwise, fall back to slow but "universal" IRETQ.

Hmm. In fact since we'd need such checks, then instructions
can be even simpler: they don't even need to check CPL,
it can be hardcoded too. We'd need four instructions then:
return to 64 and to 32 bits, to CPL0 and to CPL3.


>> Do we have contacts at Intel to petition for this? :D
>
> Some of us do and have petitioned :)

And what did Intel say?

If there's any interest in doing this, Intel better *do* talk to us
before they commit to implementing it. Their track record
in implementing "fast syscalls" is nothing to write home about.
SYSENTER is a design disaster; SYSRET is buggy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/