Re: [lkp] [x86/MSI] 52f518a3a7c: -30.5% netperf.Throughput_tps

[Jiang Liu]

On 2015/6/16 13:41, Huang Ying wrote:
> Hi, Gerry,
> 
> On Tue, 2015-06-16 at 10:09 +0800, Jiang Liu wrote:
>> On 2015/6/16 1:52, Thomas Gleixner wrote:
>>> On Mon, 15 Jun 2015, Huang Ying wrote:
>> lkml.org/lkml/2015/6/1/80
>>  The root cause is that, with hierarchy irqdomain enabled,
>> there are multiple irq_data associated with one irq. And function
>> irq_move_irq() on x86 uses a wrong copy of irq_data to check
>> whether there's pending irq migration operation. So all irq migration
>> /set_affinity operations will get pending for ever. This may
>> affect network performance due to interrupt load balance issue.
>> And the patch set posted at
>> www.gossamer-threads.com/lists/linux/kernel/2185533
>> should have solved all such regressions.
> 
> Thanks for your information.  Do you have a git tree for this patchset?

Hi Ying,
You may access the branch at:
https://github.com/jiangliu/linux test/irq_data_v3
or view at url:
https://github.com/jiangliu/linux/tree/test/irq_data_v3
Thanks!
Gerry

> 
> Best Regards,
> Huang, Ying
> 
> 
--
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: call_rcu from trace_preempt

[Alexei Starovoitov]

On 6/15/15 7:14 PM, Paul E. McKenney wrote:


Why do you believe that it is better to fix it within call_rcu()?


found it:
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 8cf7304b2867..a3be09d482ae 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -935,9 +935,9 @@ bool notrace rcu_is_watching(void)
 {
bool ret;

-   preempt_disable();
+   preempt_disable_notrace();
ret = __rcu_is_watching();
-   preempt_enable();
+   preempt_enable_notrace();
return ret;
 }

the rcu_is_watching() and __rcu_is_watching() are already marked
notrace, so imo it's a good 'fix'.
What was happening is that the above preempt_enable was triggering
recursive call_rcu that was indeed messing 'rdp' that was
prepared by __call_rcu and before __call_rcu_core could use that.

btw, also noticed that local_irq_save done by note_gp_changes
is partially redundant. In __call_rcu_core path the irqs are
already disabled.


Perhaps you are self-deadlocking within __call_rcu_core().  If you have
not already done so, please try running with CONFIG_PROVE_LOCKING=y.


yes, I had CONFIG_PROVE_LOCKING on.


I suspect that your problem may range quite a bit further than just
call_rcu().  For example, in your stack trace, you have a recursive
call to debug_object_activate(), which might not be such good thing.


nope :) recursive debug_object_activate() is fine.
with the above 'fix' the trace.patch is now passing.

Why I'm digging into all of these? Well, to find out when
it's safe to finally do call_rcu. If I will use deferred kfree
approach in bpf maps, I need to know when it's safe to finally
call_rcu and it's not an easy answer.
kprobes potentially can be placed in any part of call_rcu stack,
so things can go messy quickly. So it helps to understand the call_rcu
logic well enough to come up with good solution.

--
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/6] mm, compaction: skip compound pages by order in free scanner

[Joonsoo Kim]

On Wed, Jun 10, 2015 at 11:32:33AM +0200, Vlastimil Babka wrote:
> The compaction free scanner is looking for PageBuddy() pages and skipping all
> others.  For large compound pages such as THP or hugetlbfs, we can save a lot
> of iterations if we skip them at once using their compound_order(). This is
> generally unsafe and we can read a bogus value of order due to a race, but if
> we are careful, the only danger is skipping too much.
> 
> When tested with stress-highalloc from mmtests on 4GB system with 1GB 
> hugetlbfs
> pages, the vmstat compact_free_scanned count decreased by at least 15%.
> 
> Signed-off-by: Vlastimil Babka 


Acked-by: Joonsoo Kim 

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: [PATCH 4/6] mm, compaction: always skip compound pages by order in migrate scanner

[Joonsoo Kim]

On Wed, Jun 10, 2015 at 11:32:32AM +0200, Vlastimil Babka wrote:
> The compaction migrate scanner tries to skip compound pages by their order, to
> reduce number of iterations for pages it cannot isolate. The check is only 
> done
> if PageLRU() is true, which means it applies to THP pages, but not e.g.
> hugetlbfs pages or any other non-LRU compound pages, which we have to iterate
> by base pages.
> 
> This limitation comes from the assumption that it's only safe to read
> compound_order() when we have the zone's lru_lock and THP cannot be split 
> under
> us. But the only danger (after filtering out order values that are not below
> MAX_ORDER, to prevent overflows) is that we skip too much or too little after
> reading a bogus compound_order() due to a rare race. This is the same 
> reasoning
> as patch 99c0fd5e51c4 ("mm, compaction: skip buddy pages by their order in the
> migrate scanner") introduced for unsafely reading PageBuddy() order.
> 
> After this patch, all pages are tested for PageCompound() and we skip them by
> compound_order().  The test is done after the test for balloon_page_movable()
> as we don't want to assume if balloon pages (or other pages with own isolation
> and migration implementation if a generic API gets implemented) are compound
> or not.
> 
> When tested with stress-highalloc from mmtests on 4GB system with 1GB 
> hugetlbfs
> pages, the vmstat compact_migrate_scanned count decreased by 15%.
> 
> Signed-off-by: Vlastimil Babka 
> Cc: Minchan Kim 
> Cc: Mel Gorman 
> Cc: Joonsoo Kim 
> Cc: Michal Nazarewicz 
> Cc: Naoya Horiguchi 
> Cc: Christoph Lameter 
> Cc: Rik van Riel 
> Cc: David Rientjes 
> ---
>  mm/compaction.c | 36 +---
>  1 file changed, 17 insertions(+), 19 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index d334bb3..e37d361 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -680,6 +680,8 @@ isolate_migratepages_block(struct compact_control *cc, 
> unsigned long low_pfn,
>  
>   /* Time to isolate some pages for migration */
>   for (; low_pfn < end_pfn; low_pfn++) {
> + bool is_lru;
> +
>   /*
>* Periodically drop the lock (if held) regardless of its
>* contention, to give chance to IRQs. Abort async compaction
> @@ -723,39 +725,35 @@ isolate_migratepages_block(struct compact_control *cc, 
> unsigned long low_pfn,
>* It's possible to migrate LRU pages and balloon pages
>* Skip any other type of page
>*/
> - if (!PageLRU(page)) {
> + is_lru = PageLRU(page);
> + if (!is_lru) {
>   if (unlikely(balloon_page_movable(page))) {
>   if (balloon_page_isolate(page)) {
>   /* Successfully isolated */
>   goto isolate_success;
>   }
>   }
> - continue;
>   }
>  
>   /*
> -  * PageLRU is set. lru_lock normally excludes isolation
> -  * splitting and collapsing (collapsing has already happened
> -  * if PageLRU is set) but the lock is not necessarily taken
> -  * here and it is wasteful to take it just to check transhuge.
> -  * Check PageCompound without lock and skip the whole pageblock
> -  * if it's a transhuge page, as calling compound_order()
> -  * without preventing THP from splitting the page underneath us
> -  * may return surprising results.
> -  * If we happen to check a THP tail page, compound_order()
> -  * returns 0. It should be rare enough to not bother with
> -  * using compound_head() in that case.
> +  * Regardless of being on LRU, compound pages such as THP and
> +  * hugetlbfs are not to be compacted. We can potentially save
> +  * a lot of iterations if we skip them at once. The check is
> +  * racy, but we can consider only valid values and the only
> +  * danger is skipping too much.
>*/
>   if (PageCompound(page)) {
> - int nr;
> - if (locked)
> - nr = 1 << compound_order(page);
> - else
> - nr = pageblock_nr_pages;
> - low_pfn += nr - 1;
> + unsigned int comp_order = compound_order(page);
> +
> + if (comp_order > 0 && comp_order < MAX_ORDER)
> + low_pfn += (1UL << comp_order) - 1;
> +
>   continue;
>   }

How about moving this PageCompound() check up to the PageLRU check?
Is there any relationship between balloon page and PageCompound()?
It will remove is_lru and code would be more 

Re: [lkp] [x86/MSI] 52f518a3a7c: -30.5% netperf.Throughput_tps

[Huang Ying]

Hi, Gerry,

On Tue, 2015-06-16 at 10:09 +0800, Jiang Liu wrote:
> On 2015/6/16 1:52, Thomas Gleixner wrote:
> > On Mon, 15 Jun 2015, Huang Ying wrote:
> > 
> >> FYI, we noticed the below changes on
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> >> commit 52f518a3a7c2f80551a38d38be28bc9f335e713c ("x86/MSI: Use 
> >> hierarchical irqdomains to manage MSI interrupts")
> >>
> > 
> > I really appreciate this testing effort, but the information provided
> > is not really helpful.
> > 
> > I asked this before. Can you pretty please, upload ALL relevant
> > information (.config, full dmesg, below stats, /proc/interrupts ...)
> > to some place where everyone interested can download them?
> > 
> > Then themail contains a useful link instead of 200k waste of network 
> > bandwidth.
> 
> Hi Ying and Thomas,
>   I guess this report discloses a regression in hierarchy
> irqdomain, and which should have been fixed by the patch posted at:
> lkml.org/lkml/2015/6/1/80
>   The root cause is that, with hierarchy irqdomain enabled,
> there are multiple irq_data associated with one irq. And function
> irq_move_irq() on x86 uses a wrong copy of irq_data to check
> whether there's pending irq migration operation. So all irq migration
> /set_affinity operations will get pending for ever. This may
> affect network performance due to interrupt load balance issue.
> And the patch set posted at
> www.gossamer-threads.com/lists/linux/kernel/2185533
> should have solved all such regressions.

Thanks for your information.  Do you have a git tree for this patchset?

Best Regards,
Huang, Ying


--
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/6] mm, compaction: encapsulate resetting cached scanner positions

[Joonsoo Kim]

On Wed, Jun 10, 2015 at 11:32:31AM +0200, Vlastimil Babka wrote:
> Resetting the cached compaction scanner positions is now done implicitly in
> __reset_isolation_suitable() and compact_finished(). Encapsulate the
> functionality in a new function reset_cached_positions() and call it 
> explicitly
> where needed.
> 
> Signed-off-by: Vlastimil Babka 
> Cc: Minchan Kim 
> Cc: Mel Gorman 
> Cc: Joonsoo Kim 
> Cc: Michal Nazarewicz 
> Cc: Naoya Horiguchi 
> Cc: Christoph Lameter 
> Cc: Rik van Riel 
> Cc: David Rientjes 
> ---
>  mm/compaction.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 7e0a814..d334bb3 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -207,6 +207,13 @@ static inline bool isolation_suitable(struct 
> compact_control *cc,
>   return !get_pageblock_skip(page);
>  }
>  
> +static void reset_cached_positions(struct zone *zone)
> +{
> + zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
> + zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
> + zone->compact_cached_free_pfn = zone_end_pfn(zone);
> +}
> +
>  /*
>   * This function is called to clear all cached information on pageblocks that
>   * should be skipped for page isolation when the migrate and free page 
> scanner
> @@ -218,9 +225,6 @@ static void __reset_isolation_suitable(struct zone *zone)
>   unsigned long end_pfn = zone_end_pfn(zone);
>   unsigned long pfn;
>  
> - zone->compact_cached_migrate_pfn[0] = start_pfn;
> - zone->compact_cached_migrate_pfn[1] = start_pfn;
> - zone->compact_cached_free_pfn = end_pfn;
>   zone->compact_blockskip_flush = false;

Is there a valid reason not to call reset_cached_positions() in
__reset_isolation_suitable? You missed one callsite in
__compact_pgdat().

if (cc->order == -1)
__reset_isolation_suitable(zone);

This also needs reset_cached_positions().

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: [PATCH 4/8] ARCv2: perf: Support sampling events using overflow interrupts

[Vineet Gupta]

On Monday 15 June 2015 09:55 PM, Peter Zijlstra wrote:
> On Tue, Jun 09, 2015 at 05:49:28PM +0530, Vineet Gupta wrote:
>> +if (arc_pmu->has_interrupts) {
>> +int irq = platform_get_irq(pdev, 0);
> Hmm, so you're requesting a regular interrupt.
>
> I see your architecture has IRQ priorities, could you play games and
> create NMIs using those?
>
> For example, never mask L1 (assuming that's the highest priority) and
> treat that as an NMI.

I've had this idea before, however, while ARCv2 provides hardware interrupt
priorities, we really can't implement true NMI, because CLRI / SETI used at
backend of loal_irq_save() / restore() impact all priorities (statsu32 register
has a global enable interrupt bit which these wiggle). So e.g. a
spin_lock_irqsave() will lock out even the perf interrupt.

OTOH, we can improve the perf isr path a bit - by not routing it thru regular
interrupt return path (song and dance of CONFIG_PREEMPT_IRQ and possible
preemption). Plus there's a bit more we can do in the isr itself - not looping
thru 32 counters etc using ffs() etc - but I'd rather do that as separate 
series,
once we have the core support in.

-Vineet




--
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 17/20 v1] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API

[Sreekanth Reddy]

Created a thread using alloc_ordered_workqueue() API in order to process
the works from firmware Work-queue sequentially instead of
create_singlethread_workqueue() API.

Changes in v1:
No need to check for backport compatibility in the upstream kernel.
so removing the else section where driver use 
create_singlethread_workqueue() API if alloc_ordered_workqueue() API is
not defined, This else section is not required since in the latest upstream
kernel this alloc_ordered_workqueue() API is always defined.

Signed-off-by: Sreekanth Reddy 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index b848458..7e5926c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -8085,8 +8085,8 @@ _scsih_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
/* event thread */
snprintf(ioc->firmware_event_name, sizeof(ioc->firmware_event_name),
"fw_event%d", ioc->id);
-   ioc->firmware_event_thread = create_singlethread_workqueue(
-   ioc->firmware_event_name);
+   ioc->firmware_event_thread = alloc_ordered_workqueue(
+   ioc->firmware_event_name, WQ_MEM_RECLAIM);
if (!ioc->firmware_event_thread) {
pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
ioc->name, __FILE__, __LINE__, __func__);
-- 
2.0.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/

Re: [RFC NEXT] mm: Fix suspicious RCU usage at kernel/sched/core.c:7318

[Kamalesh Babulal]

* Larry Finger  [2015-06-15 16:25:18]:

> Beginning at commit d52d399, the following INFO splat is logged:
> 

[...]

> ---
>  include/linux/kmemleak.h |  3 ++-
>  mm/kmemleak.c|  9 +
>  mm/kmemleak.c.rej| 19 +++
>  mm/percpu.c  |  2 +-
>  4 files changed, 27 insertions(+), 6 deletions(-)
>  create mode 100644 mm/kmemleak.c.rej

Patch creates kmemleak.c.rej file.


Regards,
Kamalesh.

--
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/6] mm, compaction: simplify handling restart position in free pages scanner

[Joonsoo Kim]

On Wed, Jun 10, 2015 at 11:32:30AM +0200, Vlastimil Babka wrote:
> Handling the position where compaction free scanner should restart (stored in
> cc->free_pfn) got more complex with commit e14c720efdd7 ("mm, compaction:
> remember position within pageblock in free pages scanner"). Currently the
> position is updated in each loop iteration of isolate_freepages(), although it
> should be enough to update it only when breaking from the loop. There's also
> an extra check outside the loop updates the position in case we have met the
> migration scanner.
> 
> This can be simplified if we move the test for having isolated enough from the
> for loop header next to the test for contention, and determining the restart
> position only in these cases. We can reuse the isolate_start_pfn variable for
> this instead of setting cc->free_pfn directly. Outside the loop, we can simply
> set cc->free_pfn to current value of isolate_start_pfn without any extra 
> check.
> 
> Also add a VM_BUG_ON to catch possible mistake in the future, in case we later
> add a new condition that terminates isolate_freepages_block() prematurely
> without also considering the condition in isolate_freepages().
> 
> Signed-off-by: Vlastimil Babka 

Acked-by: Joonsoo Kim 

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/

[PATCH 14/20 v1] [SCSI] mpt3sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081

[Sreekanth Reddy]

For any SCSI command, if the driver receives
IOC status = SCSI_IOC_TERMINATED and log info = 0x32010081 then
that command will be completed with DID_RESET host status.

The definition of this log info value is
"Virtual IO has failed and has to be retried".

Firmware will provide this log info value with IOC Status
"SCSI_IOC_TERMINATED", whenever a drive (with is a part of a volume)
is pulled and pushed back within some minimal delay.
With this log info value, firmware informs the driver to retry the
failed IO command infinite times, so to provide some time for the
firmware to discover the reinserted drive successfully instated of
just retrying failed command for five times(doesn't giving enough
time for firmware to complete the drive discovery) and failing the
IO permanently even though drive came back successfully.

Changes in v1:
   Defined macro VIRTUAL_IO_FAILED_RETRY for magic a value 0x32010081

Signed-off-by: Sreekanth Reddy 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  | 2 ++
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 0ffe763..f3f79be 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -203,6 +203,8 @@
 #define MFG10_GF0_SSD_DATA_SCRUB_DISABLE   (0x0008)
 #define MFG10_GF0_SINGLE_DRIVE_R0  (0x0010)
 
+#define VIRTUAL_IO_FAILED_RETRY(0x32010081)
+
 /* OEM Specific Flags will come from OEM specific header files */
 struct Mpi2ManufacturingPage10_t {
MPI2_CONFIG_PAGE_HEADER Header; /* 00h */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 7060c8b..7587f77 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -4302,6 +4302,9 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
scmd->device->expecting_cc_ua = 1;
}
break;
+   } else if (log_info == VIRTUAL_IO_FAILED_RETRY) {
+   scmd->result = DID_RESET << 16;
+   break;
}
scmd->result = DID_SOFT_ERROR << 16;
break;
-- 
2.0.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/

Re: [PATCH 1/6] mm, compaction: more robust check for scanners meeting

[Joonsoo Kim]

On Wed, Jun 10, 2015 at 11:32:29AM +0200, Vlastimil Babka wrote:
> Compaction should finish when the migration and free scanner meet, i.e. they
> reach the same pageblock. Currently however, the test in compact_finished()
> simply just compares the exact pfns, which may yield a false negative when the
> free scanner position is in the middle of a pageblock and the migration 
> scanner
> reaches the beginning of the same pageblock.
> 
> This hasn't been a problem until commit e14c720efdd7 ("mm, compaction: 
> remember
> position within pageblock in free pages scanner") allowed the free scanner
> position to be in the middle of a pageblock between invocations.  The hot-fix
> 1d5bfe1ffb5b ("mm, compaction: prevent infinite loop in compact_zone")
> prevented the issue by adding a special check in the migration scanner to
> satisfy the current detection of scanners meeting.
> 
> However, the proper fix is to make the detection more robust. This patch
> introduces the compact_scanners_met() function that returns true when the free
> scanner position is in the same or lower pageblock than the migration scanner.
> The special case in isolate_migratepages() introduced by 1d5bfe1ffb5b is
> removed.
> 
> Suggested-by: Joonsoo Kim 
> Signed-off-by: Vlastimil Babka 

Acked-by: Joonsoo Kim 

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 v7 00/37] perf tools: filtering events using eBPF programs

[Wangnan (F)]

On 2015/6/13 0:58, Alexei Starovoitov wrote:


btw, what compile times do you see?
On my machine compiling basic hello_world.c with #include bpf_helpers.h
and few kernel headers take: 0.02 sec
So using .c is quite instant. Feels like interpreted language ;)


Sorry I didn't see your question for several days.

It takes 1.63 seconds for perf to compile lock_page.c I posted in 
previous mail.
Most of the time is consumed by kernel include directories detection. If 
skip the

detector and passes options through cmdline, time reduced to 0.2 seconds. My
environment is a server equipped with Intel Xeon 2.4G cores. However the 
storage

is NFS based.

Thank you.


--
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 0/3] Add support for X51-R3 to alienware-wmi

[Mario Limonciello]

On 06/03/2015 06:17 PM, Mario Limonciello wrote:


On 05/27/2015 02:36 PM, Limonciello, Mario wrote:

An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when particular hardware
is used in conjunction.

Mario Limonciello (3):
Add support for X51-R3
Add support for Alienware graphics amplifier.
Capture cable events created by Alienware GFX Amplifier.

   drivers/platform/x86/Kconfig |   1 +
   drivers/platform/x86/alienware-wmi.c | 179 
++-
   2 files changed, 156 insertions(+), 24 deletions(-)


Matthew,

Aside from the third patch which has unfavorable feedback from Greg, any
thoughts on the first two?  I purposefully broke them up and would like
to get the first two included even if some variation of the third ends
up not landing.

Thanks,


Hi Matthew,

I wanted to check in once more on the first two patches.  If you've got 
them queued up for inclusion in a future kernel already please let me 
know.  If any changes are needed I'd like to get them taken care of.


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/

[PATCH 2/2] Staging: sm750fb: correct spacing between lines of code

[Dighe, Niranjan (N.)]

From: Niranjan Dighe 

This patch corrects line spacing by removing and adding newline
characters wherever necessary

Signed-off-by: Niranjan Dighe 
---
 drivers/staging/sm750fb/ddk750_dvi.h |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_dvi.h 
b/drivers/staging/sm750fb/ddk750_dvi.h
index c8d31f3..83bbd6d 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.h
+++ b/drivers/staging/sm750fb/ddk750_dvi.h
@@ -14,6 +14,7 @@ typedef long (*PFN_DVICTRL_INIT)(
unsigned char continuousSyncEnable,
unsigned char pllFilterEnable,
unsigned char pllFilterValue);
+
 typedef void (*PFN_DVICTRL_RESETCHIP)(void);
 typedef char* (*PFN_DVICTRL_GETCHIPSTRING)(void);
 typedef unsigned short (*PFN_DVICTRL_GETVENDORID)(void);
@@ -24,8 +25,6 @@ typedef unsigned char (*PFN_DVICTRL_ISCONNECTED)(void);
 typedef unsigned char (*PFN_DVICTRL_CHECKINTERRUPT)(void);
 typedef void (*PFN_DVICTRL_CLEARINTERRUPT)(void);
 
-
-
 /* Structure to hold all the function pointer to the DVI Controller. */
 typedef struct _dvi_ctrl_device_t
 {
@@ -40,9 +39,8 @@ typedef struct _dvi_ctrl_device_t
PFN_DVICTRL_CHECKINTERRUPT  pfnCheckInterrupt;
PFN_DVICTRL_CLEARINTERRUPT  pfnClearInterrupt;
 } dvi_ctrl_device_t;
-#define DVI_CTRL_SII164
-
 
+#define DVI_CTRL_SII164
 
 /* dvi functions prototype */
 int dviInit(
@@ -61,7 +59,5 @@ int dviInit(
 unsigned short dviGetVendorID(void);
 unsigned short dviGetDeviceID(void);
 
-
-
 #endif
 
-- 
1.7.9.5
--
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] Staging: sm750fb: replace spaces by tabs

[Dighe, Niranjan (N.)]

From: Niranjan Dighe 

This patch replaces spaces by tabs at the start of the line and in
between variable declarations.

Signed-off-by: Niranjan Dighe 
---
 drivers/staging/sm750fb/ddk750_dvi.h |   60 +-
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_dvi.h 
b/drivers/staging/sm750fb/ddk750_dvi.h
index 50bcec2..c8d31f3 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.h
+++ b/drivers/staging/sm750fb/ddk750_dvi.h
@@ -4,16 +4,16 @@
 /* dvi chip stuffs structros */
 
 typedef long (*PFN_DVICTRL_INIT)(
-unsigned char edgeSelect,
-unsigned char busSelect,
-unsigned char dualEdgeClkSelect,
-unsigned char hsyncEnable,
-unsigned char vsyncEnable,
-unsigned char deskewEnable,
-unsigned char deskewSetting,
-unsigned char continuousSyncEnable,
-unsigned char pllFilterEnable,
-unsigned char pllFilterValue);
+   unsigned char edgeSelect,
+   unsigned char busSelect,
+   unsigned char dualEdgeClkSelect,
+   unsigned char hsyncEnable,
+   unsigned char vsyncEnable,
+   unsigned char deskewEnable,
+   unsigned char deskewSetting,
+   unsigned char continuousSyncEnable,
+   unsigned char pllFilterEnable,
+   unsigned char pllFilterValue);
 typedef void (*PFN_DVICTRL_RESETCHIP)(void);
 typedef char* (*PFN_DVICTRL_GETCHIPSTRING)(void);
 typedef unsigned short (*PFN_DVICTRL_GETVENDORID)(void);
@@ -29,16 +29,16 @@ typedef void (*PFN_DVICTRL_CLEARINTERRUPT)(void);
 /* Structure to hold all the function pointer to the DVI Controller. */
 typedef struct _dvi_ctrl_device_t
 {
-PFN_DVICTRL_INITpfnInit;
-PFN_DVICTRL_RESETCHIP   pfnResetChip;
-PFN_DVICTRL_GETCHIPSTRING   pfnGetChipString;
-PFN_DVICTRL_GETVENDORID pfnGetVendorId;
-PFN_DVICTRL_GETDEVICEID pfnGetDeviceId;
-PFN_DVICTRL_SETPOWERpfnSetPower;
-PFN_DVICTRL_HOTPLUGDETECTIONpfnEnableHotPlugDetection;
-PFN_DVICTRL_ISCONNECTED pfnIsConnected;
-PFN_DVICTRL_CHECKINTERRUPT  pfnCheckInterrupt;
-PFN_DVICTRL_CLEARINTERRUPT  pfnClearInterrupt;
+   PFN_DVICTRL_INITpfnInit;
+   PFN_DVICTRL_RESETCHIP   pfnResetChip;
+   PFN_DVICTRL_GETCHIPSTRING   pfnGetChipString;
+   PFN_DVICTRL_GETVENDORID pfnGetVendorId;
+   PFN_DVICTRL_GETDEVICEID pfnGetDeviceId;
+   PFN_DVICTRL_SETPOWERpfnSetPower;
+   PFN_DVICTRL_HOTPLUGDETECTIONpfnEnableHotPlugDetection;
+   PFN_DVICTRL_ISCONNECTED pfnIsConnected;
+   PFN_DVICTRL_CHECKINTERRUPT  pfnCheckInterrupt;
+   PFN_DVICTRL_CLEARINTERRUPT  pfnClearInterrupt;
 } dvi_ctrl_device_t;
 #define DVI_CTRL_SII164
 
@@ -46,16 +46,16 @@ typedef struct _dvi_ctrl_device_t
 
 /* dvi functions prototype */
 int dviInit(
-unsigned char edgeSelect,
-unsigned char busSelect,
-unsigned char dualEdgeClkSelect,
-unsigned char hsyncEnable,
-unsigned char vsyncEnable,
-unsigned char deskewEnable,
-unsigned char deskewSetting,
-unsigned char continuousSyncEnable,
-unsigned char pllFilterEnable,
-unsigned char pllFilterValue
+   unsigned char edgeSelect,
+   unsigned char busSelect,
+   unsigned char dualEdgeClkSelect,
+   unsigned char hsyncEnable,
+   unsigned char vsyncEnable,
+   unsigned char deskewEnable,
+   unsigned char deskewSetting,
+   unsigned char continuousSyncEnable,
+   unsigned char pllFilterEnable,
+   unsigned char pllFilterValue
 );
 
 unsigned short dviGetVendorID(void);
-- 
1.7.9.5
--
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 17/20] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API

[Sreekanth Reddy]

On Tue, Jun 16, 2015 at 2:35 AM, James Bottomley
 wrote:
> On Mon, 2015-06-15 at 16:26 +0530, Sreekanth Reddy wrote:
>> On Sat, Jun 13, 2015 at 2:33 AM, Joe Lawrence  
>> wrote:
>> > On 06/12/2015 05:42 AM, Sreekanth Reddy wrote:
>> > ...
>> >> +#if defined(alloc_ordered_workqueue)
>> >> + ioc->firmware_event_thread = alloc_ordered_workqueue(
>> >> + ioc->firmware_event_name, WQ_MEM_RECLAIM);
>> >> +#else
>> >> + ioc->firmware_event_thread = create_singlethread_workqueue(
>> >>   ioc->firmware_event_name);
>> >> +#endif
>> >
>> > Hi Sreekanth,
>> >
>> > I think the upstream version of this code can safely assume
>> > alloc_ordered_workqueue is defined, no?
>>
>> yes, upstream version of this code can safely assume that
>> alloc_ordered_workqueue is defined.
>>
>> While working in-house, I observed that some of the older kernels
>> doesn't defined this macro, so I have added this else section.
>
> The driver has to be defined for the current kernel.  If you maintain a
> backport, that's fine, but not in the upstream driver.  The reasons are
> fairly pragmatic: this code in the #else clause can't be compiled so
> it's just junk to the upstream driver and the static checkers will find
> it and you'll attract a flock of patches removing dead code.
>
Accepted. I will post next version of this patch by removing the else section.

Thanks,
Sreekanth


> James
>
>



-- 

Regards,
Sreekanth
--
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: linux-next: manual merge of the staging tree with the rdma tree

[Greg KH]

On Mon, Jun 15, 2015 at 06:12:11PM +1000, Michael Ellerman wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c between commit 
> 8e37210b38fb
> "IB/core: Change ib_create_cq to use struct ib_cq_init_attr" from the rdma 
> tree
> and commit ec3d17c0ed2e "staging: lustre: lnet: o2iblnd: code cleanup - align
> whitespace" from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> cheers
> 
> 
> diff --cc drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> index c41b5575df05,48454a576b7a..
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> @@@ -642,18 -643,17 +643,18 @@@ kib_conn_t *kiblnd_create_conn(kib_peer
>* she must dispose of 'cmid'.  (Actually I'd block forever if I tried
>* to destroy 'cmid' here since I'm called from the CM which still has
>* its ref on 'cmid'). */
> - rwlock_t*glock = _data.kib_global_lock;
> - kib_net_t *net = peer->ibp_ni->ni_data;
> - kib_dev_t *dev;
> + rwlock_t *glock = _data.kib_global_lock;
> + kib_net_t *net = peer->ibp_ni->ni_data;
> + kib_dev_t *dev;
>   struct ib_qp_init_attr *init_qp_attr;
> - struct kib_sched_info   *sched;
> - struct ib_cq_init_attr  cq_attr = {};
> - kib_conn_t  *conn;
> - struct ib_cq*cq;
> - unsigned long   flags;
> - int cpt;
> - int rc;
> - int i;
> + struct kib_sched_info *sched;
> ++struct ib_cq_init_attr cq_attr = {};
> + kib_conn_t *conn;
> + struct ib_cq *cq;
> + unsigned long flags;
> + int cpt;
> + int rc;
> + int i;

Looks good to me, thanks.

greg k-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 RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 09:06 PM, Herbert Xu wrote:
>> No, it will handle whatever it will find. So if a public key will be passed 
>> it will only set "n" and "e".
>> > If a private key will be passed it will set all three "n", "e", and "d".
>> > Then during operation I check if there is everything that's required.
> AFAICS the ASN1 parser will call all three functions and bomb out
> if any one of them fails.  If you did make them all optional then
> you'd need to check to ensure that at least n and e are present.
> 
> Also all your test vectors contain private keys.  Please add at
> least one that contains a public key only to test this.

I've just tested it and it works fine for both private and public keys.
I'll add one vector to test only public key case.
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/

cpu hot-remove bug

[范冬冬]

Hi maintainer,

We found a problem that a panic happen when cpu was hot-removed. We also trace 
the problem according to the calltrace information. 
An endless loop happen because value head is not equal to value tail forever in 
the function qi_check_fault( ). 
The location code is as follows: 


do { 
if (qi->desc_status[head] == QI_IN_USE) 
qi->desc_status[head] = QI_ABORT; 
head = (head - 2 + QI_LENGTH) % QI_LENGTH; 
} while (head != tail); 



Follow is the panic information: 

[root@localhost ~]lscpu 
Architecture: x86_64 
CPU op-mode(s): 32-bit, 64-bit 
Byte Order: Little Endian 
CPU(s): 120 
On-line CPU(s) list: 0-119 
Thread(s) per core: 2 
Core(s) per socket: 15 
Socket(s): 4 
NUMA node(s): 1 
Vendor ID: GenuineIntel 
CPU family: 6 
Model: 62 
Model name: Intel(R) Xeon(R) CPU E7-8880 v2 @ 2.50GHz 
Stepping: 7 
CPU MHz: 2973.535 
BogoMIPS: 5008.11 
Virtualization: VT-x 
L1d cache: 32K 
L1i cache: 32K 
L2 cache: 256K 
L3 cache: 38400K 
NUMA node0 CPU(s): 0-119 
[root@localhost ~]# echo 1 > /sys/firmware/acpi/hotplug/force_remove 
[root@localhost ~]# echo 1 > 
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:01/eject 
[ 138.217913] intel_pstate CPU 15 exiting 
[ 138.249976] kvm: disabling virtualization on CPU15 
[ 138.256008] smpboot: CPU 15 is now offline 
[ 138.364245] intel_pstate CPU 75 exiting 
[ 138.389285] Broke affinity for irq 47 
[ 138.394433] kvm: disabling virtualization on CPU75 
[ 138.400193] smpboot: CPU 75 is now offline 
[ 139.119913] intel_pstate CPU 16 exiting 
[ 139.146122] kvm: disabling virtualization on CPU16 
[ 139.159401] smpboot: CPU 16 is now offline 
[ 139.183872] intel_pstate CPU 76 exiting 
[ 139.215591] kvm: disabling virtualization on CPU76 
[ 139.221226] smpboot: CPU 76 is now offline 
[ 139.971687] intel_pstate CPU 17 exiting 
[ 140.003541] kvm: disabling virtualization on CPU17 
[ 140.009286] smpboot: CPU 17 is now offline 
[ 140.038648] intel_pstate CPU 77 exiting 
[ 140.064705] kvm: disabling virtualization on CPU77 
[ 140.070292] smpboot: CPU 77 is now offline 
[ 140.291735] intel_pstate CPU 18 exiting 
[ 140.306457] kvm: disabling virtualization on CPU18 
[ 140.314712] smpboot: CPU 18 is now offline 
[ 140.343928] intel_pstate CPU 78 exiting 
[ 140.369473] kvm: disabling virtualization on CPU78 
[ 140.378172] smpboot: CPU 78 is now offline 
[ 140.522952] intel_pstate CPU 19 exiting 
[ 140.537781] kvm: disabling virtualization on CPU19 
[ 140.545436] smpboot: CPU 19 is now offline 
[ 140.571167] intel_pstate CPU 79 exiting 
[ 140.591320] kvm: disabling virtualization on CPU79 
[ 140.597138] smpboot: CPU 79 is now offline 
[ 140.735166] intel_pstate CPU 20 exiting 
[ 140.750057] kvm: disabling virtualization on CPU20 
[ 140.755738] smpboot: CPU 20 is now offline 
[ 140.780342] intel_pstate CPU 80 exiting 
[ 140.797354] kvm: disabling virtualization on CPU80 
[ 140.803083] smpboot: CPU 80 is now offline 
[ 140.937355] intel_pstate CPU 21 exiting 
[ 140.955338] kvm: disabling virtualization on CPU21 
[ 140.962774] smpboot: CPU 21 is now offline 
[ 140.985552] intel_pstate CPU 81 exiting 
[ 141.002056] kvm: disabling virtualization on CPU81 
[ 141.007721] smpboot: CPU 81 is now offline 
[ 141.181624] intel_pstate CPU 22 exiting 
[ 141.199390] kvm: disabling virtualization on CPU22 
[ 141.205059] smpboot: CPU 22 is now offline 
[ 141.230659] intel_pstate CPU 82 exiting 
[ 141.250371] kvm: disabling virtualization on CPU82 
[ 141.256080] smpboot: CPU 82 is now offline 
[ 141.405812] intel_pstate CPU 23 exiting 
[ 141.420677] kvm: disabling virtualization on CPU23 
[ 141.426406] smpboot: CPU 23 is now offline 
[ 141.450894] intel_pstate CPU 83 exiting 
[ 141.467542] kvm: disabling virtualization on CPU83 
[ 141.473283] smpboot: CPU 83 is now offline 
[ 141.654099] intel_pstate CPU 24 exiting 
[ 141.669299] kvm: disabling virtualization on CPU24 
[ 141.674959] smpboot: CPU 24 is now offline 
[ 141.701252] intel_pstate CPU 84 exiting 
[ 141.723850] kvm: disabling virtualization on CPU84 
[ 141.732427] smpboot: CPU 84 is now offline 
[ 141.871268] intel_pstate CPU 25 exiting 
[ 141.883049] kvm: disabling virtualization on CPU25 
[ 141.888690] smpboot: CPU 25 is now offline 
[ 141.915392] intel_pstate CPU 85 exiting 
[ 141.935412] kvm: disabling virtualization on CPU85 
[ 141.941056] smpboot: CPU 85 is now offline 
[ 142.102551] intel_pstate CPU 26 exiting 
[ 142.120636] kvm: disabling virtualization on CPU26 
[ 142.129233] smpboot: CPU 26 is now offline 
[ 142.152582] intel_pstate CPU 86 exiting 
[ 142.171197] Broke affinity for irq 27 
[ 142.176406] kvm: disabling virtualization on CPU86 
[ 142.181977] smpboot: CPU 86 is now offline 
[ 142.339730] intel_pstate CPU 27 exiting 
[ 142.354745] kvm: disabling virtualization on CPU27 
[ 142.362048] smpboot: CPU 27 is now offline 
[ 142.387910] intel_pstate CPU 87 exiting 
[ 142.403435] Broke affinity for irq 16 
[ 142.408612] kvm: disabling virtualization on CPU87 
[ 142.414266] smpboot: CPU 87 is 

Re: [PATCH V2 4/7] clocksource: bcm2835: Migrate to new 'set-state' interface

[Viresh Kumar]

On 15-06-15, 22:16, Stephen Warren wrote:
> I see. You didn't Cc me on patch 1, and didn't mention the dependency in
> this patch. That usually means they're all independent, e.g. the same
> change in n different drivers.

Yeah, I cc'd you on the cover-letter and missed it on the first patch.
My fault. Actually during V1 the first patch wasn't there and so there
was no dependency, but in V2 this patch came in and I completely
forgot you and other guys for that patch.

> Anyway, I tracked down the whole series and applied it on top of
> next-20150615 and everything seems OK (kernel boots, and UART, USB kbd &
> SD card work), so this patch,
> Tested-by: Stephen Warren 

Thanks a lot Stephen.

-- 
viresh
--
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] staging: rtl8188eu: kill unused INCLUDE_MULTI_FUNC_* macros

[Jakub Sitnicki]

Also, remove rt_multi_func enum used exclusively by the killed macros.

Signed-off-by: Jakub Sitnicki 
---
 drivers/staging/rtl8188eu/include/rtl8188e_hal.h | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h 
b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
index b8c42ee..de1e1c8 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
@@ -188,14 +188,6 @@ struct txpowerinfo24g {
 
 #define EFUSE_PROTECT_BYTES_BANK   16
 
-/*  For RTL8723 WiFi/BT/GPS multi-function configuration. */
-enum rt_multi_func {
-   RT_MULTI_FUNC_NONE = 0x00,
-   RT_MULTI_FUNC_WIFI = 0x01,
-   RT_MULTI_FUNC_BT = 0x02,
-   RT_MULTI_FUNC_GPS = 0x04,
-};
-
 /*  For RTL8723 regulator mode. */
 enum rt_regulator_mode {
RT_SWITCHING_REGULATOR = 0,
@@ -378,11 +370,6 @@ struct hal_data_8188e {
((struct hal_data_8188e *)((__pAdapter)->HalData))
 #define GET_RF_TYPE(priv)  (GET_HAL_DATA(priv)->rf_type)
 
-#define INCLUDE_MULTI_FUNC_BT(_Adapter)\
-   (GET_HAL_DATA(_Adapter)->MultiFunc & RT_MULTI_FUNC_BT)
-#define INCLUDE_MULTI_FUNC_GPS(_Adapter)   \
-   (GET_HAL_DATA(_Adapter)->MultiFunc & RT_MULTI_FUNC_GPS)
-
 /*  rtl8188e_hal_init.c */
 void _8051Reset88E(struct adapter *padapter);
 void rtl8188e_InitializeFirmwareVars(struct adapter *padapter);
-- 
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/

Re: [PATCH V2 4/7] clocksource: bcm2835: Migrate to new 'set-state' interface

[Stephen Warren]

On 06/15/2015 09:17 PM, Viresh Kumar wrote:
> On 15-06-15, 20:57, Stephen Warren wrote:
>> On 06/12/2015 02:00 AM, Viresh Kumar wrote:
>>> Migrate bcm2835 driver to the new 'set-state' interface provided by
>>> the clockevents core, the earlier 'set-mode' interface is marked
>>> obsolete now.
>>>
>>> This also enables us to implement callbacks for new states of clockevent
>>> devices, for example: ONESHOT_STOPPED.
>>>
>>> We weren't doing anything in the ->set_mode() callback. So, this patch
>>> doesn't provide any set-state callbacks.
>>
>> This generates a panic at boot (on top of 4.1.0-rc8+, which certainly at
>> least booted fine):
>>
>>> [0.008586] clocksource timer: mask: 0x max_cycles: 0x, 
>>> max_idle_ns: 1911260446275 ns
>>> [0.018080] [ cut here ]
>>> [0.022843] kernel BUG at kernel/time/clockevents.c:480!
>>> [0.028299] Internal error: Oops - BUG: 0 [#1] ARM
>>> [0.033237] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.0-rc8+ #46
>>> [0.039567] Hardware name: BCM2835
>>> [0.043092] task: c06fb648 ti: c06f6000 task.ti: c06f6000
>>> [0.048668] PC is at clockevents_register_device+0x15c/0x174
> 
> This failed the sanity checks of clockevents core. Did you apply the
> first patch as well? Yes, its very much required.
> 
> Also, there were dependencies on the latest tip, prepared for 4.2
> merge window and would have been better if you tested on top of that.
> 
> But those dependencies are for some helpers which aren't used in this
> patch. So, it might work over rc8 + the first patch from this series..
> 
> In case it doesn't, please test it over tip/master once.

I see. You didn't Cc me on patch 1, and didn't mention the dependency in
this patch. That usually means they're all independent, e.g. the same
change in n different drivers.

Anyway, I tracked down the whole series and applied it on top of
next-20150615 and everything seems OK (kernel boots, and UART, USB kbd &
SD card work), so this patch,
Tested-by: Stephen Warren 
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 08:36:06PM -0700, Tadeusz Struk wrote:
> On 06/15/2015 08:25 PM, Herbert Xu wrote:
> > The current parse_key function requires all three number to be
> > present, n, e, and d, no?
> 
> No, it will handle whatever it will find. So if a public key will be passed 
> it will only set "n" and "e".
> If a private key will be passed it will set all three "n", "e", and "d".
> Then during operation I check if there is everything that's required.

AFAICS the ASN1 parser will call all three functions and bomb out
if any one of them fails.  If you did make them all optional then
you'd need to check to ensure that at least n and e are present.

Also all your test vectors contain private keys.  Please add at
least one that contains a public key only to test this.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] powerpc/numa: initialize distance lookup table from drconf path

[Nikunj A Dadhania]

Nikunj A Dadhania  writes:

> Reworded commit log:
>
> From: Nikunj A Dadhania 
>
> powerpc/numa: initialize distance lookup table from drconf path
>

Ping ?

Regards
Nikunj

--
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 kernel] powerpc/iommu/ioda2: Enable compile with IOV=on and IOMMU_API=off

[David Gibson]

On Mon, Jun 15, 2015 at 05:49:59PM +1000, Alexey Kardashevskiy wrote:
> The pnv_pci_ioda2_unset_window() function is used to do the final
> cleanup of a DMA window being released:
> - via VFIO ioctl by the guest request;
> - via unplugging a virtual PCI function.
> However the function was under #ifdef CONFIG_IOMMU_API and was missing.
> 
> This moves the helper outside of IOMMU_API block and enables it
> for either or both IOMMU_API and PCI_IOV.
> 
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: David Gibson 
-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgpVXCGQy8xUv.pgp
Description: PGP signature

Re: [V6 PATCH 0/7] ACPI: Introduce support for _CCA object

[Suravee Suthikulpanit]

Thank you.

Suravee

On 6/15/15 18:24, Rafael J. Wysocki wrote:

On Wednesday, June 10, 2015 11:08:51 AM Suravee Suthikulpanit wrote:

This patch series introduce support for _CCA object, which is currently
used mainly by ARM64 platform to specify DMA coherency attribute for
devices when booting with ACPI.

A copy of ACPIv6 can be found here:
 http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf

This patch also introduces a new APIS:
 1. acpi_check_dma() as part of ACPI API.
 2. device_dma_is_coherent() as part of unified device property API.

This simplifies the logic in device drivers to determine device coherency
attribute regardless of booting with DT vs ACPI.

This has been tested on AMD-Seattle platform, which implements _CCA
object as described in the AMD Opteron A1100 Series Processor ACPI Porting 
Guide:

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf

Changes from V5 (https://lkml.org/lkml/2015/5/20/1033):
 * Fix build error in the megaraid and ufs driver
   (reported by Mark Salter)

Changes from V4 (https://lkml.org/lkml/2015/5/15/669):
 * Patch1:
   - Move the arch_setup_dma_ops() call from acpi_create_platform_device()
 to acpi_bind_one() to support other bus types (per Rafael).
   - Rename acpi_device_flags.is_coherent to acpi_device_flags.coherent_dma.
 (per Rafael)
   - Refactor acpi_dma_is_supported() and acpi_dma_is_coherent() to
 acpi_check_dma() to simplify the new interface.
   - Only support _CCA=1 for now. See acpi_check_dma() (per Arnd and 
Catalin)
 * Patch2:
   - Add acked-by Catalin.
 * Patch3:
   - Use ACPI_COMPANION() instead of acpi_node().
   - Remove has_acpi_companion() check since already done by acpi_node().
 (per Will)
 * Remove the patch "Generic function for setting up PCI device DMA 
coherency"
   introduced in V4. (per Bjorn)

Changes from V3 (https://lkml.org/lkml/2015/5/7/1004):
 * Remove ARCH64_SUPPORT_ACPI_CCA_ZERO and just use CONFIG_ARM64.
   (per Catalin and Rafael)
 * Do not need to call arch_setup_dma_ops() for acpi_device->dev.
   (per Rafael)
 * [3/6] (New) We also need to call arch_setup_dma_ops() for pci
   devices and check the CCA of the host bridge. Similar logic
   exists for OF. So, I refactor of_pci_dma_configure() to
   the more generic version pci_dma_configure(), and add support
   for ACPI.

Changes from V2 (https://lkml.org/lkml/2015/5/5/510):
 * Reword ACPI_MUST_HAVE_CCA to ACPI_CCA_REQUIRED (per Rafael)
 * Reword ACPI_SUPPORT_CCA_ZERO to ARCH64_SUPPORT_ACPI_CCA_ZERO
   (per Rafael and Arnd)
 * Misc code styling clean up (per Rafael)
 * Only print missing _CCA warning message in debug mode.
 * Refactor logic in acpi_setup_device_dma() into
   if acpi_dma_is_supported() then call arch_setup_dma_ops().
 * Do not allocate device dma_mask if !acpi_dma_is_supported()
   (per Arnd).
 * Re-use the dummy functions with the same signature.

Changes from V1 (https://lkml.org/lkml/2015/4/29/290):
 * Remove supports for 32-bit ARM since doesn't currently
   supporting ACPI (Per Catalin suggestions.)
 * Do not call arch_setup_dma_ops() and when _CCA is missing.
   (per Arnd suggestion)
 * Add CONFIG_ACPI_SUPPORT_CCA_ZERO kernel config flag to
   allow architectures to specify the behavior when _CCA=0.
 * Add dummy_dma_ops for ARM64 (per Catalin suggestions).
 * Fixed build error when ACPI is not configured by defining
   acpi_dma_is_coherent() for when CONFIG_ACPI is not set.
 * Introduce device_dma_is_coherent().
 * Use device_dma_is_coherent in crypto/ccp and amd-xgbe driver.

Changes from RFC: (https://lkml.org/lkml/2015/4/1/389)
 * New logic for deriving and propagating coherent attribute from
   parent devices. (by Mark)
 * Introducing acpi_dma_is_coherent() API (Per Tom suggestion)
 * Introducing CONFIG_ACPI_MUST_HAVE_CCA kernel configuration.
 * Rebased to linux-4.1-rc1

Suravee Suthikulpanit (7):
   ACPI / scan: Parse _CCA and setup device coherency
   arm64 : Introduce support for ACPI _CCA object
   device property: Introduces device_dma_is_coherent()
   crypto: ccp - Unify coherency checking logic with
 device_dma_is_coherent()
   amd-xgbe: Unify coherency checking logic with device_dma_is_coherent()
   megaraid_sas: fix TRUE and FALSE re-define build error
   ufs: fix TRUE and FALSE re-define build error

  arch/arm64/Kconfig|  1 +
  arch/arm64/include/asm/dma-mapping.h  | 18 +-
  arch/arm64/mm/dma-mapping.c   | 92 +++
  drivers/acpi/Kconfig  |  3 +
  drivers/acpi/acpi_platform.c  |  2 +-
  drivers/acpi/glue.c   |  5 ++
  drivers/acpi/scan.c   | 35 
  drivers/base/property.c   | 14 

RE: [BUG?] crypto: caam: little/big endianness on ARM vs PPC

[Victoria Milhoan]

All,

Freescale has been adding i.MX6 support to the CAAM driver and testing on both 
i.MX6 and QorIQ platforms. The patch series is now available for review. Your 
feedback for the provided patches is appreciated.

Thanks,
Victoria

-Original Message-
From: linux-crypto-ow...@vger.kernel.org 
[mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Herbert Xu
Sent: Monday, June 15, 2015 3:05 PM
To: Steffen Trumtrar
Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-cry...@vger.kernel.org; Gupta Ruchika-R66431; ker...@pengutronix.de; 
Geanta Neag Horia Ioan-B05471; Kim Phillips
Subject: Re: [BUG?] crypto: caam: little/big endianness on ARM vs PPC

On Mon, Jun 15, 2015 at 05:59:07PM +0200, Steffen Trumtrar wrote:
> Hi!
> 
> I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current 
> drivers/crypto/caam driver only works for PowerPC AFAIK.
> Actually, there isn't that much to do, to get support for the i.MX6 
> but one patch breaks the driver severely:
> 
>   commit ef94b1d834aace7101de77c3a7c2631b9ae9c5f6
>   crypto: caam - Add definition of rd/wr_reg64 for little endian 
> platform
> 
> This patch adds
> 
> +#ifdef __LITTLE_ENDIAN
> +static inline void wr_reg64(u64 __iomem *reg, u64 data) {
> + wr_reg32((u32 __iomem *)reg + 1, (data & 0xull) >> 32);
> + wr_reg32((u32 __iomem *)reg, data & 0xull); }
> 
> The wr_reg64 function is only used in one place in the 
> drivers/crypto/caam/jr.c
> driver: to write the dma_addr_t to the register. Without that patch 
> everything works fine on ARM (little endian, 32bit), with that patch 
> the driver will write 0's into the register that holds the DMA address (the 
> numerically-higher) -> kernel hangs.
> Also, from my understanding, the comment above the defines, stating 
> that you have to first write the numerically-lower and then the 
> numerically-higher address on 32bit systems doesn't match with the 
> implementation.
> 
> What I don't know/understand is if this makes any sense for any PowerPC 
> implementation.
> 
> So, the question is, how to fix this? I'd prefer to do it directly in 
> the jr driver instead of the ifdef-ery.
> 
> Something like
>   if (sizeof(dma_addr_t) == sizeof(u32))
>   wr_reg32(>rregs->inpring_base + 1, inpbusaddr);
>   else if (sizeof(dma_addr_t) == sizeof(u64))
>   wr_reg64(...)
> 
> or just go by DT compatible and then remove the inline function definitions.
> 
> As far as I can tell, the compatible wouldn't be needed for anything 
> else in the jr driver, so maybe that is not optimal. On the other hand 
> the sizeof(..) solution would only catch little endian on 32bit and 
> not big endian (?!) I however don't know what combinations actually 
> *have* to be caught, as I don't know, which exist.
> 
> So, what do you think people?

I'm adding a couple of CCs.

Thanks,
--
Email: Herbert Xu  Home Page: 
http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" 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: [lkp] [time] 78a0b9a793a: INFO: possible recursive locking detected ]

[John Stultz]

On Mon, Jun 15, 2015 at 8:15 PM, Huang Ying  wrote:
> FYI, we noticed the below changes on
>
> https://git.linaro.org/people/john.stultz/linux.git wip
> commit 78a0b9a793a36f73a9a3330dec00859e15d9ad6d ("time: Do leapsecond 
> adjustment in gettime fastpaths")
>
>
> +--+++
> |  | 4ae9e1e25d | 78a0b9a793 |
> +--+++
> | boot_successes   | 900| 263|
> | boot_failures| 0  | 37 |
> | INFO:possible_recursive_locking_detected | 0  | 37 |
> | BUG:spinlock_lockup_suspected_on_CPU | 0  | 15 |
> | EIP_is_at_native_apic_mem_write  | 0  | 15 |
> | EIP_is_at_read_seqcount_begin| 0  | 15 |
> | backtrace:SYSC_adjtimex  | 0  | 32 |
> | backtrace:SyS_adjtimex   | 0  | 32 |
> | backtrace:vfs_write  | 0  | 7  |
> | backtrace:SyS_write  | 0  | 7  |
> | BUG:kernel_test_hang | 0  | 22 |
> | backtrace:SYSC_clock_adjtime | 0  | 5  |
> | backtrace:SyS_clock_adjtime  | 0  | 5  |
> | backtrace:lru_add_drain_all  | 0  | 1  |
> | backtrace:SyS_mlock  | 0  | 2  |
> | backtrace:do_group_exit  | 0  | 1  |
> | backtrace:SyS_exit_group | 0  | 1  |
> | backtrace:cpu_startup_entry  | 0  | 3  |
> | backtrace:__mm_populate  | 0  | 1  |
> | backtrace:link_path_walk | 0  | 1  |
> | backtrace:path_init  | 0  | 1  |
> | backtrace:do_sys_open| 0  | 1  |
> | backtrace:SyS_open   | 0  | 1  |
> +--+++
>
>
> [   23.011400] VFS: Warning: trinity-c1 using old stat() call. Recompile your 
> binary.
> [   23.012387]
> [   23.012580] =
> [   23.013218] [ INFO: possible recursive locking detected ]
> [   23.013841] 4.1.0-rc5-01505-gd6201b6 #2 Not tainted
> [   23.014419] -
> [   23.015051] trinity-c1/22948 is trying to acquire lock:
> [   23.015657]  (tk_core){..}, at: [<4107d71c>] 
> timekeeping_get_ns+0x10/0xe8
> [   23.016564]
> [   23.016564] but task is already holding lock:
> [   23.017241]  (tk_core){..}, at: [<4107f150>] do_adjtimex+0x58/0xc2
> [   23.017380]
> [   23.017380] other info that might help us debug this:
> [   23.017380]  Possible unsafe locking scenario:
> [   23.017380]
> [   23.017380]CPU0
> [   23.017380]
> [   23.017380]   lock(tk_core);
> [   23.017380]   lock(tk_core);
> [   23.017380]
> [   23.017380]  *** DEADLOCK ***
> [   23.017380]
> [   23.017380]  May be due to missing lock nesting notation
> [   23.017380]
> [   23.017380] 2 locks held by trinity-c1/22948:
> [   23.017380]  #0:  (timekeeper_lock){-.-...}, at: [<4107f144>] 
> do_adjtimex+0x4c/0xc2
> [   23.017380]  #1:  (tk_core){..}, at: [<4107f150>] do_adjtimex+0x58/0xc2
> [   23.017380]
> [   23.017380] stack backtrace:
> [   23.017380] CPU: 1 PID: 22948 Comm: trinity-c1 Not tainted 
> 4.1.0-rc5-01505-gd6201b6 #2
> [   23.017380] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [   23.017380]    50211ddc 413ce68a 41c6a910 50211e50 
> 410646c2 41551379
> [   23.017380]  41551d81 4155126c  4fc09210 41c6a910 1f02 
>  7803e01f
> [   23.017380]   4fc09210  0002 4fc09238 4fc08d40 
> 41c506f0 4fc09208
> [   23.017380] Call Trace:
> [   23.017380]  [<413ce68a>] dump_stack+0x49/0x73
> [   23.017380]  [<410646c2>] __lock_acquire+0xb78/0xcd3
> [   23.017380]  [<4106414b>] ? __lock_acquire+0x601/0xcd3
> [   23.017380]  [<41064ad9>] lock_acquire+0x5b/0x7d
> [   23.017380]  [<4107d71c>] ? timekeeping_get_ns+0x10/0xe8
> [   23.017380]  [<4107d5f1>] read_seqcount_begin+0x2e/0x74
> [   23.017380]  [<4107d71c>] ? timekeeping_get_ns+0x10/0xe8
> [   23.017380]  [<4107d71c>] timekeeping_get_ns+0x10/0xe8
> [   23.017380]  [<4107f150>] ? do_adjtimex+0x58/0xc2
> [   23.017380]  [<4107dabf>] __getnstimeofday64_preleap+0x29/0x5d
> [   23.017380]  [<4107f158>] do_adjtimex+0x60/0xc2
> [   23.017380]  [<4107aa8e>] posix_clock_realtime_adj+0xa/0xc
> [   23.017380]  [<4107af8a>] SYSC_clock_adjtime+0x60/0x92
> [   23.017380]  [<4107b732>] SyS_clock_adjtime+0xe/0x10
> [   23.017380]  [<413d3aab>] syscall_call+0x7/0x7
> [   23.017380]  

Re: [PATCH RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 08:25 PM, Herbert Xu wrote:
> The current parse_key function requires all three number to be
> present, n, e, and d, no?

No, it will handle whatever it will find. So if a public key will be passed it 
will only set "n" and "e".
If a private key will be passed it will set all three "n", "e", and "d".
Then during operation I check if there is everything that's required.



--
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 RFC] storage:rbd: make the size of request is equal to the, size of the object

[juncheng bai]

On 2015/6/15 22:27, Ilya Dryomov wrote:

On Mon, Jun 15, 2015 at 4:23 PM, juncheng bai
 wrote:



On 2015/6/15 21:03, Ilya Dryomov wrote:


On Mon, Jun 15, 2015 at 2:18 PM, juncheng bai
 wrote:


  From 6213215bd19926d1063d4e01a248107dab8a899b Mon Sep 17 00:00:00 2001
From: juncheng bai 
Date: Mon, 15 Jun 2015 18:34:00 +0800
Subject: [PATCH] storage:rbd: make the size of request is equal to the
   size of the object

ensures that the merged size of request can achieve the size of
the object.
when merge a bio to request or merge a request to request, the
sum of the segment number of the current request and the segment
number of the bio is not greater than the max segments of the request,
so the max size of request is 512k if the max segments of request is
BLK_MAX_SEGMENTS.

Signed-off-by: juncheng bai 
---
   drivers/block/rbd.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 0a54c58..dec6045 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -3757,6 +3757,8 @@ static int rbd_init_disk(struct rbd_device
*rbd_dev)
  segment_size = rbd_obj_bytes(_dev->header);
  blk_queue_max_hw_sectors(q, segment_size / SECTOR_SIZE);
  blk_queue_max_segment_size(q, segment_size);
+   if (segment_size > BLK_MAX_SEGMENTS * PAGE_SIZE)
+   blk_queue_max_segments(q, segment_size / PAGE_SIZE);
  blk_queue_io_min(q, segment_size);
  blk_queue_io_opt(q, segment_size);



I made a similar patch on Friday, investigating blk-mq plugging issue
reported by Nick.  My patch sets it to BIO_MAX_PAGES unconditionally -
AFAIU there is no point in setting to anything bigger since the bios
will be clipped to that number of vecs.  Given that BIO_MAX_PAGES is
256, this gives is 1M direct I/Os.


Hi. For signal bio, the max number of bio_vec is BIO_MAX_PAGES, but a
request can be merged from multiple bios. We can see the below function:
ll_back_merge_fn, ll_front_merge_fn and etc.
And I test in kernel 3.18 use this patch, and do:
echo 4096 > /sys/block/rbd0/queue/max_sectors_kb
We use systemtap to trace the request size, It is upto 4M.


Kernel 3.18 is pre rbd blk-mq transition, which happened in 4.0.  You
should test whatever patches you have with at least 4.0.

Putting that aside, I must be missing something.  You'll get 4M
requests on 3.18 both with your patch and without it, the only
difference would be the size of bios being merged - 512k vs 1M.  Can
you describe your test workload and provide before and after traces?


Hi. I update kernel version to 4.0.5. The test information as shown below:
The base information:
03:28:13-root@server-186:~$uname -r
4.0.5

My simple systemtap script:
probe module("rbd").function("rbd_img_request_create")
{
printf("offset:%lu length:%lu\n", ulong_arg(2), ulong_arg(3));
}

I use dd to execute the test case:
dd if=/dev/zero  of=/dev/rbd0 bs=4M count=1 oflag=direct

Case one: Without patch
03:30:23-root@server-186:~$cat /sys/block/rbd0/queue/max_sectors_kb
4096
03:30:35-root@server-186:~$cat /sys/block/rbd0/queue/max_segments
128

The output of systemtap for nornal data:
offset:0 length:524288
offset:524288 length:524288
offset:1048576 length:524288
offset:1572864 length:524288
offset:2097152 length:524288
offset:2621440 length:524288
offset:3145728 length:524288
offset:3670016 length:524288

Case two:With patch
cat /sys/block/rbd0/queue/max_sectors_kb
4096
03:49:14-root@server-186:linux-4.0.5$cat /sys/block/rbd0/queue/max_segments
1024
The output of systemtap for nornal data:
offset:0 length:1048576
offset:1048576 length:1048576
offset:2097152 length:1048576
offset:3145728 length:1048576

According to the test, you are right.
Because the blk-mq doesn't use any scheduling policy.
03:52:13-root@server-186:linux-4.0.5$cat /sys/block/rbd0/queue/scheduler
none

In previous versions of the kernel 4.0, the rbd use the defualt 
scheduler:cfq


So, I think that the blk-mq need to do more?

Thanks,

 Ilya


--
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 net-next 0/3] bpf: share helpers between tracing and networking

[Alexei Starovoitov]

On 6/15/15 4:01 PM, David Miller wrote:


Although I agree with the sentiment that this thing can cause
surprising results and can be asking for trouble.

If someone wants to filter traffic "by UID" they might make
a simple ingress TC ebpf program using these new interfaces
and expect it to work.

But the UID their program will see will be the UID of whatever
randomly happened to be executing when the packet was received
and processed.


yes, you're right. Such tc filters will be incorrect.
Will send a partial revert disallowing them in tc.

--
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 RESEND v4 1/3] kvm/powerpc: Export kvm exit reasons

[Hemant Kumar]

Hi Paul,

On 06/15/2015 11:09 AM, Paul Mackerras wrote:

On Mon, Jun 15, 2015 at 10:26:07AM +0530, Hemant Kumar wrote:

To analyze the kvm exits with perf, we will need to map the exit codes
with the exit reasons. Such a mapping exists today in trace_book3s.h.
Currently its not exported to perf.

This patch moves these kvm exit reasons and their mapping from
"arch/powerpc/kvm/trace_book3s.h" to
"arch/powerpc/include/uapi/asm/trace_book3s.h".
Accordingly change the include files in "trace_hv.h" and "trace_pr.h".

These are not really exit reasons so much as Power ISA interrupt
vectors, defined externally to the kernel (in the Power ISA document)
and not subject to change (at least, kernel developers can't change
them).  So I don't see why this needs to be "exported" from the
kernel.

Paul.



The exit reasons are needed in the perf userspace and we wanted to avoid
code duplication, so, if there are any changes, we won't need to update them
at both places.
However, we could add them to perf userspace itself separately and let perf
userspace use those.

What would you suggest?

--
Thanks,
Hemant Kumar

--
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] drivers/cpufreq: include for modular exynos-cpufreq.c code

[Paul Gortmaker]

On Mon, Jun 15, 2015 at 7:53 PM, Krzysztof Kozlowski
 wrote:
> On 16.06.2015 08:47, Rafael J. Wysocki wrote:
>> On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
>>> This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ")
>>> and also contains modular function calls so it should explicitly include
>>> module.h to avoid compile breakage during pending header shuffles.
>>>
>>> Cc: "Rafael J. Wysocki" 
>>> Cc: Viresh Kumar 
>>> Cc: Kukjin Kim 
>>> Cc: Krzysztof Kozlowski 
>>> Cc: linux...@vger.kernel.org
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-samsung-...@vger.kernel.org
>>> Signed-off-by: Paul Gortmaker 
>>
>> I'm assuming that this will go in via the Samsung tree.
>>
>>
>>> ---
>>>
>>> [ patch will be appended to the implicit include fixup series, see:
>>>   
>>> https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortma...@windriver.com
>>>   for the original series posting.]
>
> Paul, will you handle the patch or should it go through Samsung tree?

My fault for not explicitly stating the obvious...  If I don't keep the
patch locally (or at least a version of it) then we can introduce a
compile bisection fail.  So I will keep all patches locally unless there
is a rebase where I can (also) rebase and drop said pach since it
has become common history of the shared baseline...

Paul.
--

>
> Best regards,
> Krzysztof
> --
> 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/

Re: [PATCH RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 07:41:14PM -0700, Tadeusz Struk wrote:
>
> User can supply only public key and invoke encrypt() or verify() without any 
> problem.
> When the user invokes decrypt() or sign() then it will work only after the 
> setkey was
> given a private key. This is checked in the actual operation.

The current parse_key function requires all three number to be
present, n, e, and d, no?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v8 4/4] sched: Remove task and group entity load when they are dead

[Yuyang Du]

When task exits or group is destroyed, the entity's load should be
removed from its parent cfs_rq's load. Otherwise, it will take time
for the parent cfs_rq to decay the dead entity's load to 0, which
is not desired.

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 08ab789..a8fd7b9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4904,6 +4904,11 @@ static void migrate_task_rq_fair(struct task_struct *p, 
int next_cpu)
/* We have migrated, no longer consider this task hot */
p->se.exec_start = 0;
 }
+
+static void task_dead_fair(struct task_struct *p)
+{
+   remove_entity_load_avg(>se);
+}
 #endif /* CONFIG_SMP */
 
 static unsigned long
@@ -7998,8 +8003,11 @@ void free_fair_sched_group(struct task_group *tg)
for_each_possible_cpu(i) {
if (tg->cfs_rq)
kfree(tg->cfs_rq[i]);
-   if (tg->se)
+   if (tg->se) {
+   if (tg->se[i])
+   remove_entity_load_avg(tg->se[i]);
kfree(tg->se[i]);
+   }
}
 
kfree(tg->cfs_rq);
@@ -8186,6 +8194,7 @@ const struct sched_class fair_sched_class = {
.rq_offline = rq_offline_fair,
 
.task_waking= task_waking_fair,
+   .task_dead  = task_dead_fair,
 #endif
 
.set_curr_task  = set_curr_task_fair,
-- 
1.7.9.5

--
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 v8 2/4] sched: Rewrite runnable load and utilization average tracking

[Yuyang Du]

The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner, and it is still followed by this rewrite. This
rewrite aims to solve the following issues:

1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
   updated at the granularity of an entity at a time, which results in the
   cfs_rq's load average is stale or partially updated: at any time, only
   one entity is up to date, all other entities are effectively lagging
   behind. This is undesirable.

   To illustrate, if we have n runnable entities in the cfs_rq, as time
   elapses, they certainly become outdated:

   t0: cfs_rq { e1_old, e2_old, ..., en_old }

   and when we update:

   t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }

   t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }

   ...

   We solve this by combining all runnable entities' load averages together
   in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
   on the fact that if we regard the update as a function, then:

   w * update(e) = update(w * e) and

   update(e1) + update(e2) = update(e1 + e2), then

   w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)

   therefore, by this rewrite, we have an entirely updated cfs_rq at the
   time we update it:

   t1: update cfs_rq { e1_new, e2_new, ..., en_new }

   t2: update cfs_rq { e1_new, e2_new, ..., en_new }

   ...

2. cfs_rq's load average is different between top rq->cfs_rq and other
   task_group's per CPU cfs_rqs in whether or not blocked_load_average
   contributes to the load.

   The basic idea behind runnable load average (the same for utilization)
   is that the blocked state is taken into account as opposed to only
   accounting for the currently runnable state. Therefore, the average
   should include both the runnable/running and blocked load averages.
   This rewrite does that.

   In addition, we also combine runnable/running and blocked averages
   of all entities into the cfs_rq's average, and update it together at
   once. This is based on the fact that:

   update(runnable) + update(blocked) = update(runnable + blocked)

   This significantly reduces the codes as we don't need to separately
   maintain/update runnable/running load and blocked load.

3. How task_group entities' share is calculated is complex.

   We reduce the complexity in this rewrite to allow a very simple rule:
   the task_group's load_avg is aggregated from its per CPU cfs_rqs's
   load_avgs. Then group entity's weight is simply proportional to its
   own cfs_rq's load_avg / task_group's load_avg. To illustrate,

   if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,

   task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then

   cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share

To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics. As
a result, we have less load tracking overhead, better performance, and
especially better power efficiency due to more balanced load.

Signed-off-by: Yuyang Du 
---
 include/linux/sched.h |   40 ++--
 kernel/sched/core.c   |3 -
 kernel/sched/debug.c  |   35 +--
 kernel/sched/fair.c   |  625 -
 kernel/sched/sched.h  |   28 +--
 5 files changed, 240 insertions(+), 491 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index af0eeba..8b4bc4f 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1183,29 +1183,23 @@ struct load_weight {
u32 inv_weight;
 };
 
+/*
+ * The load_avg/util_avg represents an infinite geometric series:
+ * 1) load_avg describes the amount of time that a sched_entity
+ * is runnable on a rq. It is based on both load_sum and the
+ * weight of the task.
+ * 2) util_avg describes the amount of time that a sched_entity
+ * is running on a CPU. It is based on util_sum and is scaled
+ * in the range [0..SCHED_LOAD_SCALE].
+ * The 64 bit load_sum can:
+ * 1) for cfs_rq, afford 4353082796 (=2^64/47742/88761) entities with
+ * the highest weight (=88761) always runnable, we should not overflow
+ * 2) for entity, support any load.weight always runnable
+ */
 struct sched_avg {
-   u64 last_runnable_update;
-   s64 decay_count;
-   /*
-* utilization_avg_contrib describes the amount of time that a
-* sched_entity is running on a CPU. It is based on running_avg_sum
-* and is scaled in the range [0..SCHED_LOAD_SCALE].
-* load_avg_contrib described the amount of time that a sched_entity
-* is runnable on a rq. It is based on both runnable_avg_sum and the
-* 

Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

[Javier Martinez Canillas]

Hello Krzysztof,

On 06/16/2015 01:57 AM, Krzysztof Kozlowski wrote:
> On 16.06.2015 00:23, Javier Martinez Canillas wrote: (...)
 To do a more intrusive change, I should better understand the
 interactions between the Exynos pinctrl / GPIO, interrupt
 combiner and the GIC and in the meantime S2R will continue to
 be broken on these platforms unless someone more familiar with
 all this could point me in the right direction.
 
>>> 
>>> As I said I am fine with this patch for now and I don't want to
>>> block it.
>>> 
>> 
>> Thanks a lot, Krzysztof who is one of the Exynos maintainers has
>> also agreed with the patch so hopefully this can land sooner rather
>> than later.
> 
> I assume this will go through irqchip tree, right?
> 

That is my assumption as well. I meant the fact that you as an Exynos
maintainer thinks $subject is a sensible solution to the issue, would
give confidence to the irqchip maintainers to pick this patch soon.

> Best regards, Krzysztof
> 

Best regards,
Javier
--
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 v8 1/4] sched: Remove rq's runnable avg

[Yuyang Du]

The current rq->avg is not used at all since its merge into kernel,
and the code is in the scheduler's hot path, so remove it.

Signed-off-by: Yuyang Du 
---
 kernel/sched/debug.c |7 +--
 kernel/sched/fair.c  |   25 -
 kernel/sched/sched.h |2 --
 3 files changed, 5 insertions(+), 29 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index f94724e..ca39cb7 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -68,13 +68,8 @@ static void print_cfs_group_stats(struct seq_file *m, int 
cpu, struct task_group
 #define PN(F) \
SEQ_printf(m, "  .%-30s: %lld.%06ld\n", #F, SPLIT_NS((long long)F))
 
-   if (!se) {
-   struct sched_avg *avg = _rq(cpu)->avg;
-   P(avg->runnable_avg_sum);
-   P(avg->avg_period);
+   if (!se)
return;
-   }
-
 
PN(se->exec_start);
PN(se->vruntime);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d597aea..56c1b94 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2713,19 +2713,12 @@ static inline void __update_group_entity_contrib(struct 
sched_entity *se)
}
 }
 
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
-{
-   __update_entity_runnable_avg(rq_clock_task(rq), cpu_of(rq), >avg,
-   runnable, runnable);
-   __update_tg_runnable_avg(>avg, >cfs);
-}
 #else /* CONFIG_FAIR_GROUP_SCHED */
 static inline void __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
 int force_update) {}
 static inline void __update_tg_runnable_avg(struct sched_avg *sa,
  struct cfs_rq *cfs_rq) {}
 static inline void __update_group_entity_contrib(struct sched_entity *se) {}
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable) {}
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
 static inline void __update_task_entity_contrib(struct sched_entity *se)
@@ -2929,7 +2922,6 @@ static inline void dequeue_entity_load_avg(struct cfs_rq 
*cfs_rq,
  */
 void idle_enter_fair(struct rq *this_rq)
 {
-   update_rq_runnable_avg(this_rq, 1);
 }
 
 /*
@@ -2939,7 +2931,6 @@ void idle_enter_fair(struct rq *this_rq)
  */
 void idle_exit_fair(struct rq *this_rq)
 {
-   update_rq_runnable_avg(this_rq, 0);
 }
 
 static int idle_balance(struct rq *this_rq);
@@ -2948,7 +2939,6 @@ static int idle_balance(struct rq *this_rq);
 
 static inline void update_entity_load_avg(struct sched_entity *se,
  int update_cfs_rq) {}
-static inline void update_rq_runnable_avg(struct rq *rq, int runnable) {}
 static inline void enqueue_entity_load_avg(struct cfs_rq *cfs_rq,
   struct sched_entity *se,
   int wakeup) {}
@@ -4247,10 +4237,9 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, 
int flags)
update_entity_load_avg(se, 1);
}
 
-   if (!se) {
-   update_rq_runnable_avg(rq, rq->nr_running);
+   if (!se)
add_nr_running(rq, 1);
-   }
+
hrtick_update(rq);
 }
 
@@ -4308,10 +4297,9 @@ static void dequeue_task_fair(struct rq *rq, struct 
task_struct *p, int flags)
update_entity_load_avg(se, 1);
}
 
-   if (!se) {
+   if (!se)
sub_nr_running(rq, 1);
-   update_rq_runnable_avg(rq, 1);
-   }
+
hrtick_update(rq);
 }
 
@@ -6016,9 +6004,6 @@ static void __update_blocked_averages_cpu(struct 
task_group *tg, int cpu)
 */
if (!se->avg.runnable_avg_sum && !cfs_rq->nr_running)
list_del_leaf_cfs_rq(cfs_rq);
-   } else {
-   struct rq *rq = rq_of(cfs_rq);
-   update_rq_runnable_avg(rq, rq->nr_running);
}
 }
 
@@ -8002,8 +7987,6 @@ static void task_tick_fair(struct rq *rq, struct 
task_struct *curr, int queued)
 
if (numabalancing_enabled)
task_tick_numa(rq, curr);
-
-   update_rq_runnable_avg(rq, 1);
 }
 
 /*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index f10a445..d465a5c 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -595,8 +595,6 @@ struct rq {
 #ifdef CONFIG_FAIR_GROUP_SCHED
/* list of leaf cfs_rq on this cpu: */
struct list_head leaf_cfs_rq_list;
-
-   struct sched_avg avg;
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
/*
-- 
1.7.9.5

--
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 v8 3/4] sched: Init cfs_rq's sched_entity load average

[Yuyang Du]

The runnable load and utilization averages of cfs_rq's sched_entity
were not initiated. Like done to a task, give new cfs_rq' sched_entity
start values to heavy its load in infant time.

Signed-off-by: Yuyang Du 
---
 kernel/sched/core.c  |2 +-
 kernel/sched/fair.c  |   11 ++-
 kernel/sched/sched.h |2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 724de5b..c8dad9b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2112,7 +2112,7 @@ void wake_up_new_task(struct task_struct *p)
 #endif
 
/* Initialize new task's runnable average */
-   init_task_runnable_average(p);
+   init_entity_runnable_average(>se);
rq = __task_rq_lock(p);
activate_task(rq, p, 0);
p->on_rq = TASK_ON_RQ_QUEUED;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f336f6e..08ab789 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -672,10 +672,10 @@ static unsigned long task_h_load(struct task_struct *p);
 #define LOAD_AVG_MAX 47742 /* maximum possible load avg */
 #define LOAD_AVG_MAX_N 345 /* number of full periods to produce LOAD_MAX_AVG */
 
-/* Give new task start runnable values to heavy its load in infant time */
-void init_task_runnable_average(struct task_struct *p)
+/* Give new sched_entity start runnable values to heavy its load in infant 
time */
+void init_entity_runnable_average(struct sched_entity *se)
 {
-   struct sched_avg *sa = >se.avg;
+   struct sched_avg *sa = >avg;
 
sa->last_update_time = 0;
/*
@@ -684,14 +684,14 @@ void init_task_runnable_average(struct task_struct *p)
 * will definitely be update (after enqueue).
 */
sa->period_contrib = 1023;
-   sa->load_avg = scale_load_down(p->se.load.weight);
+   sa->load_avg = scale_load_down(se->load.weight);
sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
sa->util_avg = scale_load_down(SCHED_LOAD_SCALE);
sa->util_sum = sa->util_avg * LOAD_AVG_MAX;
/* when this task enqueue'ed, it will contribute to its cfs_rq's 
load_avg */
 }
 #else
-void init_task_runnable_average(struct task_struct *p)
+void init_entity_runnable_average(struct sched_entity *se)
 {
 }
 #endif
@@ -8036,6 +8036,7 @@ int alloc_fair_sched_group(struct task_group *tg, struct 
task_group *parent)
 
init_cfs_rq(cfs_rq);
init_tg_cfs_entry(tg, cfs_rq, se, i, parent->se[i]);
+   init_entity_runnable_average(se);
}
 
return 1;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 3dfec8d..f2b17ea 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1293,7 +1293,7 @@ extern void init_dl_task_timer(struct sched_dl_entity 
*dl_se);
 
 unsigned long to_ratio(u64 period, u64 runtime);
 
-extern void init_task_runnable_average(struct task_struct *p);
+extern void init_entity_runnable_average(struct sched_entity *se);
 
 static inline void add_nr_running(struct rq *rq, unsigned count)
 {
-- 
1.7.9.5

--
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 4/7] clocksource: bcm2835: Migrate to new 'set-state' interface

[Viresh Kumar]

On 15-06-15, 20:57, Stephen Warren wrote:
> On 06/12/2015 02:00 AM, Viresh Kumar wrote:
> > Migrate bcm2835 driver to the new 'set-state' interface provided by
> > the clockevents core, the earlier 'set-mode' interface is marked
> > obsolete now.
> > 
> > This also enables us to implement callbacks for new states of clockevent
> > devices, for example: ONESHOT_STOPPED.
> > 
> > We weren't doing anything in the ->set_mode() callback. So, this patch
> > doesn't provide any set-state callbacks.
> 
> This generates a panic at boot (on top of 4.1.0-rc8+, which certainly at
> least booted fine):
> 
> > [0.008586] clocksource timer: mask: 0x max_cycles: 0x, 
> > max_idle_ns: 1911260446275 ns
> > [0.018080] [ cut here ]
> > [0.022843] kernel BUG at kernel/time/clockevents.c:480!
> > [0.028299] Internal error: Oops - BUG: 0 [#1] ARM
> > [0.033237] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.0-rc8+ #46
> > [0.039567] Hardware name: BCM2835
> > [0.043092] task: c06fb648 ti: c06f6000 task.ti: c06f6000
> > [0.048668] PC is at clockevents_register_device+0x15c/0x174

This failed the sanity checks of clockevents core. Did you apply the
first patch as well? Yes, its very much required.

Also, there were dependencies on the latest tip, prepared for 4.2
merge window and would have been better if you tested on top of that.

But those dependencies are for some helpers which aren't used in this
patch. So, it might work over rc8 + the first patch from this series..

In case it doesn't, please test it over tip/master once.

-- 
viresh
--
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/

[Resend PATCH v8 0/4] sched: Rewrite runnable load and utilization average tracking

[Yuyang Du]

Hi Peter and Ingo,

Changes are made for the 8th version:

1) Rebase to the latest tip tree
2) scale_load_down the weight when doing the averages
3) change util_sum to u32

Thanks a lot for Ben's comments, which lead to this version.
Thanks to Vincent for review.

Regards,
Yuyang

v7 changes:

The 7th version mostly is to accommodate the utilization load average recently
merged into kernel. The general idea is as well to update the cfs_rq as a whole
as opposed to only updating an entity at a time and update the cfs_rq with the
only updated entity.

1) Rename utilization_load_avg to util_avg to be concise and meaningful

2) To track the cfs_rq util_avg, simply use "cfs_rq->curr != NULL" as the
predicate. This should be equivalent to but simpler than aggregating each
individual child sched_entity's util_avg when "cfs_rq->curr == se". Because
if cfs_rq->curr != NULL, the cfs_rq->curr has to be some se.

3) Remove se's util_avg from its cfs_rq's when migrating it, this was already
proposed by Morten and patches sent

3) The group entity's load average is initiated when the entity is created

4) Small nits: the entity's util_avg is removed from switched_from_fair()
and task_move_group_fair().

Thanks a lot for Vincent and Morten's help for the 7th version.

Thanks,
Yuyang

v6 changes:

Many thanks to PeterZ for his review, to Dietmar, and to Fengguang for 0Day and 
LKP.

Rebased on v3.18-rc2.

- Unify decay_load 32 and 64 bits by mul_u64_u32_shr
- Add force option in update_tg_load_avg
- Read real-time cfs's load_avg for calc_tg_weight
- Have tg_load_avg_contrib ifdef CONFIG_FAIR_GROUP_SCHED
- Bug fix

v5 changes:

Thank Peter intensively for reviewing this patchset in detail and all his 
comments.
And Mike for general and cgroup pipe-test. Morten, Ben, and Vincent in the 
discussion.

- Remove dead task and task group load_avg
- Do not update trivial delta to task_group load_avg (threshold 1/64 
old_contrib)
- mul_u64_u32_shr() is used in decay_load, so on 64bit, load_sum can afford
  about 4353082796 (=2^64/47742/88761) entities with the highest weight (=88761)
  always runnable, greater than previous theoretical maximum 132845
- Various code efficiency and style changes

We carried out some performance tests (thanks to Fengguang and his LKP). The 
results
are shown as follows. The patchset (including threepatches) is on top of 
mainline
v3.16-rc5. We may report more perf numbers later.

Overall, this rewrite has better performance, and reduced net overhead in load
average tracking, flat efficiency in multi-layer cgroup pipe-test.

v4 changes:

Thanks to Morten, Ben, and Fengguang for v4 revision.

- Insert memory barrier before writing cfs_rq->load_last_update_copy.
- Fix typos.

v3 changes:

Many thanks to Ben for v3 revision.

Regarding the overflow issue, we now have for both entity and cfs_rq:

struct sched_avg {
.
u64 load_sum;
unsigned long load_avg;
.
};

Given the weight for both entity and cfs_rq is:

struct load_weight {
unsigned long weight;
.
};

So, load_sum's max is 47742 * load.weight (which is unsigned long), then on 
32bit,
it is absolutly safe. On 64bit, with unsigned long being 64bit, but we can 
afford
about 4353082796 (=2^64/47742/88761) entities with the highest weight (=88761)
always runnable, even considering we may multiply 1<<15 in decay_load64, we can
still support 132845 (=4353082796/2^15) always runnable, which should be 
acceptible.

load_avg = load_sum / 47742 = load.weight (which is unsigned long), so it 
should be
perfectly safe for both entity (even with arbitrary user group share) and 
cfs_rq on
both 32bit and 64bit. Originally, we saved this division, but have to get it 
back
because of the overflow issue on 32bit (actually load average itself is safe 
from
overflow, but the rest of the code referencing it always uses long, such as 
cpu_load,
etc., which prevents it from saving).

- Fix overflow issue both for entity and cfs_rq on both 32bit and 64bit.
- Track all entities (both task and group entity) due to group entity's clock 
issue.
  This actually improves code simplicity.
- Make a copy of cfs_rq sched_avg's last_update_time, to read an intact 64bit
  variable on 32bit machine when in data race (hope I did it right).
- Minor fixes and code improvement.

v2 changes:

Thanks to PeterZ and Ben for their help in fixing the issues and improving
the quality, and Fengguang and his 0Day in finding compile errors in different
configurations for version 2.

- Batch update the tg->load_avg, making sure it is up-to-date before 
update_cfs_shares
- Remove migrating task from the old CPU/cfs_rq, and do so with atomic 
operations


Yuyang Du (4):
  sched: Remove rq's runnable avg
  sched: Rewrite runnable load and utilization average tracking
  sched: Init cfs_rq's sched_entity load average
  sched: Remove task and group entity load when they are dead

 include/linux/sched.h |   40 ++-
 kernel/sched/core.c   |5 +-
 kernel/sched/debug.c  |   

Re: [PATCH v2 3/3] ARM: dts: bcm2835-rpi: Add "brcm,raspberrypi-pm-wdt" to wdt compatible

[Stephen Warren]

On 06/13/2015 05:39 AM, Noralf Trønnes wrote:
> The Raspberry Pi uses a new value for halt in the PM_RSTS watchdog
> register. Expand the compatible string to cover this.

FWIW, the series,
Tested-by: Stephen Warren 

... but that doesn't imply my ack for the 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: [RFC v2 23/24] m68k/mac: Fix PRAM accessors

[Finn Thain]

On Mon, 15 Jun 2015, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Sun, Jun 14, 2015 at 9:46 AM, Finn Thain  
> wrote:
> > --- linux.orig/arch/m68k/mac/misc.c 2015-06-14 17:46:02.0 +1000
> > +++ linux/arch/m68k/mac/misc.c  2015-06-14 17:46:03.0 +1000
> > @@ -284,11 +287,31 @@ static void via_pram_command(int command
> >
> >  static unsigned char via_pram_read_byte(int offset)
> >  {
> > -   return 0;
> > +   unsigned char temp;
> > +   int addr = ((offset & 0xE0) << 3) | ((offset & 0x1F) << 2);
> 
> Can you please add #defines for the magic values?

This is just marshalling the offset argument. I don't know how to rewrite 
that code more clearly. I'm open to suggestions. I don't know of any 
documentation that gives names or meanings to the different bit ranges. I 
infered the format from the MESS source code, 
https://github.com/mamedev/mame/blob/master/src/mess/machine/macrtc.c

What I found in the MESS source code looks like the result of reverse 
engineering. Hence the RTC code in this patch also looks like a reverse 
engineered driver.

> 
> > +
> > +   /* Use RTC command 0x38 for XPRAM access, as per MESS source code */
> > +   via_pram_command(addr | 0x3800 | 0x8001, );
> 
> It seems 0x38 is already documented in  (see below), or not 
> (it's shifted left by 8 bits?)?

No, this is a RTC command not a PMU command. This RTC device is an Apple 
custom IC that is publicly undocumented. OTOH, the PMU device is well 
documented, since Apple publicly released PMU driver source code in 
MkLinux and later in XNU. That's why I've been able to provide #defines 
for the PMU commands but not the RTC commands.

> 
> > +
> > +   return temp;
> >  }
> >
> >  static void via_pram_write_byte(unsigned char data, int offset)
> >  {
> > +   unsigned char temp;
> > +   int addr = ((offset & 0xE0) << 3) | ((offset & 0x1F) << 2);
> > +
> > +   /* Clear the write protect bit */
> > +   temp = 0x55;
> > +   via_pram_command(0x34 | 0x01, );
> > +
> > +   /* Write the byte to XPRAM */
> > +   temp = data;
> > +   via_pram_command(0x3800 | 0x0001 | addr, );
> > +
> > +   /* Set the write protect bit */
> > +   temp = 0xD5;
> > +   via_pram_command(0x34 | 0x01, );
> 
> More magic values...

When I have reliable documentation I always define macros. So I agree that 
"command" bytes like 0x34 and 0x3800 should have names but what are the 
correct names? Are we constructing an opcode containing RTC register file 
addresses or are we issuing read/write accesses to chip registers?

In my experience with undocumented 68k Mac hardware and its Linux port, 
codified guesswork is worse than no documentation at all. The only useful 
RTC documentation I've ever come across is this: 
http://mac.linux-m68k.org/devel/plushw.php

It tells us that the two least significant bits bits must equal 0b01. What 
would you call that macro? It also tells us that the most significant bit, 
0x80, means "read access" but it only mentions early RTC chips and so it 
does not cover two byte opcodes. Should I have used 0x8080 here?

Whatever your opinion of reverse engineered drivers, the changes in this 
patch are consistent with the rest of the file. E.g. via_read_time() and 
via_write_time(). If/when we have the chip data needed to correctly define 
macros for 0x01, 0x0001, 0x80, 0x8000 or 0x8080, I think they should be 
applied across the entire file, and in a different patch. Inconsistent use 
of such macros would be undesirable IMHO.

> 
> >  }
> >
> >  /*
> > Index: linux/include/uapi/linux/pmu.h
> > ===
> > --- linux.orig/include/uapi/linux/pmu.h 2015-06-14 17:45:34.0 +1000
> > +++ linux/include/uapi/linux/pmu.h  2015-06-14 17:46:03.0 +1000
> > @@ -18,7 +18,9 @@
> >  #define PMU_POWER_CTRL 0x11/* control power of some devices */
> >  #define PMU_ADB_CMD0x20/* send ADB packet */
> >  #define PMU_ADB_POLL_OFF   0x21/* disable ADB auto-poll */
> > +#define PMU_WRITE_XPRAM0x32/* write eXtended Parameter 
> > RAM */
> >  #define PMU_WRITE_NVRAM0x33/* write non-volatile RAM */
> > +#define PMU_READ_XPRAM 0x3a/* read eXtended Parameter RAM */
> >  #define PMU_READ_NVRAM 0x3b/* read non-volatile RAM */
> >  #define PMU_SET_RTC0x30/* set real-time clock */
> >  #define PMU_READ_RTC   0x38/* read real-time clock */
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 

-- 
--
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 2/3] watchdog: bcm2835: Add poweroff code for the Raspberry Pi

[Stephen Warren]

On 06/13/2015 05:39 AM, Noralf Trønnes wrote:
> This adds a new poweroff function to the watchdog driver for the
> Raspberry Pi. Currently poweroff/halt results in a reboot.
> 
> The Raspberry Pi firmware uses the RSTS register to know which
> partiton to boot from. The partiton value is spread into bits
> 0, 2, 4, 6, 8, 10. Partiton 63 is a special partition used by
> the firmware to indicate halt.
> 
> The firmware made this change in 19 Aug 2013 and was matched
> by the downstream commit:
> Changes for new NOOBS multi partition booting from gsh

I don't understand why we need a new compatible value here; why not
simply modify the existing bcm2835_power_off() function. That is written
to do something that's interpreted by the RPi firmware, not something
that the bcm2835 HW does.

Admittedly the current name is a bit misleading, but fixing that should
be a separate change to fixing the implementation to do what the current
firmware expects.
--
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 4/7] clocksource: bcm2835: Migrate to new 'set-state' interface

[Stephen Warren]

On 06/12/2015 02:00 AM, Viresh Kumar wrote:
> Migrate bcm2835 driver to the new 'set-state' interface provided by
> the clockevents core, the earlier 'set-mode' interface is marked
> obsolete now.
> 
> This also enables us to implement callbacks for new states of clockevent
> devices, for example: ONESHOT_STOPPED.
> 
> We weren't doing anything in the ->set_mode() callback. So, this patch
> doesn't provide any set-state callbacks.

This generates a panic at boot (on top of 4.1.0-rc8+, which certainly at
least booted fine):

> [0.008586] clocksource timer: mask: 0x max_cycles: 0x, 
> max_idle_ns: 1911260446275 ns
> [0.018080] [ cut here ]
> [0.022843] kernel BUG at kernel/time/clockevents.c:480!
> [0.028299] Internal error: Oops - BUG: 0 [#1] ARM
> [0.033237] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.0-rc8+ #46
> [0.039567] Hardware name: BCM2835
> [0.043092] task: c06fb648 ti: c06f6000 task.ti: c06f6000
> [0.048668] PC is at clockevents_register_device+0x15c/0x174
> [0.054481] LR is at clockevents_config_and_register+0x2c/0x30
> [0.060467] pc : []lr : []psr: 61d3
> [0.060467] sp : c06f7f18  ip : c0066498  fp : c06f7f34
> [0.072243] r10: cdffc660  r9 : 410fb767  r8 : c06db128
> [0.077611] r7 : 001b  r6 : f0003018  r5 : cde38ed4  r4 : cd422020
> [0.084294] r3 : 0002  r2 :   r1 : 03e7  r0 : cd422020
> [0.090979] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
> kernel
> [0.098627] Control: 00c5387d  Table: 4008  DAC: 0015
> [0.104521] Process swapper (pid: 0, stack limit = 0xc06f6188)
> [0.110502] Stack: (0xc06f7f18 to 0xc06f8000)
> [0.114993] 7f00:   
> 03e7 cd422020
> [0.123354] 7f20: cde38ed4 f0003018 c06f7f4c c06f7f38 c00666b4 c0066490 
>  cd422000
> [0.131715] 7f40: c06f7f7c c06f7f50 c06c3358 c0066694 0020 c03429ac 
> c06f7f7c 000f4240
> [0.140076] 7f60: cde38ed4 0001 c06f7f84  c06f7fa4 c06f7f80 
> c06c3124 c06c321c
> [0.148436] 7f80: 0001 c06f4ea0   0001 c075aea0 
> c06f7fb4 c06f7fa8
> [0.156798] 7fa0: c06988e4 c06c30dc c06f7ff4 c06f7fb8 c0695b90 c06988c0 
>  
> [0.165159] 7fc0: c06956e4   c06db128 c075b014 c06f8024 
> c06db124 c06fc910
> [0.173518] 7fe0: 4008 006d9fcc  c06f7ff8 8074 c069597c 
>  
> [0.181910] [] (clockevents_register_device) from [] 
> (clockevents_config_and_register+0x2c/0x30)
> [0.192661] [] (clockevents_config_and_register) from 
> [] (bcm2835_timer_init+0x148/0x19c)
> [0.202785] [] (bcm2835_timer_init) from [] 
> (clocksource_of_init+0x54/0x98)
> [0.211693] [] (clocksource_of_init) from [] 
> (time_init+0x30/0x38)
> [0.219798] [] (time_init) from [] 
> (start_kernel+0x220/0x3a4)
> [0.227459] [] (start_kernel) from [<8074>] (0x8074)
> [0.233803] Code: e5943078 e353 1ad5 ead2 (e7f001f2) 
> [0.240103] ---[ end trace cb88537fdc8fa200 ]---
> [0.244866] Kernel panic - not syncing: Attempted to kill the idle task!
> [0.251730] ---[ end Kernel panic - not syncing: Attempted to kill the 
> idle task!

--
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/1 net-next] net: rds: use for_each_sg() for scatterlist parsing

[David Miller]

From: Fabian Frederick 
Date: Mon, 15 Jun 2015 19:13:05 +0200

>  {
>   unsigned int i;
> + struct scatterlist *sg;

Please order local variables from longest to shortest line (reverse
christmas tree).

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: [PATCH RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 07:50 PM, Herbert Xu wrote:
> If you want to keep the helper generic what you can do is have
> it take struct rsa_key instead of struct crypto_ablkcipher.

Ok I'll do it that way.

> 
> It definitely should just be an optional helper as opposed to
> a required part of crypto_akcipher since you could have a piece
> of hardware that takes the encoded key directly in which case
> you wouldn't need the helper at all.

Oh yes, it is definitely optional.
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/

[PATCH v2] *** TEST ***

[xiaofeng.yan]

TEST


-- 
1.9.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/

[RFC PATCH] perf/kvm: Guest Symbol Resolution for powerpc

[Hemant Kumar]

"perf kvm {record|report}" is used to record and report the performance
profile of any workload on a guest. From the host, we can collect
guest kernel statistics which is useful in finding out any contentions
in guest kernel symbols for a certain workload.

This feature is not available on powerpc because "perf" relies on the
"cycles" event (a PMU event) to profile the guest. However, for powerpc,
this can't be used from the host because the PMUs are controlled by the
guest rather than the host.

Due to this problem, we need a different approach to profile the
workload in the guest. There exists a tracepoint "kvm_hv:kvm_guest_exit"
in powerpc which is hit whenever any of the threads exit the guest
context. The guest instruction pointer dumped along with this
tracepoint data in the field "pc", can be used as guest instruction
pointer while postprocessing the trace data to map this IP to symbol
from guest.kallsyms.

However, to have some kind of periodicity, we can't use all the kvm
exits, rather exits which are bound to happen in certain intervals.
HV_DECREMENTER Interrupt forces the threads to exit after an interval
of 10 ms.

This patch makes use of the "kvm_guest_exit" tracepoint and checks the
exit reason for any kvm exit. If it is HV_DECREMENTER, then the
instruction pointer dumped along with this tracepoint is retrieved and
mapped with the guest kallsyms.

This patch is a prototype asking for suggestions/comments as to whether
the approach is right or is there any way better than this (like using
a different event to profile for, etc) to profile the guest from the
host.

Thank You.

Signed-off-by: Hemant Kumar 
---
 tools/perf/arch/powerpc/Makefile|  1 +
 tools/perf/arch/powerpc/util/parse-tp.c | 55 +
 tools/perf/builtin-report.c |  9 ++
 tools/perf/util/event.c |  7 -
 tools/perf/util/evsel.c |  7 +
 tools/perf/util/evsel.h |  4 +++
 tools/perf/util/session.c   |  7 +++--
 7 files changed, 86 insertions(+), 4 deletions(-)
 create mode 100644 tools/perf/arch/powerpc/util/parse-tp.c

diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 6f7782b..992a0d5 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -4,3 +4,4 @@ LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
 LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/skip-callchain-idx.o
 endif
 LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/parse-tp.o
diff --git a/tools/perf/arch/powerpc/util/parse-tp.c 
b/tools/perf/arch/powerpc/util/parse-tp.c
new file mode 100644
index 000..4c6e49c
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/parse-tp.c
@@ -0,0 +1,55 @@
+#include "../../util/evsel.h"
+#include "../../util/trace-event.h"
+#include "../../util/session.h"
+
+#define KVMPPC_EXIT "kvm_hv:kvm_guest_exit"
+#define HV_DECREMENTER 2432
+#define HV_BIT 3
+#define PR_BIT 49
+#define PPC_MAX 63
+
+/*
+ * Get the instruction pointer from the tracepoint data
+ */
+u64 arch__get_ip(struct perf_evsel *evsel, struct perf_sample *data)
+{
+   u64 tp_ip = data->ip;
+   int trap;
+
+   if (!strcmp(KVMPPC_EXIT, evsel->name)) {
+   trap = raw_field_value(evsel->tp_format, "trap", 
data->raw_data);
+
+   if (trap == HV_DECREMENTER)
+   tp_ip = raw_field_value(evsel->tp_format, "pc",
+   data->raw_data);
+   }
+   return tp_ip;
+}
+
+/*
+ * Get the HV and PR bits and accordingly, determine the cpumode
+ */
+u8 arch__get_cpumode(union perf_event *event, struct perf_evsel *evsel,
+struct perf_sample *data)
+{
+   unsigned long hv, pr, msr;
+   u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
+
+   if (strcmp(KVMPPC_EXIT, evsel->name))
+   goto ret;
+
+   if (data->raw_data)
+   msr = raw_field_value(evsel->tp_format, "msr", data->raw_data);
+   else
+   goto ret;
+
+   hv = msr & ((long unsigned)1 << (PPC_MAX - HV_BIT));
+   pr = msr & ((long unsigned)1 << (PPC_MAX - PR_BIT));
+
+   if (!hv && pr)
+   cpumode = PERF_RECORD_MISC_GUEST_USER;
+   else
+   cpumode = PERF_RECORD_MISC_GUEST_KERNEL;
+ret:
+   return cpumode;
+}
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 072ae8a..e3fe5d0 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -141,6 +141,13 @@ out:
return err;
 }
 
+u8 __weak arch__get_cpumode(union perf_event *event,
+   __maybe_unused struct perf_evsel *evsel,
+   __maybe_unused struct perf_sample *sample)
+{
+   return event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
+}
+
 static int process_sample_event(struct perf_tool *tool,
union perf_event 

Re: [PATCH RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 07:46:28PM -0700, Tadeusz Struk wrote:
>
> Ok I wanted to handle everything in the parse_key helper without any help 
> from the implementation.
> I can change the helper to return the key and implementation will store it in 
> the ctx. Is this
> what you are suggesting?

If you want to keep the helper generic what you can do is have
it take struct rsa_key instead of struct crypto_ablkcipher.

It definitely should just be an optional helper as opposed to
a required part of crypto_akcipher since you could have a piece
of hardware that takes the encoded key directly in which case
you wouldn't need the helper at all.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 07:29 PM, Herbert Xu wrote:
>> I thought that the ctx needs to be available for implementations to store 
>> private data.
>> > This way we can allocate and store any type of key in the 
>> > _parse_key() helper and still have the cxt
>> > available for implementations to use for their stuff (e.g. HW context).
> No for symmetric key algorithms we always store the key in the
> context and never in the tfm proper.
> 
> Think about it, the generic tfm doesn't have any idea on what
> the key contains so how can it store it? Only the implementation
> knows the key format and can store it in a useful way.

Ok I wanted to handle everything in the parse_key helper without any help from 
the implementation.
I can change the helper to return the key and implementation will store it in 
the ctx. Is this
what you are suggesting?
--
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 RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 07:27 PM, Herbert Xu wrote:
>> The two functions will be almost identical. We can do it this way if we want 
>> to check
>> > if all the required elements of the key are provided. Currently I'm 
>> > checking this in the
>> > actual operation.
> Right now your RSA setkey function only works if you supply both
> the public key and the private key.  If the user supplies only one
> key how are you going to tell whether it's public or private?

User can supply only public key and invoke encrypt() or verify() without any 
problem.
When the user invokes decrypt() or sign() then it will work only after the 
setkey was
given a private key. This is checked in the actual operation.
So the user is responsible for providing an appropriate key for given operation.
We can split it if you think this is the right thing to do, but currently it 
works fine.

 
--
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 v8 0/4] sched: Rewrite runnable load and utilization average tracking

[Yuyang Du]

Hi Boqun,

Thanks for the tests.

Indeed I can't find the 8th versio myself in the archive. That is weird.
Vincent sure received the patches, but maybe not the list, then that is
interesting...

Anyway, I will rebase the patches up-to-date, and resend it to the list
shortly.

Regarding test results, "less than 50% sometimes" meaning imbalanced?
What about versus the stock kernel?

Regards,
Yuyang

On Mon, Jun 15, 2015 at 06:38:56PM +0800, Boqun Feng wrote:
> Hi Yuyang,
> 
> We have tested your V7 patchset as follow:
> 
> On Intel(R) Xeon(R) CPU X5690 (12 cores), run 12 stress and 6 dbench.
> Results show that usages of some CPUs are less than 50% sometimes.
> 
> We would like to test your V8 patchset, but I can neither find it in a
> lkml archive, nor in my lkml subscription. Would you please send me your
> V8 patchset, if convenient? Or a public git tree works too!
> 
> Regards,
> Boqun
> 
> On Tue, Jun 09, 2015 at 09:21:43AM +0800, Yuyang Du wrote:
> > Ping ...
> > 
> > Plus some data tested by LKP:
> > 
> > To name a few host configurations:
> > 
> > host: brickland3
> > model: Brickland Ivy Bridge-EX
> > nr_cpu: 120
> > memory: 512G
> > 
> > host: lkp-a03
> > model: Atom
> > memory: 8G
> > 
> > host: grantley
> > model: Grantley Haswell-EP
> > memory: 32G
> > 
> > host: ivb43
> > model: Ivytown Ivy Bridge-EP
> > nr_cpu: 48
> > memory: 64G
> > 
> [snip]


--
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 v3 2/2] dma: Add Xilinx zynqmp dma engine driver support

[Punnaiah Choudary Kalluri]

Added the basic driver for zynqmp dma engine used in Zynq
UltraScale+ MPSoC. The initial release of this driver supports
only memory to memory transfers.

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v3:
- Modified the zynqmp_dma_chan_is_idle function return type to
  bool
Changes in v2:
- Corrected the function header documentation
- Framework expects bus-width value in bytes. so, fixed it.
- Removed magic numbers for bus-width
---
 drivers/dma/Kconfig |6 +
 drivers/dma/xilinx/Makefile |1 +
 drivers/dma/xilinx/zynqmp_dma.c | 1216 +++
 3 files changed, 1223 insertions(+), 0 deletions(-)
 create mode 100644 drivers/dma/xilinx/zynqmp_dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index bda2cb0..d5b57fc 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -410,6 +410,12 @@ config XILINX_VDMA
  channels, Memory Mapped to Stream (MM2S) and Stream to
  Memory Mapped (S2MM) for the data transfers.
 
+config XILINX_ZYNQMP_DMA
+   tristate "Xilinx ZynqMP DMA Engine"
+   select DMA_ENGINE
+   help
+ Enable support for Xilinx ZynqMP DMA engine in Zynq UltraScale+ MPSoC.
+
 config DMA_SUN6I
tristate "Allwinner A31 SoCs DMA support"
depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 3c4e9f2..95469dc 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
new file mode 100644
index 000..cfb169a
--- /dev/null
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -0,0 +1,1216 @@
+/*
+ * DMA driver for Xilinx ZynqMP DMA Engine
+ *
+ * Copyright (C) 2015 Xilinx, Inc. All rights reserved.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../dmaengine.h"
+
+/* Register Offsets */
+#define ISR0x100
+#define IMR0x104
+#define IER0x108
+#define IDS0x10C
+#define CTRL0  0x110
+#define CTRL1  0x114
+#define STATUS 0x11C
+#define DATA_ATTR  0x120
+#define DSCR_ATTR  0x124
+#define SRC_DSCR_WRD0  0x128
+#define SRC_DSCR_WRD1  0x12C
+#define SRC_DSCR_WRD2  0x130
+#define SRC_DSCR_WRD3  0x134
+#define DST_DSCR_WRD0  0x138
+#define DST_DSCR_WRD1  0x13C
+#define DST_DSCR_WRD2  0x140
+#define DST_DSCR_WRD3  0x144
+#define SRC_START_LSB  0x158
+#define SRC_START_MSB  0x15C
+#define DST_START_LSB  0x160
+#define DST_START_MSB  0x164
+#define TOTAL_BYTE 0x188
+#define RATE_CTRL  0x18C
+#define IRQ_SRC_ACCT   0x190
+#define IRQ_DST_ACCT   0x194
+#define CTRL2  0x200
+
+/* Interrupt registers bit field definitions */
+#define DMA_DONE   BIT(10)
+#define AXI_WR_DATABIT(9)
+#define AXI_RD_DATABIT(8)
+#define AXI_RD_DST_DSCRBIT(7)
+#define AXI_RD_SRC_DSCRBIT(6)
+#define IRQ_DST_ACCT_ERR   BIT(5)
+#define IRQ_SRC_ACCT_ERR   BIT(4)
+#define BYTE_CNT_OVRFL BIT(3)
+#define DST_DSCR_DONE  BIT(2)
+#define INV_APBBIT(0)
+
+/* Control 0 register bit field definitions */
+#define OVR_FETCH  BIT(7)
+#define POINT_TYPE_SG  BIT(6)
+#define RATE_CTRL_EN   BIT(3)
+
+/* Control 1 register bit field definitions */
+#define SRC_ISSUE  GENMASK(4, 0)
+
+/* Channel status register bit field definitions */
+#define STATUS_BUSY0x2
+
+/* Data Attribute register bit field definitions */
+#define ARBURSTGENMASK(27, 26)
+#define ARCACHEGENMASK(25, 22)
+#define ARCACHE_OFST   22
+#define ARQOS  GENMASK(21, 18)
+#define ARQOS_OFST 18
+#define ARLEN  GENMASK(17, 14)
+#define ARLEN_OFST 14
+#define AWBURST

[PATCH v3 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation

[Punnaiah Choudary Kalluri]

Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.

Signed-off-by: Punnaiah Choudary Kalluri 
---
Changes in v3:
- None
Changes in v2:
- None
---
 .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  |   61 
 1 files changed, 61 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt

diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..e4f92b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,61 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible: Should be "xlnx,zynqmp-dma-1.0"
+- #dma-cells: Should be <1>, a single cell holding a line request number
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain DMA channel interrupt
+- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
+
+Optional properties:
+- xlnx,include-sg: Indicates the controller to operate in simple or scatter
+  gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
+source AXI transaction
+- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data
+- xlnx,src-issue: Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
+   descriptor read are marked Non-coherent
+- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
+   source descriptor payload are marked Non-coherent
+- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
+   dst descriptor payload are marked Non-coherent
+- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
+- xlnx,src-axi-qos: AXI QOS bits to be used for data read
+- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
+- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
+- xlnx,desc-axi-cache: AXI cache bits to be used for data read
+- xlnx,desc-axi-cache: AXI cache bits to be used for data write
+- xlnx,src-burst-len: AXI length for data read. Support only power of 2 values
+ i.e 1,2,4,8 and 16
+- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 values
+ i.e 1,2,4,8 and 16
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+   compatible = "xlnx,zynqmp-dma-1.0";
+   reg = <0x0 0xFD50 0x1000>;
+   #dma_cells = <1>;
+   interrupt-parent = <>;
+   interrupts = <0 117 4>;
+   xlnx,bus-width = <128>;
+   xlnx,include-sg;
+   xlnx,overfetch;
+   xlnx,ratectrl = <0>;
+   xlnx,src-issue = <16>;
+   xlnx,desc-axi-cohrnt;
+   xlnx,src-axi-cohrnt;
+   xlnx,dst-axi-cohrnt;
+   xlnx,desc-axi-qos = <0>;
+   xlnx,desc-axi-cache = <0>;
+   xlnx,src-axi-qos = <0>;
+   xlnx,src-axi-cache = <2>;
+   xlnx,dst-axi-qos = <0>;
+   xlnx,dst-axi-cache = <2>;
+   xlnx,src-burst-len = <4>;
+   xlnx,dst-burst-len = <4>;
+};
-- 
1.7.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: [PATCH RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 07:29:45PM -0700, Tadeusz Struk wrote:
>
> Actually I think it is useful. Without it the user will need to allocate
> a buffer, and invoke an operation only to find out that the buffer need to be
> bigger.

No the user could simply supply NULL/0 and get the requisite
information if they have no idea what the proper size is.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 05:05 PM, Herbert Xu wrote:
> Hmm, we could actually get rid of maxsize by just having each
> function check the dst_len and if it is insufficient write the
> required length in it and then return an error.

Actually I think it is useful. Without it the user will need to allocate
a buffer, and invoke an operation only to find out that the buffer need to be
bigger.
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 07:21:48PM -0700, Tadeusz Struk wrote:
>
> I thought that the ctx needs to be available for implementations to store 
> private data.
> This way we can allocate and store any type of key in the _parse_key() 
> helper and still have the cxt
> available for implementations to use for their stuff (e.g. HW context).

No for symmetric key algorithms we always store the key in the
context and never in the tfm proper.

Think about it, the generic tfm doesn't have any idea on what
the key contains so how can it store it? Only the implementation
knows the key format and can store it in a useful way.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 07:03:11PM -0700, Tadeusz Struk wrote:
> On 06/15/2015 05:05 PM, Herbert Xu wrote:
> >> > + * @setkey: Function invokes the algorithm specific set key 
> >> > function, which
> >> > + *  knows how to decode and interpret the BER encoded key
> > We should split this into two functions: setpubkey and setprivkey.
> > 
> 
> The two functions will be almost identical. We can do it this way if we want 
> to check
> if all the required elements of the key are provided. Currently I'm checking 
> this in the
> actual operation.

Right now your RSA setkey function only works if you supply both
the public key and the private key.  If the user supplies only one
key how are you going to tell whether it's public or private?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 RFC v5 3/4] crypto: rsa: add a new rsa generic implementation

[Tadeusz Struk]

On 06/15/2015 07:19 PM, Stephan Mueller wrote:
>> I'm not familiar with the FIPS requirements. I checked the NIST
>> > recommendations witch states that RSA: |n| >= 2048 is acceptable. If FIPS
>> > allows 2K and 3K only then we need to change it.
> The reason for exclusive 2k/3k is the CAVS testing: there is only the ability 
> to test 2/3k. Longer key sizes are even not allowed as per SP800-131A in 
> favor 
> of EC.

Ok I'll update it to only accept 2K & 3K. 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: [PATCH RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 04:59 PM, Herbert Xu wrote:
>> > +struct crypto_akcipher {
>> > +  void *key;
> Having a void * pointer here is useless.  The normal way of doing
> it is to place the key into the tfm context.

I thought that the ctx needs to be available for implementations to store 
private data.
This way we can allocate and store any type of key in the _parse_key() 
helper and still have the cxt
available for implementations to use for their stuff (e.g. HW context).
--
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 RFC v5 3/4] crypto: rsa: add a new rsa generic implementation

[Stephan Mueller]

Am Montag, 15. Juni 2015, 18:49:15 schrieb Tadeusz Struk:

Hi Tadeusz,

> On 06/15/2015 04:23 PM, Stephan Mueller wrote:
> >> +  /* In FIPS mode only allow key size minimum 2K */
> >> 
> >> > +if (fips_enabled && (mpi_get_size(key->n) < 256)) {
> > 
> > Considering my previous email, shouldn't that check rather be
> > 
> > if (fips_enabled &&
> > 
> > ((mpi_get_size(key->n) != 256) || (mpi_get_size(key->n) != 384))
> 
> I'm not familiar with the FIPS requirements. I checked the NIST
> recommendations witch states that RSA: |n| >= 2048 is acceptable. If FIPS
> allows 2K and 3K only then we need to change it.

The reason for exclusive 2k/3k is the CAVS testing: there is only the ability 
to test 2/3k. Longer key sizes are even not allowed as per SP800-131A in favor 
of EC.


-- 
Ciao
Stephan
--
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] builddeb: sign the modules after splitting out the debuginfo files

[Theodore Ts'o]

Signed-off-by: Theodore Ts'o 
---
 scripts/package/builddeb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 88dbf23..159ec7c 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -163,6 +163,9 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
$OBJCOPY 
--add-gnu-debuglink=$dbg_dir/usr/lib/debug/$module $tmpdir/$module
done
fi
+   if grep -q '^CONFIG_MODULE_SIG=y' $KCONFIG_CONFIG ; then
+   INSTALL_MOD_PATH="$tmpdir" $MAKE KBUILD_SRC= modules_sign
+   fi
 fi
 
 if [ "$ARCH" != "um" ]; then
-- 
2.3.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/

Re: call_rcu from trace_preempt

[Paul E. McKenney]

On Mon, Jun 15, 2015 at 06:09:56PM -0700, Alexei Starovoitov wrote:
> On 6/15/15 4:07 PM, Paul E. McKenney wrote:
> >
> >Oh...  One important thing is that both call_rcu() and kfree_rcu()
> >use per-CPU variables, managing a per-CPU linked list.  This is why
> >they disable interrupts.  If you do another call_rcu() in the middle
> >of the first one in just the wrong place, you will have two entities
> >concurrently manipulating the same linked list, which will not go well.
> 
> yes. I'm trying to find that 'wrong place'.
> The trace.patch is doing kmalloc/kfree_rcu for every preempt_enable.
> So any spin_unlock called by first call_rcu will be triggering
> 2nd recursive to call_rcu.
> But as far as I could understand rcu code that looks ok everywhere.
> call_rcu
>   debug_rcu_head_[un]queue
> debug_object_activate
>   spin_unlock
> 
> and debug_rcu_head* seems to be called from safe places
> where local_irq is enabled.

I do sympathize, but your own testing does demonstrate that it is
very much not OK.  ;-)

> >Maybe mark call_rcu() and the things it calls as notrace?  Or you
> >could maintain a separate per-CPU linked list that gathered up the
> >stuff to be kfree()ed after a grace period, and some time later
> >feed them to kfree_rcu()?
> 
> yeah, I can think of this or 10 other ways to fix it within
> kprobe+bpf area, but I think something like call_rcu_notrace()
> may be a better solution.
> Or may be single generic 'fix' for call_rcu will be enough if
> it doesn't affect all other users.

Why do you believe that it is better to fix it within call_rcu()?

> >The usual consequence of racing a pair of callback insertions on the
> >same CPU would be that one of them gets leaked, and possible all
> >subsequent callbacks.  So the lockup is no surprise.  And there are a
> >lot of other assumptions in nearby code paths about only one execution
> >at a time from a given CPU.
> 
> yes, I don't think calling 2nd call_rcu from preempt_enable violates
> this assumptions. local_irq does it job. No extra stuff is called when
> interrupts are disabled.

Perhaps you are self-deadlocking within __call_rcu_core().  If you have
not already done so, please try running with CONFIG_PROVE_LOCKING=y.
(Yes, I see your point about not calling extra stuff when interrupts
are disabled, and I remember that __call_rcu() avoids that path when
interrupts are disabled, but -something- is clearly going wrong!
Or maybe something momentarily enables interrupts somewhere, and RCU
has just been getting lucky.  Or...)

> >>Any advise on where to look is greatly appreciated.
> >
> >What I don't understand is exactly what you are trying to do.  Have more
> >complex tracers that dynamically allocate memory?  If so, having a per-CPU
> >list that stages memory to be freed so that it can be passed to call_rcu()
> >in a safe environment might make sense.  Of course, that list would need
> >to be managed carefully!
> 
> yes. We tried to compute the time the kernel spends between
> preempt_disable->preempt_enable and plot a histogram of latencies.
> 
> >Or am I missing the point of the code below?
> 
> this trace.patch is reproducer of call_rcu crashes that doing:
> preempt_enable
>   trace_preempt_on
> kfree_call_rcu
> 
> The real call stack is:
> preempt_enable
>   trace_preempt_on
> kprobe_int3_handler
>   trace_call_bpf
> bpf_map_update_elem
>   htab_map_update_elem
> kree_call_rcu

I suspect that your problem may range quite a bit further than just
call_rcu().  For example, in your stack trace, you have a recursive
call to debug_object_activate(), which might not be such good thing.

Thanx, Paul

--
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: [lkp] [x86/MSI] 52f518a3a7c: -30.5% netperf.Throughput_tps

[Jiang Liu]

On 2015/6/16 1:52, Thomas Gleixner wrote:
> On Mon, 15 Jun 2015, Huang Ying wrote:
> 
>> FYI, we noticed the below changes on
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> commit 52f518a3a7c2f80551a38d38be28bc9f335e713c ("x86/MSI: Use hierarchical 
>> irqdomains to manage MSI interrupts")
>>
> 
> I really appreciate this testing effort, but the information provided
> is not really helpful.
> 
> I asked this before. Can you pretty please, upload ALL relevant
> information (.config, full dmesg, below stats, /proc/interrupts ...)
> to some place where everyone interested can download them?
> 
> Then themail contains a useful link instead of 200k waste of network 
> bandwidth.

Hi Ying and Thomas,
I guess this report discloses a regression in hierarchy
irqdomain, and which should have been fixed by the patch posted at:
lkml.org/lkml/2015/6/1/80
The root cause is that, with hierarchy irqdomain enabled,
there are multiple irq_data associated with one irq. And function
irq_move_irq() on x86 uses a wrong copy of irq_data to check
whether there's pending irq migration operation. So all irq migration
/set_affinity operations will get pending for ever. This may
affect network performance due to interrupt load balance issue.
And the patch set posted at
www.gossamer-threads.com/lists/linux/kernel/2185533
should have solved all such regressions.

Thanks!
Gerry

> 
> Thanks,
> 
>   tglx 
> 
--
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 RFC v5 2/4] crypto: add PKE API

[Tadeusz Struk]

On 06/15/2015 05:05 PM, Herbert Xu wrote:
>> > + * @setkey:   Function invokes the algorithm specific set key 
>> > function, which
>> > + *knows how to decode and interpret the BER encoded key
> We should split this into two functions: setpubkey and setprivkey.
> 

The two functions will be almost identical. We can do it this way if we want to 
check
if all the required elements of the key are provided. Currently I'm checking 
this in the
actual operation.

>> > + *
>> > + * @reqsize:  Request context size required by algorithm 
>> > implementation
>> > + * @base: Common crypto API algorithm data structure
>> > + */
>> > +struct akcipher_alg {
>> > +  int (*sign)(struct akcipher_request *req);
>> > +  int (*verify)(struct akcipher_request *req);
>> > +  int (*encrypt)(struct akcipher_request *req);
>> > +  int (*decrypt)(struct akcipher_request *req);
>> > +  int (*maxsize)(struct crypto_akcipher *tfm);
> Hmm, we could actually get rid of maxsize by just having each
> function check the dst_len and if it is insufficient write the
> required length in it and then return an error.

Can do it that way too.
Thanks for your feedback. I will send v6 soon.
Thanks
T
--
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 v15 3/4] soc: rockchip: power-domain: add power domain driver

[Caesar Wang]

在 2015年06月15日 23:00, Paul Bolle 写道:

On Sun, 2015-06-14 at 13:13 +0800, Caesar Wang wrote:


--- /dev/null
+++ b/drivers/soc/rockchip/Kconfig
+config PM_GENERIC_DOMAINS
+tristate "Rockchip generic power domain"

Since my remarks on v13 you removed the module specific code from
pm_domains.c. But now this became a tristate symbol. That makes little
sense. Why didn't you keep bool?


Yeah, you are right. :s/tristate/bool

I forget it when the driver is moving from 'arch/arm/mach-rockchip/' to 
'/driver/soc/rockchip/'.



+depends on PM
+help
+  Say y here to enable power doamin support.

s/doamin/domain/.


Done.

+  In order to meet high performance and low power requirements, a power
+  management unit is designed or saving power when RK3288 in low power
+  mode. The RK3288 PMU is dedicated for managing the power ot the 
whole chip.

s/ot/of/


Done.

+  If unsure, say N.

Thanks,


Paul Bolle


Thanks,

Caesar







--
Thanks,
- Caesar


--
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 RFC v5 3/4] crypto: rsa: add a new rsa generic implementation

[Tadeusz Struk]

On 06/15/2015 04:23 PM, Stephan Mueller wrote:
>> +/* In FIPS mode only allow key size minimum 2K */
>> > +  if (fips_enabled && (mpi_get_size(key->n) < 256)) {
> Considering my previous email, shouldn't that check rather be
> 
> if (fips_enabled &&
> ((mpi_get_size(key->n) != 256) || (mpi_get_size(key->n) != 384))

I'm not familiar with the FIPS requirements. I checked the NIST recommendations 
witch states that
RSA: |n| >= 2048 is acceptable. If FIPS allows 2K and 3K only then we need to 
change it.

--
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: call_rcu from trace_preempt

[Alexei Starovoitov]

On 6/15/15 4:07 PM, Paul E. McKenney wrote:


Oh...  One important thing is that both call_rcu() and kfree_rcu()
use per-CPU variables, managing a per-CPU linked list.  This is why
they disable interrupts.  If you do another call_rcu() in the middle
of the first one in just the wrong place, you will have two entities
concurrently manipulating the same linked list, which will not go well.


yes. I'm trying to find that 'wrong place'.
The trace.patch is doing kmalloc/kfree_rcu for every preempt_enable.
So any spin_unlock called by first call_rcu will be triggering
2nd recursive to call_rcu.
But as far as I could understand rcu code that looks ok everywhere.
call_rcu
  debug_rcu_head_[un]queue
debug_object_activate
  spin_unlock

and debug_rcu_head* seems to be called from safe places
where local_irq is enabled.


Maybe mark call_rcu() and the things it calls as notrace?  Or you
could maintain a separate per-CPU linked list that gathered up the
stuff to be kfree()ed after a grace period, and some time later
feed them to kfree_rcu()?


yeah, I can think of this or 10 other ways to fix it within
kprobe+bpf area, but I think something like call_rcu_notrace()
may be a better solution.
Or may be single generic 'fix' for call_rcu will be enough if
it doesn't affect all other users.


The usual consequence of racing a pair of callback insertions on the
same CPU would be that one of them gets leaked, and possible all
subsequent callbacks.  So the lockup is no surprise.  And there are a
lot of other assumptions in nearby code paths about only one execution
at a time from a given CPU.


yes, I don't think calling 2nd call_rcu from preempt_enable violates
this assumptions. local_irq does it job. No extra stuff is called when
interrupts are disabled.


Any advise on where to look is greatly appreciated.


What I don't understand is exactly what you are trying to do.  Have more
complex tracers that dynamically allocate memory?  If so, having a per-CPU
list that stages memory to be freed so that it can be passed to call_rcu()
in a safe environment might make sense.  Of course, that list would need
to be managed carefully!


yes. We tried to compute the time the kernel spends between
preempt_disable->preempt_enable and plot a histogram of latencies.


Or am I missing the point of the code below?


this trace.patch is reproducer of call_rcu crashes that doing:
preempt_enable
  trace_preempt_on
kfree_call_rcu

The real call stack is:
preempt_enable
  trace_preempt_on
kprobe_int3_handler
  trace_call_bpf
bpf_map_update_elem
  htab_map_update_elem
kree_call_rcu

--
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 v4 1/1] usb: core: lpm: set lpm_capable for root hub device

[Lu Baolu]

Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.

Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.

This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882e2fc ("usb/xhci: Change how we indicate
a host supports Link PM.").

Cc: sta...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser 
Signed-off-by: Lu Baolu 
Acked-by: Alan Stern 
---
 drivers/usb/core/hcd.c | 7 +--
 drivers/usb/core/hub.c | 2 +-
 drivers/usb/core/usb.h | 1 +
 3 files changed, 7 insertions(+), 3 deletions(-)
 v1->v2 change log:
   1. two code blocks merged
   2. fix build error when CONFIG_PM is not set
 v2->v3 change log:
   1. further fix of build error when CONFIG_PM is not set
 v3->v4 change log:
   1. Add Alan's ACK

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 45a915c..1c1385e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1022,9 +1022,12 @@ static int register_root_hub(struct usb_hcd *hcd)
dev_name(_dev->dev), retval);
return (retval < 0) ? retval : -EMSGSIZE;
}
-   if (usb_dev->speed == USB_SPEED_SUPER) {
+
+   if (le16_to_cpu(usb_dev->descriptor.bcdUSB) >= 0x0201) {
retval = usb_get_bos_descriptor(usb_dev);
-   if (retval < 0) {
+   if (!retval) {
+   usb_dev->lpm_capable = usb_device_supports_lpm(usb_dev);
+   } else if (usb_dev->speed == USB_SPEED_SUPER) {
mutex_unlock(_bus_list_lock);
dev_dbg(parent_dev, "can't read %s bos descriptor %d\n",
dev_name(_dev->dev), retval);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3b71516..884d702 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -122,7 +122,7 @@ struct usb_hub *usb_hub_to_struct_hub(struct usb_device 
*hdev)
return usb_get_intfdata(hdev->actconfig->interface[0]);
 }
 
-static int usb_device_supports_lpm(struct usb_device *udev)
+int usb_device_supports_lpm(struct usb_device *udev)
 {
/* USB 2.1 (and greater) devices indicate LPM support through
 * their USB 2.0 Extended Capabilities BOS descriptor.
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 7eb1e26..457255a 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -65,6 +65,7 @@ extern int  usb_hub_init(void);
 extern void usb_hub_cleanup(void);
 extern int usb_major_init(void);
 extern void usb_major_cleanup(void);
+extern int usb_device_supports_lpm(struct usb_device *udev);
 
 #ifdef CONFIG_PM
 
-- 
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/

Re: [PATCH 2/4] locking/rtmutex: Use cmp-cmpxchg

[Jason Low]

On Mon, Jun 15, 2015 at 12:37 PM, Davidlohr Bueso  wrote:
> On Mon, 2015-06-15 at 11:34 -0700, Jason Low wrote:
>> The CCAS technique was typically used in the slow paths for those
>> other locks, where the chance of the operation returning false is
>> higher.
>
> That is true. Although I really want to use it in patch 4, I guess I
> could move the check in there, and thus avoid having it in the fastpath.

I agree, that way, we only have the extra check in cases where it is
beneficial, like in the optimistic spin loop.

Jason
--
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: [lkp] [drm/i915] 7f072451f2d: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

[Huang Ying]

On Mon, 2015-06-15 at 11:01 +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 15-06-15 om 08:58 schreef Huang Ying:
> > FYI, we noticed the below changes on
> >
> > git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
> > commit 7f072451f2d3d53e4f6939440e15ab36afed2051 ("drm/i915: Implement 
> > intel_crtc_control using atomic state, v4")
> >
> > Test Environment check: Succeeded.
> > [0/2]  Running Test(s): 0
> > [   87.315159] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
> > pipe B FIFO underrun
> > [   87.323386] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH 
> > transcoder B FIFO underrun
> > [1/2] pass: 1 Running Test(s): 1
> > [2/2] dmesg-warn: 1, pass: 1
> > Thank you for running Piglit!
> > Results have been written to /tmp/lkp/piglit-results-0/results.json
> > igt/kms_flip/rcs-wf_vblank-vs-dpms.seconds: 129.532452335
> > 2015-06-12 04:39:32 piglit summary console /tmp/lkp/piglit-results-0
> > igt/kms_flip/rcs-wf_vblank-vs-dpms: pass
> > igt/kms_flip/rcs-wf_vblank-vs-dpms-interruptible: dmesg-warn
> > summary:
> >pass: 1
> >fail: 0
> >   crash: 0
> >skip: 0
> > timeout: 0
> >warn: 0
> >  dmesg-warn: 1
> >  dmesg-fail: 0
> >   total: 2
> > all tests finished
> >
> >
> > To reproduce:
> >
> > apt-get install ruby
> > git clone 
> > git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > cd lkp-tests
> > bin/setup-local job.yaml # the job file attached in this email
> > bin/run-local   job.yaml
> >
> Are there any tests that already have FIFO underruns, before this commit?

This test is the first test run on the machine, the command line for
test is as follow:

$ piglit run igt -t igt/kms_flip/rcs-wf_vblank-vs-dpms /tmp/lkp/piglit-results-0

But the test system may be via kexec.

Best Regards,
Huang, Ying


--
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 RFC v5 4/4] crypto: add tests vectors for RSA

[Herbert Xu]

On Mon, Jun 15, 2015 at 01:18:53PM -0700, Tadeusz Struk wrote:
> New test vectors for RSA algorithm.
> 
> Signed-off-by: Tadeusz Struk 
> ---
>  crypto/Kconfig   |1 
>  crypto/testmgr.c |  149 
> ++
>  crypto/testmgr.h |  143 
>  3 files changed, 293 insertions(+)
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index a09404b..90c1f77 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -107,6 +107,7 @@ config CRYPTO_RSA
>  config CRYPTO_MANAGER
>   tristate "Cryptographic algorithm manager"
>   select CRYPTO_MANAGER2
> + select CRYPTO_AKCIPHER

Please add this to CRYPTO_MANAGER2 instead.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 10/12] mm: add the buddy system interface

[Kamezawa Hiroyuki]

On 2015/06/16 2:20, Luck, Tony wrote:

On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote:

So, there are 3 ideas.

  (1) kernel only from MIRROR / user only from MOVABLE (Tony)
  (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP)  (AKPM 
suggested)
  This makes use of the fact MOVABLE memory is reclaimable but Tony pointed 
out
  the memory reclaim can be critical for GFP_ATOMIC.
  (3) kernel only from MIRROR / user from MOVABLE, special user from MIRROR 
(Xishi)

2 Implementation ideas.
   - creating ZONE
   - creating new alloation attribute

I don't convince whether we need some new structure in mm. Isn't it good to use
ZONE_MOVABLE for not-mirrored memory ?
Then, disable fallback from ZONE_MOVABLE -> ZONE_NORMAL for (1) and (3)


We might need to rename it ... right now the memory hotplug
people use ZONE_MOVABLE to indicate regions of physical memory
that can be removed from the system.  I'm wondering whether
people will want systems that have both removable and mirrored
areas?  Then we have four attribute combinations:

mirror=no  removable=no  - prefer to use for user, could use for kernel if we 
run out of mirror
mirror=no  removable=yes - can only be used for user (kernel allocation makes 
it not-removable)
mirror=yes removable=no  - use for kernel, possibly for special users if we 
define some interface
mirror=yes removable=yes - must not use for kernel ... would have to give to 
user ... seems like a bad idea to configure a system this way



Thank you for clarification. I see "mirror=no, removable=no" case may require a 
new name.

IMHO, the value of Address-Based-Memory-Mirror is that users can protect their 
system's
important functions without using full-memory mirror. So, I feel thinking
"mirror=no, removable=no" just makes our discussion/implemenation complex 
without real
user value.

Shouldn't we start with just thiking 2 cases of
 mirror=no  removable=yes
 mirror=yes removable=no
?

And then, if the naming is problem, alias name can be added.

Thanks,
-Kame






--
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: arch linux with gcc 5.1.0 doesn't like include/linux/rcutiny.h

[Josh Triplett]

On Mon, Jun 15, 2015 at 05:20:31PM -0700, Paul E. McKenney wrote:
> On Mon, Jun 15, 2015 at 05:11:16PM -0700, Jim Davis wrote:
> > Just an FYI, but with next-20150615 (and I think some previous days too 
> > IIRC),
> > 
> > In file included from include/linux/rcupdate.h:429:0,
> >  from include/linux/srcu.h:33,
> >  from include/linux/notifier.h:15,
> >  from include/linux/memory_hotplug.h:6,
> >  from include/linux/mmzone.h:797,
> >  from include/linux/gfp.h:5,
> >  from include/linux/kmod.h:22,
> >  from include/linux/module.h:13,
> >  from kernel/rcu/rcutorture.c:28:
> > include/linux/rcutiny.h: In function ‘rcu_barrier_sched’:
> > include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
> >  static inline void rcu_barrier_sched(void)
> > ^
> > 
> > That's with a random configuration file setting
> 
> I presume that you are reporting it to the gcc guys as well?  If nothing
> else, for the obtuseness of the error message?

Agreed.  Can you reproduce this with a preprocessed file ("make
kernel/rcu/rcutorture.i" first), and then provide that file in a bug
report to GCC?

- Josh Triplett
--
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/5] x86/asm/entry/32: Replace RESTORE_RSI_RDI[_RDX] with open-coded 32-bit reads

[Denys Vlasenko]

On 06/15/2015 10:20 PM, Ingo Molnar wrote:
>> Actually, ecx and r11 need to be loaded first. They are not so much 
>> "restored" 
>> as "prepared for SYSRET insn". Every cycle lost in loading these delays 
>> SYSRET. 
>> [...]
> 
> So in the typical case they will still be cached, and so their max latency 
> should 
> be around 3 cycles.

If syscall flushes caches (say, a large read), or sleeps
and CPU schedules away, then pt_regs->ip,flags are evicted
and need to be reloaded.

> In fact because they are memory loads, they don't really have dependencies,
> they should be available to SYSRET almost immediately,

They depend on the memory data.

> i.e. within a cycle - and 
> there's no reason to believe why these loads wouldn't pipeline properly and 
> parallelize with the many other things SYSRET has to do to organize a return 
> to 
> user-space, before it can actually use the target RIP and RFLAGS.

This does not sound right.

If it takes, say, 20 cycles to pull data from e.g. L3 cache to ECX,
then SYSRET can't possibly complete sooner than in 20 cycles.

--
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] pkt_sched: sch_qfq: remove redundant -if- control statement

[David Miller]

From: Andrea Parri 
Date: Mon, 15 Jun 2015 14:20:01 +0200

> The control !hlist_unhashed() in qfq_destroy_agg() is unnecessary
> because already performed in hlist_del_init(), so remove it.
> 
> Signed-off-by: Andrea Parri 

This patch has been corrupted by your email client (TAB characters
have been transformed into sequences of SPACEs, etc.)

Please fix this up and resubmit.
--
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: arch linux with gcc 5.1.0 doesn't like include/linux/rcutiny.h

[Paul E. McKenney]

On Mon, Jun 15, 2015 at 05:11:16PM -0700, Jim Davis wrote:
> Just an FYI, but with next-20150615 (and I think some previous days too IIRC),
> 
> In file included from include/linux/rcupdate.h:429:0,
>  from include/linux/srcu.h:33,
>  from include/linux/notifier.h:15,
>  from include/linux/memory_hotplug.h:6,
>  from include/linux/mmzone.h:797,
>  from include/linux/gfp.h:5,
>  from include/linux/kmod.h:22,
>  from include/linux/module.h:13,
>  from kernel/rcu/rcutorture.c:28:
> include/linux/rcutiny.h: In function ‘rcu_barrier_sched’:
> include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
>  static inline void rcu_barrier_sched(void)
> ^
> 
> That's with a random configuration file setting

I presume that you are reporting it to the gcc guys as well?  If nothing
else, for the obtuseness of the error message?

Thanx, Paul

> # RCU Subsystem
> CONFIG_TINY_RCU=y
> CONFIG_RCU_EXPERT=y
> CONFIG_SRCU=y
> CONFIG_TASKS_RCU=y
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> CONFIG_RCU_KTHREAD_PRIO=0
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> # RCU Debugging
> CONFIG_PROVE_RCU=y
> CONFIG_PROVE_RCU_REPEATEDLY=y
> CONFIG_SPARSE_RCU_POINTER=y
> CONFIG_RCU_TORTURE_TEST=m
> # CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT is not set
> # CONFIG_RCU_TORTURE_TEST_SLOW_INIT is not set
> # CONFIG_RCU_TORTURE_TEST_SLOW_CLEANUP is not set
> CONFIG_RCU_CPU_STALL_TIMEOUT=21
> CONFIG_RCU_TRACE=y
> # CONFIG_RCU_EQS_DEBUG is not set
> 
> Jim
> 

--
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/1] net: replace if()/BUG with BUG_ON()

[David Miller]

From: Maninder Singh 
Date: Mon, 15 Jun 2015 10:35:05 +0530

> Use BUG_ON(condition) instead of if(condition)/BUG()
> 
> Signed-off-by: Maninder Singh 
> Reviewed-by: Akhilesh Kumar 

Your email client corrupted this patch, making it unusable.
--
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/

arch linux with gcc 5.1.0 doesn't like include/linux/rcutiny.h

[Jim Davis]

Just an FYI, but with next-20150615 (and I think some previous days too IIRC),

In file included from include/linux/rcupdate.h:429:0,
 from include/linux/srcu.h:33,
 from include/linux/notifier.h:15,
 from include/linux/memory_hotplug.h:6,
 from include/linux/mmzone.h:797,
 from include/linux/gfp.h:5,
 from include/linux/kmod.h:22,
 from include/linux/module.h:13,
 from kernel/rcu/rcutorture.c:28:
include/linux/rcutiny.h: In function ‘rcu_barrier_sched’:
include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
 static inline void rcu_barrier_sched(void)
^

That's with a random configuration file setting

# RCU Subsystem
CONFIG_TINY_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_EXPEDITE_BOOT is not set
# RCU Debugging
CONFIG_PROVE_RCU=y
CONFIG_PROVE_RCU_REPEATEDLY=y
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_RCU_TORTURE_TEST=m
# CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT is not set
# CONFIG_RCU_TORTURE_TEST_SLOW_INIT is not set
# CONFIG_RCU_TORTURE_TEST_SLOW_CLEANUP is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

Jim
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 01:18:42PM -0700, Tadeusz Struk wrote:
>
> + * @setkey:  Function invokes the algorithm specific set key function, which
> + *   knows how to decode and interpret the BER encoded key

We should split this into two functions: setpubkey and setprivkey.

> + *
> + * @reqsize: Request context size required by algorithm implementation
> + * @base:Common crypto API algorithm data structure
> + */
> +struct akcipher_alg {
> + int (*sign)(struct akcipher_request *req);
> + int (*verify)(struct akcipher_request *req);
> + int (*encrypt)(struct akcipher_request *req);
> + int (*decrypt)(struct akcipher_request *req);
> + int (*maxsize)(struct crypto_akcipher *tfm);

Hmm, we could actually get rid of maxsize by just having each
function check the dst_len and if it is insufficient write the
required length in it and then return an error.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 01:18:42PM -0700, Tadeusz Struk wrote:
>
> +struct crypto_akcipher {
> + void *key;

Having a void * pointer here is useless.  The normal way of doing
it is to place the key into the tfm context.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

[Krzysztof Kozlowski]

On 16.06.2015 00:23, Javier Martinez Canillas wrote:
(...)
>>> To do a more intrusive change, I should better understand the interactions
>>> between the Exynos pinctrl / GPIO, interrupt combiner and the GIC and in the
>>> meantime S2R will continue to be broken on these platforms unless someone
>>> more familiar with all this could point me in the right direction.
>>>
>>
>> As I said I am fine with this patch for now and I don't want to block it.
>>
> 
> Thanks a lot, Krzysztof who is one of the Exynos maintainers has also agreed
> with the patch so hopefully this can land sooner rather than later.

I assume this will go through irqchip tree, right?

Best regards,
Krzysztof

--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 01:18:42PM -0700, Tadeusz Struk wrote:
>
> +static int crypto_akcipher_report(struct sk_buff *skb, struct crypto_alg 
> *alg)
> +{
> + struct crypto_report_akcipher rakcipher;
> +
> + strncpy(rakcipher.type, "akcipher", sizeof(rakcipher.type));
> + strncpy(rakcipher.subtype, alg->cra_name, sizeof(rakcipher.subtype));

There is no point in reporting cra_name.  That's already taken care
of by crypto_user.c.

> +static void crypto_akcipher_show(struct seq_file *m, struct crypto_alg *alg)
> + __attribute__ ((unused));
> +
> +static void crypto_akcipher_show(struct seq_file *m, struct crypto_alg *alg)
> +{
> + seq_puts(m, "type : akcipher\n");
> + seq_printf(m, "subtype  : %s\n", alg->cra_name);

Ditto please drop subtype.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] drivers/cpufreq: include for modular exynos-cpufreq.c code

[Krzysztof Kozlowski]

On 16.06.2015 08:47, Rafael J. Wysocki wrote:
> On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
>> This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ")
>> and also contains modular function calls so it should explicitly include
>> module.h to avoid compile breakage during pending header shuffles.
>>
>> Cc: "Rafael J. Wysocki" 
>> Cc: Viresh Kumar 
>> Cc: Kukjin Kim 
>> Cc: Krzysztof Kozlowski 
>> Cc: linux...@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-samsung-...@vger.kernel.org
>> Signed-off-by: Paul Gortmaker 
> 
> I'm assuming that this will go in via the Samsung tree.
> 
> 
>> ---
>>
>> [ patch will be appended to the implicit include fixup series, see:
>>   
>> https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortma...@windriver.com
>>   for the original series posting.]

Paul, will you handle the patch or should it go through Samsung tree?

Best regards,
Krzysztof
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 01:18:42PM -0700, Tadeusz Struk wrote:
>
> +/**
> + * crypto_register_akcipher() -- Register public key algorithm
> + *
> + * Function registers an implementation of a public key verify algorithm
> + *
> + * @alg: algorithm definition
> + *
> + * Return: zero on success; error code in case of error
> + */
> +int crypto_register_akcipher(struct akcipher_alg *alg);
> +
> +/**
> + * crypto_unregister_akcipher() -- Unregister public key algorithm
> + *
> + * Function unregisters an implementation of a public key verify algorithm
> + *
> + * @alg: algorithm definition
> + */
> +void crypto_unregister_akcipher(struct akcipher_alg *alg);

These two functions and anything else that's specific to public key
implementors should go into crypto/internal.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 01:18:42PM -0700, Tadeusz Struk wrote:
>
> +/**
> + * crypto_akcipher_setkey() -- Invoke public key setkey operation
> + *
> + * Function invokes the algorithm specific set key function, which knows
> + * how to decode and interpret the encoded key
> + *
> + * @tfm: tfm handle
> + * @key: BER encoded private or public key
> + * @keylen:  length of the key
> + *
> + * Return: size required to store result or error code in case of error

cut-n-paste error?
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 RFC v5 2/4] crypto: add PKE API

[Herbert Xu]

On Mon, Jun 15, 2015 at 01:18:42PM -0700, Tadeusz Struk wrote:
>
> +struct akcipher_request {
> + struct crypto_async_request base;
> + void *src;
> + void *dst;
> + unsigned int src_len;
> + unsigned int dst_len;
> + unsigned int *result_len;
> + void *__ctx[] CRYPTO_MINALIGN_ATTR;
> +};

result_len is redundant.  You can write to dst_len after the
operation is done.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: tegra124: pmu support

[Jon Hunter]

On 15/06/15 19:46, Kyle Huey wrote:
> This patch modifies the device tree for tegra124 based devices to enable the 
> Cortex A15 PMU.  The interrupt numbers are taken from NVIDIA TRM 
> DP-06905-001_v03p.  This patch was tested on a Jetson TK1.
> 
> Signed-off-by: Kyle Huey 
> ---
>  arch/arm/boot/dts/tegra124.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
> index 4be06c6..d966d4e 100644
> --- a/arch/arm/boot/dts/tegra124.dtsi
> +++ b/arch/arm/boot/dts/tegra124.dtsi
> @@ -906,16 +906,24 @@
>  
>   cpu@3 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a15";
>   reg = <3>;
>   };
>   };
>  
> + pmu {
> + compatible = "arm,cortex-a15-pmu";
> + interrupts = ,
> +  ,
> +  ,
> +  ;
> + };
> +
>   thermal-zones {
>   cpu {
>   polling-delay-passive = <1000>;
>   polling-delay = <1000>;
>  
>   thermal-sensors =
>   < TEGRA124_SOCTHERM_SENSOR_CPU>;
>   };
> 

Acked-by: Jon Hunter 

Jon
--
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: ADMIN TEAM‏‏‏‏

[Sarah Ghebrezghi]

From: Sarah Ghebrezghi
Sent: June 15, 2015 3:49 PM
To: Sarah Ghebrezghi
Subject: ADMIN TEAM

Dear Webmail User,

Your two incoming mails were placed on pending status due to the recent upgrade 
in our database,

In order to receive the messages kindly CLICK 
HERE

Login with your correct Webmail information's and wait for responds from our 
data base service.
We apologize for any inconvenience and do appreciate your understanding.

Thanks,
The Microsoft Account Team.

--
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/3] writeback, blkio: add documentation for cgroup writeback support

[Theodore Ts'o]

On Mon, Jun 15, 2015 at 02:23:45PM -0400, Tejun Heo wrote:
> 
> On ext2, there's nothing interlocking each other.  My understanding of
> ext4 is pretty limited but as long as the journal head doesn't
> overwrap and gets bloked on the slow one, it should be fine, so for
> most use cases, this shouldn't be a problem.

The writes to the journal in ext3/ext4 are done from the jbd/jbd2
kernel thread.  So writes to the journal shouldn't be a problem.  In
data=ordered mode inodes that have blocks that were allocated during
the current transaction do have to have their data blocks written out,
and this is done by the jbd/jbd2 thread using filemap_fdatawait().

If this gets throttled because blocks were originally dirtied by some
cgroup that didn't have much disk time quota, then all file system
activities will get stalled out until the ordered mode writeback
completes, which means if there are any high priority cgroups trying
to execute any system call that mutates file system state will block
until the commit has gotten past the initial setup stage, and so other
system activity could sputter to a halt --- at which point the commit
will be allowed to compete, and then all of the calls to
ext4_journal_start() will unblock, and the system will come back to
life.  :-)

Because ext3 doesn't have delayed allocation, it will orders of
magnitude more data=ordered block flushing, so this problem will be
far worse with ext3 compared to ext4.

So if there is some way we can signal to any cgroup that that might be
throttling writeback or disk I/O that the jbd/jbd2 process should be
considered privileged, that would be a good since it would allow us to
avoid a potential priority inversion problem. 

- Ted
--
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] cpufreq, Fix overflow in busy_scaled due to long delay [v2]

[Prarit Bhargava]

On 06/15/2015 06:12 PM, Kristen Carlson Accardi wrote:
> On Mon, 15 Jun 2015 13:43:29 -0400
> Prarit Bhargava  wrote:
> 
>> The kernel may delay interrupts for a long time which can result in timers
>> being delayed. If this occurs the intel_pstate driver will crash with a
>> divide by zero error:
>>
>> divide error:  [#1] SMP
>> Modules linked in: btrfs zlib_deflate raid6_pq xor msdos ext4 mbcache jbd2 
>> binfmt_misc arc4 md4 nls_utf8 cifs dns_resolver tcp_lp bnep bluetooth rfkill 
>> fuse dm_service_time iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi 
>> nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ftp 
>> ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute 
>> bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 
>> nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw 
>> ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
>> nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw 
>> iptable_filter ip_tables intel_powerclamp coretemp vfat fat kvm_intel 
>> iTCO_wdt iTCO_vendor_support ipmi_devintf sr_mod kvm crct10dif_pclmul
>>  crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel cdc_ether lrw 
>> usbnet cdrom mii gf128mul glue_helper ablk_helper cryptd lpc_ich mfd_core 
>> pcspkr sb_edac edac_core ipmi_si ipmi_msghandler ioatdma wmi shpchp acpi_pad 
>> nfsd auth_rpcgss nfs_acl lockd uinput dm_multipath sunrpc xfs libcrc32c 
>> usb_storage sd_mod crc_t10dif crct10dif_common ixgbe mgag200 syscopyarea 
>> sysfillrect sysimgblt mdio drm_kms_helper ttm igb drm ptp pps_core dca 
>> i2c_algo_bit megaraid_sas i2c_core dm_mirror dm_region_hash dm_log dm_mod
>> CPU: 113 PID: 0 Comm: swapper/113 Tainted: GW   --   
>> 3.10.0-229.1.2.el7.x86_64 #1
>> Hardware name: IBM x3950 X6 -[3837AC2]-/00FN827, BIOS -[A8E112BUS-1.00]- 
>> 08/27/2014
>> task: 880fe8abe660 ti: 880fe8ae4000 task.ti: 880fe8ae4000
>> RIP: 0010:[]  [] 
>> intel_pstate_timer_func+0x179/0x3d0
>> RSP: 0018:883fff4e3db8  EFLAGS: 00010206
>> RAX: 2710 RBX: 883fe6965100 RCX: 
>> RDX:  RSI: 0010 RDI: 2e53632d
>> RBP: 883fff4e3e20 R08: 000e6f69a5a125c0 R09: 883fe84ec001
>> R10: 0002 R11: 0005 R12: 49f5
>> R13: 00271000 R14: 49f5 R15: 0246
>> FS:  () GS:883fff4e() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 7f7668601000 CR3: 0190a000 CR4: 001407e0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: 0ff0 DR7: 0400
>> Stack:
>>  883fff4e3e58 81099dc1 0086 0071
>>  883fff4f3680 0071 fbdc8a965e33afee 810b69dd
>>  883fe84ec000 883fe6965108 0100 814a9100
>> Call Trace:
>>  
>>
>>  [] ? run_posix_cpu_timers+0x51/0x840
>>  [] ? trigger_load_balance+0x5d/0x200
>>  [] ? pid_param_set+0x130/0x130
>>  [] call_timer_fn+0x36/0x110
>>  [] ? pid_param_set+0x130/0x130
>>  [] run_timer_softirq+0x21f/0x320
>>  [] __do_softirq+0xef/0x280
>>  [] call_softirq+0x1c/0x30
>>  [] do_softirq+0x65/0xa0
>>  [] irq_exit+0x115/0x120
>>  [] smp_apic_timer_interrupt+0x45/0x60
>>  [] apic_timer_interrupt+0x6d/0x80
>>  
>>
>>  [] ? cpuidle_enter_state+0x52/0xc0
>>  [] ? cpuidle_enter_state+0x48/0xc0
>>  [] cpuidle_idle_call+0xc5/0x200
>>  [] arch_cpu_idle+0xe/0x30
>>  [] cpu_startup_entry+0xf1/0x290
>>  [] start_secondary+0x1ba/0x230
>> Code: 42 0f 00 45 89 e6 48 01 c2 43 8d 44 6d 00 39 d0 73 26 49 c1 e5 08 89 
>> d2 4d 63 f4 49 63 c5 48 c1 e2 08 48 c1 e0 08 48 63 ca 48 99 <48> f7 f9 48 98 
>> 4c 0f af f0 49 c1 ee 08 8b 43 78 c1 e0 08 44 29
>> RIP  [] intel_pstate_timer_func+0x179/0x3d0
>>  RSP 
>>
>> The kernel values for cpudata for CPU 113 were:
>>
>> struct cpudata {
>>   cpu = 113,
>>   timer = {
>> entry = {
>>   next = 0x0,
>>   prev = 0xdead00200200
>> },
>> expires = 8357799745,
>> base = 0x883fe84ec001,
>> function = 0x814a9100 ,
>> data = 18446612406765768960,
>> 
>> i_gain = 0,
>> d_gain = 0,
>> deadband = 0,
>> last_err = 22489
>>   },
>>   last_sample_time = {
>> tv64 = 4063132438017305
>>   },
>>   prev_aperf = 287326796397463,
>>   prev_mperf = 251427432090198,
>>   sample = {
>> core_pct_busy = 23081,
>> aperf = 2937407,
>> mperf = 3257884,
>> freq = 2524484,
>> time = {
>>   tv64 = 4063149215234118
>> }
>>   }
>> }
>>
>> which results in the time between samples = last_sample_time - sample.time
>> = 4063149215234118 - 4063132438017305 = 16777216813 which is 16.777 seconds.
>>
>> The duration between reads of the APERF and MPERF registers overflowed a s32
>> sized integer in intel_pstate_get_scaled_busy()'s call to 

RE: ADMIN TEAM‏‏‏‏

[Sarah Ghebrezghi]

From: Sarah Ghebrezghi
Sent: June 15, 2015 3:49 PM
To: Sarah Ghebrezghi
Subject: ADMIN TEAM

Dear Webmail User,

Your two incoming mails were placed on pending status due to the recent upgrade 
in our database,

In order to receive the messages kindly CLICK 
HERE

Login with your correct Webmail information's and wait for responds from our 
data base service.
We apologize for any inconvenience and do appreciate your understanding.

Thanks,
The Microsoft Account Team.

--
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: [RESEND PATCH 0/3] watchdog: MAX63xx cleanup and platform settings

[Vivien Didelot]

Hi Guenter,

On Jun 15, 2015, at 5:41 PM, Guenter Roeck li...@roeck-us.net wrote:

> On 06/15/2015 12:58 PM, Vivien Didelot wrote:
>> The first version of this patchset from January, 29 [1] got no feedback
>> from the maintainer. 1/4 [2] was applied to watchdog-next on May, 30
>> though. A concern about constants removal was raised in the preliminary
>> 2/4 cleanup patch, the explanation has been added to the related commit
>> message.
>>
> 
> Hi Vivien,
> 
> For my part, adding a comment about removal of constants does not alleviate
> my concern about removing those constants. I just don't believe that removing
> constants is a good idea, no matter what the arguments for doing so might be.

Ok then, I'll minimize this cleanup patch and keep MAX6369_WDSET and
MAX6369_WDI as is.

Thanks,
-v
--
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] drivers/cpufreq: Convert non-modular s5pv210-cpufreq.c to use builtin_platform_driver

[Rafael J. Wysocki]

On Wednesday, June 03, 2015 05:12:46 PM Paul Gortmaker wrote:
> This file depends on a Kconfig option which is a bool, so
> we use the appropriate registration function, which avoids us
> relying on an implicit inclusion of  which we are
> doing currently.
> 
> While this currently works, we really don't want to be including
> the module.h header in non-modular code, which we'd be forced
> to do, pending some upcoming code relocation from init.h into
> module.h.  So we fix it now by using the non-modular equivalent.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: Kukjin Kim 
> Cc: linux...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Paul Gortmaker 

I'm assuming that this will go in via the Samsung tree.


-- 
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 RFC v5 3/4] crypto: rsa: add a new rsa generic implementation

[Stephan Mueller]

Am Montag, 15. Juni 2015, 13:18:47 schrieb Tadeusz Struk:

Hi Tadeusz,

> Add a new rsa generic SW implementation.
> This implements only cryptographic primitives.

Thank you, that seems to address the issues around the FIPS side including the 
self test code.

Though, I have one question:

> +
> +int rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
> +   const void *value, size_t vlen)
> +{
> + struct crypto_akcipher *tfm = context;
> + struct rsa_key *key = tfm->key;
> +
> + key->n = mpi_read_raw_data(value, vlen);
> +
> + if (!key->n)
> + return -ENOMEM;
> +
> + /* In FIPS mode only allow key size minimum 2K */
> + if (fips_enabled && (mpi_get_size(key->n) < 256)) {

Considering my previous email, shouldn't that check rather be

if (fips_enabled &&
((mpi_get_size(key->n) != 256) || (mpi_get_size(key->n) != 384))

?

> + pr_err("RSA: key size not allowed in FIPS mode\n");
> + mpi_free(key->n);
> + key->n = NULL;
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +int rsa_get_e(void *context, size_t hdrlen, unsigned char tag,
> +   const void *value, size_t vlen)
> +{
> + struct crypto_akcipher *tfm = context;
> + struct rsa_key *key = tfm->key;
> +
> + key->e = mpi_read_raw_data(value, vlen);
> +
> + if (!key->e)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +int rsa_get_d(void *context, size_t hdrlen, unsigned char tag,
> +   const void *value, size_t vlen)
> +{
> + struct crypto_akcipher *tfm = context;
> + struct rsa_key *key = tfm->key;
> +
> + key->d = mpi_read_raw_data(value, vlen);
> +
> + if (!key->d)
> + return -ENOMEM;
> +
> + /* In FIPS mode only allow key size minimum 2K */
> + if (fips_enabled && (mpi_get_size(key->d) < 256)) {

dto.

> + pr_err("RSA: key size not allowed in FIPS mode\n");
> + mpi_free(key->d);
> + key->d = NULL;
> + return -EINVAL;
> + }
> + return 0;
> +}
> +

Thanks
-- 
Ciao
Stephan
--
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 v9 2/2] pwm: core: Set enable state properly on failed call to enable

[Jonathan Richardson]

On 15-06-15 02:21 PM, Jonathan Richardson wrote:
> The pwm_enable function didn't clear the enabled bit if a call to a
> clients enable function returned an error. The result was that the state
> of the pwm core was wrong. Clearing the bit when enable returns an error
> ensures the state is properly set.
> 
> Tested-by: Jonathan Richardson 
> Reviewed-by: Dmitry Torokhov 
> Signed-off-by: Jonathan Richardson 
> ---
>  drivers/pwm/core.c  |   19 ---
>  include/linux/pwm.h |2 ++
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 76b0386..c255267 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -263,6 +263,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
>   pwm->pwm = chip->base + i;
>   pwm->hwpwm = i;
>   pwm->polarity = polarity;
> + mutex_init(>lock);
>  
>   radix_tree_insert(_tree, pwm->pwm, pwm);
>   }
> @@ -474,10 +475,22 @@ EXPORT_SYMBOL_GPL(pwm_set_polarity);
>   */
>  int pwm_enable(struct pwm_device *pwm)
>  {
> - if (pwm && !test_and_set_bit(PWMF_ENABLED, >flags))
> - return pwm->chip->ops->enable(pwm->chip, pwm);
> + int err = 0;
>  
> - return pwm ? 0 : -EINVAL;
> + if (!pwm)
> + return -EINVAL;
> +
> + mutex_lock(>lock);
> +
> + if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
> + err = pwm->chip->ops->enable(pwm->chip, pwm);
> + if (err)
> + clear_bit(PWMF_ENABLED, >flags);
> + }
> +
> + mutex_unlock(>lock);
> +
> + return err;
>  }
>  EXPORT_SYMBOL_GPL(pwm_enable);

I meant to add the mutex check in disable also, but what about when
PWMF_ENABLED is checked in pwm_set_polarity() and pwm_dbg_show()?

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: [PATCH] drivers/cpufreq: include for modular exynos-cpufreq.c code

[Rafael J. Wysocki]

On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
> This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ")
> and also contains modular function calls so it should explicitly include
> module.h to avoid compile breakage during pending header shuffles.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: linux...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

I'm assuming that this will go in via the Samsung tree.


> ---
> 
> [ patch will be appended to the implicit include fixup series, see:
>   
> https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortma...@windriver.com
>   for the original series posting.]
> 
>  drivers/cpufreq/exynos-cpufreq.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/exynos-cpufreq.c 
> b/drivers/cpufreq/exynos-cpufreq.c
> index 82d2fbb20f7e..4c157302365f 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -10,6 +10,7 @@
>  */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 

-- 
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 v2 08/17] baycom_epp: Replace rdtscl() with native_read_tsc()

[Andy Lutomirski]

On Sat, Jun 13, 2015 at 3:45 AM, walter harms  wrote:
> Hello,
> please add a line what is the difference between V1 and V2.
>

There is none.  v1 was screwed up elsewhere in the series.

This is part of a larger series to clean up the rdtsc inlines and
macros.  I'm hoping for an ack so this can go in through -tip.

Thanks,
Andy

> re,
>  wh
>
> Am 13.06.2015 01:44, schrieb Andy Lutomirski:
>> This is only used if BAYCOM_DEBUG is defined.
>>
>> Cc: Thomas Sailer 
>> Cc: linux-h...@vger.kernel.org
>> Signed-off-by: Andy Lutomirski 
>> ---
>>  drivers/net/hamradio/baycom_epp.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/hamradio/baycom_epp.c 
>> b/drivers/net/hamradio/baycom_epp.c
>> index 83c7cce0d172..44e5c3b5e0af 100644
>> --- a/drivers/net/hamradio/baycom_epp.c
>> +++ b/drivers/net/hamradio/baycom_epp.c
>> @@ -638,7 +638,7 @@ static int receive(struct net_device *dev, int cnt)
>>  #define GETTICK(x)\
>>  ({\
>>   if (cpu_has_tsc)  \
>> - rdtscl(x);\
>> + x = (unsigned int)native_read_tsc();  \
>>  })
>>  #else /* __i386__ */
>>  #define GETTICK(x)



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/