[PATCH 1/1] drm/i915: Fix BUG in i915_gem.c when switch to console

2015-03-10 Thread Xi Ruoyao

In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer
assigned to plane crtc->primary by

crtc->primary->fb = fb;

However, it forgot to change crtc->primary->state->fb. However, when we
switch to console, some kernel code will read crtc->primary->state->fb
to get the framebuffer assigned to crtc->primaty. Then a framebuffer
object can be unpinned twice and a kernel BUG will be produced in 
i915_gem.c.


So, update crtc->primary->state->fb in intel_display.c using
drm_atomic_set_fb_for_plane to fix the BUG.

Signed-off-by: Xi Ruoyao 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c

index e730789..97083fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -37,6 +37,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_trace.h"
+#include 
 #include 
 #include 
 #include 
@@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
 drm_gem_object_reference(>base);

 crtc->primary->fb = fb;
+drm_atomic_set_fb_for_plane(crtc->primary->state, fb);

 work->pending_flip_obj = obj;

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


linux-next: Tree for Mar 11

2015-03-10 Thread Stephen Rothwell
Hi all,

Changes since 20150310:

New tree: drm-exynos

The sound-asoc tree still had its build failure so I used the version from
next-20150306.

The regulator tree lost its build failure.

The tip tree gained a conflict against the usb-gadget-fixes tree.

The staging tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3446
 3448 files changed, 138744 insertions(+), 73083 deletions(-)



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

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 208 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (affb8172de39 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (6d021b724481 ARM: dump pgd, pmd and pte states on 
unhandled data abort faults)
Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet 
bridging)
Merging metag-fixes/fixes (c2996cb29bfb metag: Fix KSTK_EIP() and KSTK_ESP() 
macros)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1)
Merging powerpc-merge-mpe/fixes (4ad04e598711 powerpc/iommu: Remove IOMMU 
device references via bus notifier)
Merging sparc/master (53eb2516972b sparc: semtimedop() unreachable due to 
comparison error)
Merging net/master (7768eed8bf1d net: add comment for sock_efree() usage)
Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in 
xfrm_lookup())
Merging sound-current/for-linus (59294a01d703 ALSA: firewire-lib: leave unit 
reference counting completely)
Merging pci-current/for-linus (085a68d0010f PCI: xgene: Add register offset to 
config space base address)
Merging wireless-drivers/master (3f1615340ace brcmfmac: Perform bound checking 
on vendor command buffer)
Merging driver-core.current/driver-core-linus (c517d838eb7d Linux 4.0-rc1)
Merging tty.current/tty-linus (9eccca084320 Linux 4.0-rc3)
Merging usb.current/usb-linus (9eccca084320 Linux 4.0-rc3)
Merging usb-gadget-fixes/fixes (1998adab1c18 usb: isp1760: add 
peripheral/device controller chip id)
Merging usb-serial-fixes/usb-linus (9eccca084320 Linux 4.0-rc3)
Merging staging.current/staging-linus (1f51d5801859 vt6655: Fix late setting of 
byRFType.)
Merging char-misc.current/char-misc-linus (9eccca084320 Linux 4.0-rc3)
Merging input-current/for-linus (4eb8d6e7e5aa Input: psmouse - disable "palm 
detection" in the focaltech driver)
Merging crypto-current/master (001eabfd54c0 crypto: arm/aes update NEON AES 
module to latest OpenSSL version)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays 
with sub-devices tests)
Merging rr-fixes/fixes (f47689345931 lguest: update help text.)
Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci 
device type in vfio_pci_probe())
Merging kselftest-fixes/fixes (9eccca084320 Linux 4.0-rc3)
Merging drm-intel-fixes/for-linux-next-fixes (5e4f518959bd drm/i915: Prevent 
TLB error on first execution on SNB)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (3240dd57e533 ARC: Fix 

Re: [PATCH v6 3/3] ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)

2015-03-10 Thread Jason Cooper
On Wed, Mar 11, 2015 at 08:48:15AM +0800, Shawn Guo wrote:
> On Sun, Mar 01, 2015 at 11:41:29PM +0100, Stefan Agner wrote:
> > Add the Miscellaneous System Control Module (MSCM) to the base
> > device tree for Vybrid SoC's. This module contains registers
> > to get information of the individual and current (accessing)
> > CPU. In a second block, there is an interrupt router, which
> > handles the routing of the interrupts between the two CPU cores
> > on VF6xx variants of the SoC. However, also on single core
> > variants the interrupt router needs to be configured in order
> > to receive interrupts on the CPU's interrupt controller. Almost
> > all peripheral interrupts are routed through the router, hence
> > the MSCM module is the default interrupt parent for this SoC.
> > 
> > In a earlier commit the interrupt nodes were moved out of the
> > peripheral nodes and specified in the CPU specific vf500.dtsi
> > device tree. This allowed to use the base device tree vfxxx.dtsi
> > also for a Cortex-M4 specific device tree, which uses different
> > interrupt nodes due to the NVIC interrupt controller. However,
> > since the interrupt parent for peripherals is the MSCM module
> > independently which CPU the device tree is used for, we can move
> > the interrupt nodes into the base device tree vfxxx.dtsi again.
> > Depending on which CPU this base device tree will be used with,
> > the correct parent interrupt controller has to be assigned to
> > the MSCM-IR node (GIC or NVIC). The driver takes care of the
> > parent interrupt controller specific needs (interrupt-cells).
> > 
> > Acked-by: Marc Zyngier 
> > Signed-off-by: Stefan Agner 
> 
> Stefan,
> 
> I guess this patch has a run-time dependency on the first two in the
> series, right?  Or put it another way, if I apply this single patch on
> my branch, the dtb and kernel built from the same branch do not work
> together, right?  If so, we will need to either wait for the first two
> hit mainline or pull Jason's irqchip/vybrid branch into my tree as
> prerequisite (irqchip/vybrid needs to be stable).

No problem, I'll only add patches on top of this if needed.  no rebasing.

thx,

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: [PATCH v2 1/2] cgroups: allow a cgroup subsystem to reject a fork

2015-03-10 Thread Aleksa Sarai
Hello Tejun,

On Wed, Mar 11, 2015 at 2:17 AM, Tejun Heo  wrote:
> On Wed, Mar 11, 2015 at 01:51:06AM +1100, Aleksa Sarai wrote:
>> Actually, I'm fairly sure we can do it all inside cgroup_post_fork() because
>> inside cgroup_post_fork() we have access to both the old css_set and the new
>> one. Then it's just a matter of reverting and re-applying the charge to the
>> hierarchies.
>
> But the problem isn't whether we know both the old and new ones.  The
> problem is that we can only abort before the fork commit point and the
> "old" one may change between the abort point and post-commit point so
> we need to trycharge the old one at the possible abort point, remember
> to which css it got charged and then check whether the association has
> changed inbetween at the post commit point and readjust if so.

Actually, it appears I was wrong. Until we hit cgroup_post_fork()'s setting up
of the task's css_set, cgroup_can_fork() ends up charging init_css_set *every
time*. Which means a check to see if it changed will always show that it had
changed. The issue is that we need to access the css_set which is going to be
saved as the task's css_set in order to decide if the task should fork.

We know that the task will have its css_set set to task_css_set(current), and
we could just use that in cgroup_can_fork(). The only question is, can
task_css_set(current) change between cgroup_can_fork() and cgroup_post_fork()?

If it can change between the two calls, then we're in trouble -- there'd be no
reliable way of checking that the future css_set allows for the fork without
going through the registration of the css_set *proper* in cgroup_post_fork()
unless we hold css_set_rwsem for the entirety of the can_fork() to post_fork()
segment (which I can't imagine is a good idea).

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


Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

2015-03-10 Thread Archit Taneja



On 03/10/2015 09:03 PM, Jani Nikula wrote:

On Tue, 10 Mar 2015, Archit Taneja  wrote:

On 03/10/2015 03:35 PM, Daniel Vetter wrote:

On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:



On 03/10/2015 03:17 PM, Daniel Vetter wrote:

On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:

DRM_KMS_FB_HELPER selects that for us, right?


Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.


I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff
internally in their respective xyz_fbdev.c files.

Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers
and replace them with 'select DRM_FBDEV_EMULATION'?


Slightly tangential: As a rule of thumb, you should not "select"
anything that is visible in menuconfig or has dependencies [1]. This
will break the build eventually, and attempts to fix it are troublesome
[2].


Thanks, I'll keep this in mind!

Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 5/6] drm/imx: Remove local fbdev emulation Kconfig option

2015-03-10 Thread Archit Taneja



On 03/10/2015 04:24 PM, Philipp Zabel wrote:

Hi Archit,

thanks for the cleanup!

Am Dienstag, den 10.03.2015, 15:11 +0530 schrieb Archit Taneja:

DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation for
the imx kms driver.

Remove this local config option and use the top level DRM_FBDEV_EMULATION config
option where applicable. Using this config lets us also prevent wrapping around
drm_fb_helper_* calls with #ifdefs in certain places.

We replace the #ifdef in imx_drm_driver_load with CONFIG_DRM_FBDEV_EMULATION.
It's probably okay to get remove the #ifdef itself, but just left it here for
now to be safe. It can be removed after some testing.

Signed-off-by: Archit Taneja 


Tested-by: Philipp Zabel 
(Both with and without the #ifdef CONFIG_DRM_FBDEV_EMULATION removed.)



Thanks for testing it out.


Although this is for another patch, I think the legacyfb_depth
module_param should be removed altogether if CONFIG_DRM_FBDEV_EMULATION
is disabled, so maybe that #ifdef should stay.


I'll create a patch for that for future revs of this patch set.

Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] shmem: Add eventfd notification on utlilization level

2015-03-10 Thread Kyungmin Park
On Tue, Mar 10, 2015 at 11:22 PM, Jan Kara  wrote:
> On Tue 10-03-15 06:03:23, Christoph Hellwig wrote:
>> On Tue, Mar 10, 2015 at 10:51:41AM +0900, Kyungmin Park wrote:
>> > Any updates?
>>
>> Please just add disk quota support to tmpfs so thast the standard quota
>> netlink notifications can be used.
>   If I understand the problem at hand, they are really interested in
> notification when running out of free space. Using quota for that doesn't
> seem ideal since that tracks used space per user, not free space on fs as a
> whole.
>
> But if I remember right there were discussions about ENOSPC notification
> from filesystem for thin provisioning usecases. It would be good to make
> this consistent with those but I'm not sure if it went anywhere.

In mobile case, it provides two warning messages when it remains 5%
and 0.1% respectively.
to achieve it, some daemon call statfs periodically. right it's inefficient.

that's reason we need some notification method from filesystem.

tmpfs is different story. some malicious app fills tmpfs then system
goes slow. so it has to check it periodically.
to avoid it, this patch is developed and want to get feedback.

we considered quota but it's not desired one. other can't write tmpfs
even though it has 20% remaining.

Thank you,
Kyungmin Park
--
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 -next] zsmalloc: Include linux/sched.h to fix build error

2015-03-10 Thread Minchan Kim
Hello Guenter,

On Tue, Mar 10, 2015 at 08:41:02PM -0700, Guenter Roeck wrote:
> Fix:
> 
> mm/zsmalloc.c: In function '__zs_compact':
> mm/zsmalloc.c:1747:2: error: implicit declaration of function 'cond_resched'
> 
> seen when building mips:allmodconfig.
> 
> Fixes: c4d204c38734 ("zsmalloc: support compaction")
> Cc: Minchan Kim 
> Signed-off-by: Guenter Roeck 

Thanks for the fixing!

A few hours ago, Geert Uytterhoeven sent a patch.
http://www.spinics.net/lists/linux-mm/msg85571.html

Thanks.

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


[PATCH v2] x86: Bypass legacy PIC and PIT in ACPI hardware reduced mode

2015-03-10 Thread Li, Aubrey
On a platform in ACPI Hardware-reduced mode, the legacy PIC and PIT
may not be initialized even though they may be present in silicon.
Touching these legacy components causes unexpected result on system.

On Bay Trail-T(ASUS-T100) platform, touching these legacy components
blocks platform hardware low idle power state(S0ix) during system
suspend. So we should bypass them in ACPI hardware reduced mode.

Suggested-by: Arjan van de Ven 
Signed-off-by: Li Aubrey 
Cc: Len Brown 
Cc: Rafael J. Wysocki 
Cc: Alan Cox 
---
 arch/x86/kernel/acpi/boot.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index b9e30da..1e5a7865 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1343,6 +1343,24 @@ static int __init dmi_ignore_irq0_timer_override(const 
struct dmi_system_id *d)
 }
 
 /*
+ * ACPI offers an alternative platform interface model that removes
+ * ACPI hardware requirements for platforms that do not implement
+ * the PC Architecture.
+ *
+ * We initialize the Hardware-reduced ACPI model here
+ */
+static void __init acpi_reduced_hw_init(void)
+{
+   /*
+* Override x86_init functions and bypass legacy pic
+* in Hardware-reduced ACPI mode
+*/
+   x86_init.timers.timer_init  = x86_init_noop;
+   x86_init.irqs.pre_vector_init   = x86_init_noop;
+   legacy_pic  = _legacy_pic;
+}
+
+/*
  * If your system is blacklisted here, but you find that acpi=force
  * works for you, please contact linux-a...@vger.kernel.org
  */
@@ -1541,6 +1559,9 @@ int __init early_acpi_boot_init(void)
 */
early_acpi_process_madt();
 
+   if (acpi_gbl_reduced_hardware)
+   acpi_reduced_hw_init();
+
return 0;
 }
 
-- 
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/


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

2015-03-10 Thread Minchan Kim
On Wed, Mar 11, 2015 at 10:14:51AM +0800, Wang, Yalin wrote:
> > -Original Message-
> > From: Minchan Kim [mailto:minc...@kernel.org]
> > Sent: Wednesday, March 11, 2015 9:21 AM
> > To: Andrew Morton
> > Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; Michal Hocko;
> > Johannes Weiner; Mel Gorman; Rik van Riel; Shaohua Li; Wang, Yalin; Minchan
> > Kim
> > Subject: [PATCH 3/4] mm: move lazy free pages to inactive list
> > 
> > MADV_FREE is hint that it's okay to discard pages if there is
> > memory pressure and we uses reclaimers(ie, kswapd and direct reclaim)
> > to free them so there is no worth to remain them in active anonymous LRU
> > so this patch moves them to inactive LRU list's head.
> > 
> > This means that MADV_FREE-ed pages which were living on the inactive list
> > are reclaimed first because they are more likely to be cold rather than
> > recently active pages.
> > 
> > A arguable issue for the approach would be whether we should put it to
> > head or tail in inactive list. I selected *head* because kernel cannot
> > make sure it's really cold or warm for every MADV_FREE usecase but
> > at least we know it's not *hot* so landing of inactive head would be
> > comprimise for various usecases.
> > 
> > This is fixing a suboptimal behavior of MADV_FREE when pages living on
> > the active list will sit there for a long time even under memory
> > pressure while the inactive list is reclaimed heavily. This basically
> > breaks the whole purpose of using MADV_FREE to help the system to free
> > memory which is might not be used.
> > 
> > Acked-by: Michal Hocko 
> > Signed-off-by: Minchan Kim 
> > ---
> >  include/linux/swap.h |  1 +
> >  mm/madvise.c |  2 ++
> >  mm/swap.c| 35 +++
> >  3 files changed, 38 insertions(+)
> > 
> > diff --git a/include/linux/swap.h b/include/linux/swap.h
> > index cee108c..0428e4c 100644
> > --- a/include/linux/swap.h
> > +++ b/include/linux/swap.h
> > @@ -308,6 +308,7 @@ extern void lru_add_drain_cpu(int cpu);
> >  extern void lru_add_drain_all(void);
> >  extern void rotate_reclaimable_page(struct page *page);
> >  extern void deactivate_file_page(struct page *page);
> > +extern void deactivate_page(struct page *page);
> >  extern void swap_setup(void);
> > 
> >  extern void add_page_to_unevictable_list(struct page *page);
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index ebe692e..22e8f0c 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -340,6 +340,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
> > long addr,
> > ptent = pte_mkold(ptent);
> > ptent = pte_mkclean(ptent);
> > set_pte_at(mm, addr, pte, ptent);
> > +   if (PageActive(page))
> > +   deactivate_page(page);
> > tlb_remove_tlb_entry(tlb, pte, addr);
> > }
> 
> I think this place should be changed like this:
>   +   if (!page_referenced(page, false, NULL, NULL, NULL) && 
> PageActive(page))
>   +   deactivate_page(page);
> Because we don't know if other processes are reference this page,
> If it is true, don't need deactivate this page.

The page_referenced is too much heavy operation to do it
in madvise_free fast path.
If other processes(parent or child) referenced the page,
shrink_page_list in slow path could filter it out and
activates the page.

In addition, shared case for anon pages happens by fork mostly
so we could expect child will do exec soonish in many cases.

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


TOI: introducing Split Lists hybrids of doubly linked lists within the Linux Kernel

2015-03-10 Thread Mitchell Erblich

Please note that this proposal is from this engineer and not from the company 
he works for.

This SHOULD also fulfills any legal notification of work done, but not 
submitted to the Linux Kernel.


Transfer of Information  : Introduction to what I term as split lists
——-

Double link list support has been available for decades within 
UNIX OSs.  There is a perceived perception that double link list support is 
slow because of walking the list from the head or from the tail. This proposal 
suggests a first a simple change to the logic to average an immediate 
approximate 2x performance improvement with creation of ordered double link 
lists. This achievement is for all operations of insertions, deletions, and 
searches of elements within the link list.  There are increasing difficulty 
versions that benefit only as the size of the link list significantly 
increases. The size of the base link list structure increases and additional 
checks are necessary as to where the start of the search is to begin.   The 
suggested implementation follow the syscall(system call) layouts, with a 
split1_ll_xxx, split2_ll_xxx, split3_ll_xxx, where xxx are the operations on 
the split link lists  and so on.  Only the first two will be mentioned in this 
TOI, but the logic starts being fairly simple and should end with the well 
known skip list functionality. The functionality is proposed to first be 
incorporated into a new header file within the linux kernel with just the 1st 
order split list support. Later support can be added to support the 2nd order 
split list and finally a skip list with dynamic / run time support to modify 
the list conversion from a split linked list to then the skip linked list.

To keep the terminology simple, split1_ll will be known as just 
a split link list. The simplest performance change to an ordered doubly link 
list is to just search half the list. Yes, if it an ordered doubly linked list 
and the value that we search is fairly large, and we have increasing values 
from head to tail, with the doubly link list we can search from the tail. 
However, the distribution of values within the list that we search can be 
sparse and not equally distributed, thus the value MAY still be closer to the 
head. Thus we can a level of additional guarantee by increasing the size of the 
structure and adding additional logic. 

Thus, for the simplest split linked list is  basically achieved 
by identifying a middle and then adding support to additionally search from the 
middle to the head or middle to the tail. This is of course additional to the 
original searching from the head or from the tail. I term this new ordered 
double link list as a split doubly link list. There is an implied assumption 
that almost100% of the elements to be added are not just increasing/decreasing, 
 else just default and add at the tail or head and walk the list for the very 
few exceptional unordered items.  This will in general allow us to search 1/2 
of the ordered link list and thus a major performance in a guarantee in walking 
at most just 1/2 of the items. This was originally done by this engineer for a 
different UNIX OS many years ago.

Operations are based on first searching for the location for the new 
element to be added or deleted, thus the approximate maximum list size is 
important to be known before the set of functions are called. In the past the 
list was assumed to be anywhere from 64 to 256 elements in size. If one is 
aware that this list could reach an approximate 4,096 elements in size, then a 
more complicated version of the split list SHOULD be used to keep major 
performance improvements. To support this I add additional checks at the 1/4 
and 3/4 points to the list and allows the searching to only walk a maximum of 
1/4 of the number of elements in the double split list, with 4 sections.

This split ordered link list could also be implemented with 
synchronization for each of the separate sections of the split list to minimize 
contention for the list.  The determination of how to find the middle in the 
simplest split list is based on the well known skip list algorithm. On every 
two insertions into the skip list, the middle is adjusted if both insertions 
fall on 1st or 2nd half of the list. If they are inserted into the first half, 
then the middle moves one position to the head. The reverse is true for every 
two deletions from the 1st half. The movement of the middle comparison item 
follows simple logic.

If the number of elements are expected or grown beyond say 16k elements 
, then it makes sense to scale the split list to an actual skip list. The skip 
list and the split list will stay balanced, without additional overhead and 
will not decrease in performance as if some periodic order of the elements are 
inserted into the lists. Trees will need rebalancing, rotations, etc and thus 
are not being included in 

Re: [RFC V2 04/12] i2c: opal: make use of the new infrastructure for quirks

2015-03-10 Thread Neelesh Gupta


On 03/11/2015 04:42 AM, Benjamin Herrenschmidt wrote:

On Tue, 2015-03-10 at 22:43 +0530, Neelesh Gupta wrote:

I tested the i2c opal driver after updating the patch as below.
Basically I think we can also support write-then-{read/write}
for the number of messages = 2.
Ben, any issues if we support both write plus read/write in the
opal driver ?

Nope, in fact it's a good idea, I found myself having to expoes such
an interface to some userspace tool of ours.

However...


diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
index 16f90b1..85412ba 100644
--- a/drivers/i2c/busses/i2c-opal.c
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -104,18 +104,8 @@ static int i2c_opal_master_xfer(struct i2c_adapter *adap, 
struct i2c_msg *msgs,
req.buffer_ra = cpu_to_be64(__pa(msgs[0].buf));
break;
case 2:
-   /* For two messages, we basically support only simple
-* smbus transactions of a write plus a read. We might
-* want to allow also two writes but we'd have to bounce
-* the data into a single buffer.
-*/
-   if ((msgs[0].flags & I2C_M_RD) || !(msgs[1].flags & I2C_M_RD))
-   return -EOPNOTSUPP;

Don't we still want to enforce that the first message is a write ?
Somebody may not be looking at the quirks...


-   if (msgs[0].len > 4)
-   return -EOPNOTSUPP;

And that the len is supported...


-   if (msgs[0].addr != msgs[1].addr)
-   return -EOPNOTSUPP;

Same...

Ie, the quirk indicates to the callers what we support, but we should
still check that we aren't called with something that doesn't match.


Quirk *also* return error to the user if any of the conditions mismatch with
what we have indicated through the quriks structure...

I think we can't land up here by-passing the check for quirks so above 
checks

are duplicated here..

Neelesh.




-   req.type = OPAL_I2C_SM_READ;
+   req.type = (msgs[1].flags & I2C_M_RD) ?
+   OPAL_I2C_SM_READ : OPAL_I2C_SM_WRITE;
req.addr = cpu_to_be16(msgs[0].addr);
req.subaddr_sz = msgs[0].len;
for (i = 0; i < msgs[0].len; i++)
@@ -210,6 +200,11 @@ static const struct i2c_algorithm i2c_opal_algo = {
.functionality  = i2c_opal_func,
   };

+static struct i2c_adapter_quirks i2c_opal_quirks = {
+   .flags = I2C_AQ_COMB | I2C_AQ_COMB_WRITE_FIRST | I2C_AQ_COMB_SAME_ADDR,
+   .max_comb_1st_msg_len = 4,
+};
+
   static int i2c_opal_probe(struct platform_device *pdev)
   {
struct i2c_adapter  *adapter;
@@ -232,6 +227,7 @@ static int i2c_opal_probe(struct platform_device *pdev)

adapter->algo = _opal_algo;
adapter->algo_data = (void *)(unsigned long)opal_id;
+   adapter->quirks = _opal_quirks;
adapter->dev.parent = >dev;
adapter->dev.of_node = of_node_get(pdev->dev.of_node);
pname = of_get_property(pdev->dev.of_node, "ibm,port-name", NULL);



On 02/25/2015 09:31 PM, Wolfram Sang wrote:

From: Wolfram Sang 

Signed-off-by: Wolfram Sang 
---
   drivers/i2c/busses/i2c-opal.c | 22 +++---
   1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/busses/i2c-opal.c b/drivers/i2c/busses/i2c-opal.c
index 16f90b1a750894..b2788ecad5b3cb 100644
--- a/drivers/i2c/busses/i2c-opal.c
+++ b/drivers/i2c/busses/i2c-opal.c
@@ -104,17 +104,6 @@ static int i2c_opal_master_xfer(struct i2c_adapter *adap, 
struct i2c_msg *msgs,
req.buffer_ra = cpu_to_be64(__pa(msgs[0].buf));
break;
case 2:
-   /* For two messages, we basically support only simple
-* smbus transactions of a write plus a read. We might
-* want to allow also two writes but we'd have to bounce
-* the data into a single buffer.
-*/
-   if ((msgs[0].flags & I2C_M_RD) || !(msgs[1].flags & I2C_M_RD))
-   return -EOPNOTSUPP;
-   if (msgs[0].len > 4)
-   return -EOPNOTSUPP;
-   if (msgs[0].addr != msgs[1].addr)
-   return -EOPNOTSUPP;
req.type = OPAL_I2C_SM_READ;
req.addr = cpu_to_be16(msgs[0].addr);
req.subaddr_sz = msgs[0].len;
@@ -210,6 +199,16 @@ static const struct i2c_algorithm i2c_opal_algo = {
.functionality  = i2c_opal_func,
   };
   
+/* For two messages, we basically support only simple

+ * smbus transactions of a write plus a read. We might
+ * want to allow also two writes but we'd have to bounce
+ * the data into a single buffer.
+ */
+static struct i2c_adapter_quirks i2c_opal_quirks = {
+   .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+   .max_comb_1st_msg_len = 4,
+};
+
   static int i2c_opal_probe(struct platform_device *pdev)
   {
struct 

[PATCH v2 man-pages] bpf.2: new page documenting bpf(2)

2015-03-10 Thread Alexei Starovoitov
Signed-off-by: Alexei Starovoitov 
---
 man2/bpf.2 |  630 
 1 file changed, 630 insertions(+)
 create mode 100644 man2/bpf.2

diff --git a/man2/bpf.2 b/man2/bpf.2
new file mode 100644
index 000..a605489
--- /dev/null
+++ b/man2/bpf.2
@@ -0,0 +1,630 @@
+.\" Copyright (C) 2015 Alexei Starovoitov 
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date.  The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein.  The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.TH BPF 2 2015-03-10 "Linux" "Linux Programmer's Manual"
+.SH NAME
+bpf - perform a command on an extended BPF map or program
+.SH SYNOPSIS
+.nf
+.B #include 
+.sp
+.BI "int bpf(int cmd, union bpf_attr *attr, unsigned int size);
+
+.SH DESCRIPTION
+.BR bpf()
+syscall is a multiplexor for a range of different operations on extended BPF
+which can be characterized as "universal in-kernel virtual machine".
+Extended BPF (or eBPF) is similar to the original Berkeley Packet Filter
+(or "classic BPF") used to filter network packets. Both statically analyze
+the programs before loading them into the kernel to ensure that they cannot
+harm the running system.
+.P
+eBPF extends classic BPF in multiple ways including the ability to call
+in-kernel helper functions and access shared data structures like BPF maps.
+The programs can be written in a restricted C that is compiled into
+eBPF bytecode and executed on the in-kernel virtual machine or JITed into
+native code.
+.SS Extended BPF Design/Architecture
+.P
+BPF maps are a generic data structure for storage of different data types.
+A user process can create multiple maps (with key/value-pairs being
+opaque bytes of data) and access them via file descriptor.
+BPF programs can access maps from inside the kernel in parallel.
+It's up to the user process and BPF program to decide what they store
+inside maps.
+.P
+BPF programs are similar to kernel modules. They are loaded by the user
+process and automatically unloaded when the process exits.
+Each BPF program is a set of instructions that is safe to run until
+its completion. The BPF verifier statically determines that the program
+terminates and is safe to execute. During
+verification the program takes hold of maps that it intends to use,
+so selected maps cannot be removed until the program is unloaded. The program
+can be attached to different events. These events can be packets, tracing
+events and other types that may be added in the future. A new event triggers
+execution of the program which may store information about the event in the 
maps.
+Beyond storing data the programs may call into in-kernel helper functions.
+The same program can be attached to multiple events and different programs can
+access the same map:
+.nf
+  tracing tracing tracing packet packet
+  event A event B event C on eth0on eth1
+   | |  |   |  |
+   | |  |   |  |
+   --> tracing <--  tracing   socket socket
+prog_1   prog_2   prog_3 prog_4
+|  |   ||
+ |---  -|  |---|   map_3
+   map_1   map_2
+.fi
+.SS Syscall Arguments
+.B bpf()
+syscall operation is determined by
+.IR cmd
+which can be one of the following:
+.TP
+.B BPF_MAP_CREATE
+Create a map with the given type and attributes and return map FD
+.TP
+.B BPF_MAP_LOOKUP_ELEM
+Lookup element by key in a given map and return its value
+.TP
+.B BPF_MAP_UPDATE_ELEM
+Create or update element (key/value pair) in a given map
+.TP
+.B BPF_MAP_DELETE_ELEM
+Lookup and delete element by key in a given map
+.TP
+.B BPF_MAP_GET_NEXT_KEY
+Lookup element by key in a given map and return key of next element
+.TP
+.B BPF_PROG_LOAD
+Verify and load BPF program
+.TP
+.B attr
+is a pointer to a union of type bpf_attr as defined below.
+.TP
+.B size
+is the size of the union.
+.P
+.nf
+union bpf_attr {
+struct { /* anonymous struct used by 

Re: [PATCH 4/5] Documentation: rename of_selftest.txt to of_unittest.txt

2015-03-10 Thread Gaurav Minocha
Please use -M flag while sending rename patch, as mentioned in my other mail.

On Tue, Mar 10, 2015 at 8:37 PM, Wang Long  wrote:
> Since the test of the devicetree's OF api use unittest as
> its name. so we should rename of_selftest.txt to of_unittest.txt.
>
> Signed-off-by: Wang Long 
> ---
>  Documentation/devicetree/of_selftest.txt | 198 
> ---
>  Documentation/devicetree/of_unittest.txt | 198 
> +++
>  2 files changed, 198 insertions(+), 198 deletions(-)
>  delete mode 100644 Documentation/devicetree/of_selftest.txt
>  create mode 100644 Documentation/devicetree/of_unittest.txt
>
> diff --git a/Documentation/devicetree/of_selftest.txt 
> b/Documentation/devicetree/of_selftest.txt
> deleted file mode 100644
> index d79a6bc..000
> --- a/Documentation/devicetree/of_selftest.txt
> +++ /dev/null
> @@ -1,198 +0,0 @@
> -Open Firmware Device Tree Unittest
> ---
> -
> -Author: Gaurav Minocha 
> -
> -1. Introduction
> -
> -This document explains how the test data required for executing OF unittest
> -is attached to the live tree dynamically, independent of the machine's
> -architecture.
> -
> -It is recommended to read the following documents before moving ahead.
> -
> -[1] Documentation/devicetree/usage-model.txt
> -[2] http://www.devicetree.org/Device_Tree_Usage
> -
> -OF Selftest has been designed to test the interface (include/linux/of.h)
> -provided to device driver developers to fetch the device information..etc.
> -from the unflattened device tree data structure. This interface is used by
> -most of the device drivers in various use cases.
> -
> -
> -2. Test-data
> -
> -The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
> -the test data required for executing the unit tests automated in
> -drivers/of/unittest.c. Currently, following Device Tree Source Include files
> -(.dtsi) are included in testcases.dts:
> -
> -drivers/of/unittest-data/tests-interrupts.dtsi
> -drivers/of/unittest-data/tests-platform.dtsi
> -drivers/of/unittest-data/tests-phandle.dtsi
> -drivers/of/unittest-data/tests-match.dtsi
> -drivers/of/unittest-data/tests-overlay.dtsi
> -
> -When the kernel is build with OF_SELFTEST enabled, then the following make 
> rule
> -
> -$(obj)/%.dtb: $(src)/%.dts FORCE
> -   $(call if_changed_dep, dtc)
> -
> -is used to compile the DT source file (testcases.dts) into a binary blob
> -(testcases.dtb), also referred as flattened DT.
> -
> -After that, using the following rule the binary blob above is wrapped as an
> -assembly file (testcases.dtb.S).
> -
> -$(obj)/%.dtb.S: $(obj)/%.dtb
> -   $(call cmd, dt_S_dtb)
> -
> -The assembly file is compiled into an object file (testcases.dtb.o), and is
> -linked into the kernel image.
> -
> -
> -2.1. Adding the test data
> -
> -Un-flattened device tree structure:
> -
> -Un-flattened device tree consists of connected device_node(s) in form of a 
> tree
> -structure described below.
> -
> -// following struct members are used to construct the tree
> -struct device_node {
> -...
> -struct  device_node *parent;
> -struct  device_node *child;
> -struct  device_node *sibling;
> -...
> - };
> -
> -Figure 1, describes a generic structure of machine's un-flattened device tree
> -considering only child and sibling pointers. There exists another pointer,
> -*parent, that is used to traverse the tree in the reverse direction. So, at
> -a particular level the child node and all the sibling nodes will have a 
> parent
> -pointer pointing to a common node (e.g. child1, sibling2, sibling3, 
> sibling4's
> -parent points to root node)
> -
> -root ('/')
> -   |
> -child1 -> sibling2 -> sibling3 -> sibling4 -> null
> -   | |   |   |
> -   | |   |  null
> -   | |   |
> -   | |child31 -> sibling32 -> null
> -   | |   |  |
> -   | |  null   null
> -   | |
> -   |  child21 -> sibling22 -> sibling23 -> null
> -   | |  ||
> -   |null   null null
> -   |
> -child11 -> sibling12 -> sibling13 -> sibling14 -> null
> -   |   |   ||
> -   |   |   |   null
> -   |   |   |
> -  nullnull   child131 -> null
> -   |
> -  null
> -
> -Figure 1: Generic structure of un-flattened device tree
> -
> -
> -Before executing OF unittest, it is required to attach the test data to
> -machine's device tree (if present). So, when unittest_data_add() is called,
> -at first it reads the flattened device tree data linked into the kernel image
> -via the following kernel symbols:
> -
> -__dtb_testcases_begin - address marking the start of test data blob
> -__dtb_testcases_end   - address marking the end of test data blob
> -
> -Secondly, it calls 

[PATCH v6 tip 2/8] tracing: attach BPF programs to kprobes

2015-03-10 Thread Alexei Starovoitov
User interface:
struct perf_event_attr attr = {.type = PERF_TYPE_TRACEPOINT, .config = 
event_id, ...};
event_fd = perf_event_open(,...);
ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);

prog_fd is a file descriptor associated with BPF program previously loaded.
event_id is an ID of created kprobe

close(event_fd) - automatically detaches BPF program from it

BPF programs can call in-kernel helper functions to:
- lookup/update/delete elements in maps
- probe_read - wraper of probe_kernel_read() used to access any kernel
  data structures

BPF programs receive 'struct pt_regs *' as an input
('struct pt_regs' is architecture dependent)

Note, kprobes are _not_ a stable kernel ABI, so bpf programs attached to
kprobes must be recompiled for every kernel version and user must supply correct
LINUX_VERSION_CODE in attr.kern_version during bpf_prog_load() call.

Signed-off-by: Alexei Starovoitov 
---
 include/linux/ftrace_event.h|   14 +
 include/uapi/linux/bpf.h|3 +
 include/uapi/linux/perf_event.h |1 +
 kernel/bpf/syscall.c|7 ++-
 kernel/events/core.c|   59 +++
 kernel/trace/Makefile   |1 +
 kernel/trace/bpf_trace.c|  119 +++
 kernel/trace/trace_kprobe.c |   10 +++-
 8 files changed, 212 insertions(+), 2 deletions(-)
 create mode 100644 kernel/trace/bpf_trace.c

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index c674ee8f7fca..0aa535bc9f05 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -13,6 +13,7 @@ struct trace_array;
 struct trace_buffer;
 struct tracer;
 struct dentry;
+struct bpf_prog;
 
 struct trace_print_flags {
unsigned long   mask;
@@ -252,6 +253,7 @@ enum {
TRACE_EVENT_FL_WAS_ENABLED_BIT,
TRACE_EVENT_FL_USE_CALL_FILTER_BIT,
TRACE_EVENT_FL_TRACEPOINT_BIT,
+   TRACE_EVENT_FL_KPROBE_BIT,
 };
 
 /*
@@ -265,6 +267,7 @@ enum {
  * it is best to clear the buffers that used it).
  *  USE_CALL_FILTER - For ftrace internal events, don't use file filter
  *  TRACEPOINT- Event is a tracepoint
+ *  KPROBE- Event is a kprobe
  */
 enum {
TRACE_EVENT_FL_FILTERED = (1 << TRACE_EVENT_FL_FILTERED_BIT),
@@ -274,6 +277,7 @@ enum {
TRACE_EVENT_FL_WAS_ENABLED  = (1 << TRACE_EVENT_FL_WAS_ENABLED_BIT),
TRACE_EVENT_FL_USE_CALL_FILTER  = (1 << 
TRACE_EVENT_FL_USE_CALL_FILTER_BIT),
TRACE_EVENT_FL_TRACEPOINT   = (1 << TRACE_EVENT_FL_TRACEPOINT_BIT),
+   TRACE_EVENT_FL_KPROBE   = (1 << TRACE_EVENT_FL_KPROBE_BIT),
 };
 
 struct ftrace_event_call {
@@ -303,6 +307,7 @@ struct ftrace_event_call {
 #ifdef CONFIG_PERF_EVENTS
int perf_refcount;
struct hlist_head __percpu  *perf_events;
+   struct bpf_prog *prog;
 
int (*perf_perm)(struct ftrace_event_call *,
 struct perf_event *);
@@ -548,6 +553,15 @@ event_trigger_unlock_commit_regs(struct ftrace_event_file 
*file,
event_triggers_post_call(file, tt);
 }
 
+#ifdef CONFIG_BPF_SYSCALL
+unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx);
+#else
+static inline unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx)
+{
+   return 1;
+}
+#endif
+
 enum {
FILTER_OTHER = 0,
FILTER_STATIC_STRING,
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 45da7ec7d274..4486d36d2e9e 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -118,6 +118,7 @@ enum bpf_map_type {
 enum bpf_prog_type {
BPF_PROG_TYPE_UNSPEC,
BPF_PROG_TYPE_SOCKET_FILTER,
+   BPF_PROG_TYPE_KPROBE,
 };
 
 /* flags for BPF_MAP_UPDATE_ELEM command */
@@ -151,6 +152,7 @@ union bpf_attr {
__u32   log_level;  /* verbosity level of verifier 
*/
__u32   log_size;   /* size of user buffer */
__aligned_u64   log_buf;/* user supplied buffer */
+   __u32   kern_version;   /* checked when type=kprobe */
};
 } __attribute__((aligned(8)));
 
@@ -162,6 +164,7 @@ enum bpf_func_id {
BPF_FUNC_map_lookup_elem, /* void *map_lookup_elem(, ) */
BPF_FUNC_map_update_elem, /* int map_update_elem(, , , 
flags) */
BPF_FUNC_map_delete_elem, /* int map_delete_elem(, ) */
+   BPF_FUNC_probe_read,  /* int bpf_probe_read(void *dst, int size, 
void *src) */
__BPF_FUNC_MAX_ID,
 };
 
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 3c8b45de57ec..ad4dade2a502 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -382,6 +382,7 @@ struct perf_event_attr {
 #define PERF_EVENT_IOC_SET_OUTPUT  _IO ('$', 5)
 #define PERF_EVENT_IOC_SET_FILTER  _IOW('$', 6, char *)
 #define PERF_EVENT_IOC_ID  _IOR('$', 7, __u64 

[PATCH v6 tip 5/8] samples: bpf: simple non-portable kprobe filter example

2015-03-10 Thread Alexei Starovoitov
tracex1_kern.c - C program compiled into BPF.
It attaches to kprobe:netif_receive_skb
When skb->dev->name == "lo", it prints sample debug message into trace_pipe
via bpf_trace_printk() helper function.

tracex1_user.c - corresponding user space component that:
- loads bpf program via bpf() syscall
- opens kprobes:netif_receive_skb event via perf_event_open() syscall
- attaches the program to event via ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, 
prog_fd);
- prints from trace_pipe

Note, this bpf program is completely non-portable. It must be recompiled
with current kernel headers. kprobe is not a stable ABI and bpf+kprobe scripts
may stop working any time.

bpf verifier will detect that it's using bpf_trace_printk() and kernel will
print warning banner:
** trace_printk() being used. Allocating extra memory.  **
**  **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use.   **

bpf_trace_printk() should be used for debugging of bpf program only.

Usage:
$ sudo tracex1
ping-19826 [000] d.s2 63103.382648: : skb 880466b1ca00 len 84
ping-19826 [000] d.s2 63103.382684: : skb 880466b1d300 len 84

ping-19826 [000] d.s2 63104.382533: : skb 880466b1ca00 len 84
ping-19826 [000] d.s2 63104.382594: : skb 880466b1d300 len 84

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/Makefile|4 ++
 samples/bpf/bpf_helpers.h   |6 +++
 samples/bpf/bpf_load.c  |  125 ---
 samples/bpf/bpf_load.h  |3 ++
 samples/bpf/libbpf.c|   14 -
 samples/bpf/libbpf.h|5 +-
 samples/bpf/sock_example.c  |2 +-
 samples/bpf/test_verifier.c |2 +-
 samples/bpf/tracex1_kern.c  |   50 +
 samples/bpf/tracex1_user.c  |   25 +
 10 files changed, 224 insertions(+), 12 deletions(-)
 create mode 100644 samples/bpf/tracex1_kern.c
 create mode 100644 samples/bpf/tracex1_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index b5b3600dcdf5..51f6f01e5a3a 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -6,23 +6,27 @@ hostprogs-y := test_verifier test_maps
 hostprogs-y += sock_example
 hostprogs-y += sockex1
 hostprogs-y += sockex2
+hostprogs-y += tracex1
 
 test_verifier-objs := test_verifier.o libbpf.o
 test_maps-objs := test_maps.o libbpf.o
 sock_example-objs := sock_example.o libbpf.o
 sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
 sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
+tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
 always += sockex1_kern.o
 always += sockex2_kern.o
+always += tracex1_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 
 HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
 HOSTLOADLIBES_sockex1 += -lelf
 HOSTLOADLIBES_sockex2 += -lelf
+HOSTLOADLIBES_tracex1 += -lelf
 
 # point this to your LLVM backend with bpf support
 LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index ca0333146006..1c872bcf5a80 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -15,6 +15,12 @@ static int (*bpf_map_update_elem)(void *map, void *key, void 
*value,
(void *) BPF_FUNC_map_update_elem;
 static int (*bpf_map_delete_elem)(void *map, void *key) =
(void *) BPF_FUNC_map_delete_elem;
+static int (*bpf_probe_read)(void *dst, int size, void *unsafe_ptr) =
+   (void *) BPF_FUNC_probe_read;
+static unsigned long long (*bpf_ktime_get_ns)(void) =
+   (void *) BPF_FUNC_ktime_get_ns;
+static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
+   (void *) BPF_FUNC_trace_printk;
 
 /* llvm builtin functions that eBPF C program may use to
  * emit BPF_LD_ABS and BPF_LD_IND instructions
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 1831d236382b..95c106e4bcdb 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -8,29 +8,70 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "libbpf.h"
 #include "bpf_helpers.h"
 #include "bpf_load.h"
 
+#define DEBUGFS "/sys/kernel/debug/tracing/"
+
 static char license[128];
+static int kern_version;
 static bool processed_sec[128];
 int map_fd[MAX_MAPS];
 int prog_fd[MAX_PROGS];
+int event_fd[MAX_PROGS];
 int prog_cnt;
 
 static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
 {
-   int fd;
bool is_socket = strncmp(event, "socket", 6) == 0;
-
-   if (!is_socket)
-   /* tracing events tbd */
+   bool is_kprobe = strncmp(event, "kprobe/", 7) == 0;
+   bool is_kretprobe = strncmp(event, "kretprobe/", 10) == 0;
+   enum bpf_prog_type prog_type;
+   char buf[256];
+   int fd, efd, err, id;
+   

[PATCH v6 tip 4/8] tracing: allow BPF programs to call bpf_trace_printk()

2015-03-10 Thread Alexei Starovoitov
Debugging of BPF programs needs some form of printk from the program,
so let programs call limited trace_printk() with %d %u %x %p modifiers only.

Similar to kernel modules, during program load verifier checks whether program
is calling bpf_trace_printk() and if so, kernel allocates trace_printk buffers
and emits big 'this is debug only' banner.

Signed-off-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h |1 +
 kernel/trace/bpf_trace.c |   68 ++
 2 files changed, 69 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 101e509d1001..4095f3d9a716 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -166,6 +166,7 @@ enum bpf_func_id {
BPF_FUNC_map_delete_elem, /* int map_delete_elem(, ) */
BPF_FUNC_probe_read,  /* int bpf_probe_read(void *dst, int size, 
void *src) */
BPF_FUNC_ktime_get_ns,/* u64 bpf_ktime_get_ns(void) */
+   BPF_FUNC_trace_printk,/* int bpf_trace_printk(const char *fmt, int 
fmt_size, ...) */
__BPF_FUNC_MAX_ID,
 };
 
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index ee7c2c629e75..367235d8576b 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -62,6 +62,60 @@ static u64 bpf_ktime_get_ns(u64 r1, u64 r2, u64 r3, u64 r4, 
u64 r5)
return ktime_get_mono_fast_ns();
 }
 
+/* limited trace_printk()
+ * only %d %u %x %ld %lu %lx %lld %llu %llx %p conversion specifiers allowed
+ */
+static u64 bpf_trace_printk(u64 r1, u64 fmt_size, u64 r3, u64 r4, u64 r5)
+{
+   char *fmt = (char *) (long) r1;
+   int fmt_cnt = 0;
+   bool mod_l[3] = {};
+   int i;
+
+   /* bpf_check() guarantees that fmt points to bpf program stack and
+* fmt_size bytes of it were initialized by bpf program
+*/
+   if (fmt[fmt_size - 1] != 0)
+   return -EINVAL;
+
+   /* check format string for allowed specifiers */
+   for (i = 0; i < fmt_size; i++)
+   if (fmt[i] == '%') {
+   if (fmt_cnt >= 3)
+   return -EINVAL;
+   i++;
+   if (i >= fmt_size)
+   return -EINVAL;
+
+   if (fmt[i] == 'l') {
+   mod_l[fmt_cnt] = true;
+   i++;
+   if (i >= fmt_size)
+   return -EINVAL;
+   } else if (fmt[i] == 'p') {
+   mod_l[fmt_cnt] = true;
+   fmt_cnt++;
+   continue;
+   }
+
+   if (fmt[i] == 'l') {
+   mod_l[fmt_cnt] = true;
+   i++;
+   if (i >= fmt_size)
+   return -EINVAL;
+   }
+
+   if (fmt[i] != 'd' && fmt[i] != 'u' && fmt[i] != 'x')
+   return -EINVAL;
+   fmt_cnt++;
+   }
+
+   return __trace_printk(1/* fake ip will not be printed */, fmt,
+ mod_l[0] ? r3 : (u32) r3,
+ mod_l[1] ? r4 : (u32) r4,
+ mod_l[2] ? r5 : (u32) r5);
+}
+
 static struct bpf_func_proto kprobe_prog_funcs[] = {
[BPF_FUNC_probe_read] = {
.func = bpf_probe_read,
@@ -76,6 +130,13 @@ static struct bpf_func_proto kprobe_prog_funcs[] = {
.gpl_only = true,
.ret_type = RET_INTEGER,
},
+   [BPF_FUNC_trace_printk] = {
+   .func = bpf_trace_printk,
+   .gpl_only = true,
+   .ret_type = RET_INTEGER,
+   .arg1_type = ARG_PTR_TO_STACK,
+   .arg2_type = ARG_CONST_STACK_SIZE,
+   },
 };
 
 static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id 
func_id)
@@ -90,6 +151,13 @@ static const struct bpf_func_proto 
*kprobe_prog_func_proto(enum bpf_func_id func
default:
if (func_id < 0 || func_id >= ARRAY_SIZE(kprobe_prog_funcs))
return NULL;
+
+   if (func_id == BPF_FUNC_trace_printk)
+   /* this program might be calling bpf_trace_printk,
+* so allocate per-cpu printk buffers
+*/
+   trace_printk_init_buffers();
+
return _prog_funcs[func_id];
}
 }
-- 
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 v6 tip 1/8] bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs

2015-03-10 Thread Alexei Starovoitov
From: Daniel Borkmann 

Socket filter code and other subsystems with upcoming eBPF support should
not need to deal with the fact that we have CONFIG_BPF_SYSCALL defined or
not.

Having the bpf syscall as a config option is a nice thing and I'd expect
it to stay that way for expert users (I presume one day the default setting
of it might change, though), but code making use of it should not care if
it's actually enabled or not.

Instead, hide this via header files and let the rest deal with it.

Signed-off-by: Daniel Borkmann 
Signed-off-by: Alexei Starovoitov 
---
 include/linux/bpf.h |   20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index bbfceb756452..c2e21113ecc0 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -113,8 +113,6 @@ struct bpf_prog_type_list {
enum bpf_prog_type type;
 };
 
-void bpf_register_prog_type(struct bpf_prog_type_list *tl);
-
 struct bpf_prog;
 
 struct bpf_prog_aux {
@@ -129,11 +127,25 @@ struct bpf_prog_aux {
 };
 
 #ifdef CONFIG_BPF_SYSCALL
+void bpf_register_prog_type(struct bpf_prog_type_list *tl);
+
 void bpf_prog_put(struct bpf_prog *prog);
+struct bpf_prog *bpf_prog_get(u32 ufd);
 #else
-static inline void bpf_prog_put(struct bpf_prog *prog) {}
+static inline void bpf_register_prog_type(struct bpf_prog_type_list *tl)
+{
+}
+
+static inline struct bpf_prog *bpf_prog_get(u32 ufd)
+{
+   return ERR_PTR(-EOPNOTSUPP);
+}
+
+static inline void bpf_prog_put(struct bpf_prog *prog)
+{
+}
 #endif
-struct bpf_prog *bpf_prog_get(u32 ufd);
+
 /* verify correctness of eBPF program */
 int bpf_check(struct bpf_prog *fp, union bpf_attr *attr);
 
-- 
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 v6 tip 6/8] samples: bpf: counting example for kfree_skb and write syscall

2015-03-10 Thread Alexei Starovoitov
this example has two probes in one C file that attach to different kprove events
and use two different maps.

1st probe is x64 specific equivalent of dropmon. It attaches to kfree_skb,
retrevies 'ip' address of kfree_skb() caller and counts number of packet drops
at that 'ip' address. User space prints 'location - count' map every second.

2nd probe attaches to kprobe:sys_write and computes a histogram of different
write sizes

Usage:
$ sudo tracex2
location 0x81695995 count 1
location 0x816d0da9 count 2

location 0x81695995 count 2
location 0x816d0da9 count 2

location 0x81695995 count 3
location 0x816d0da9 count 2

557145+0 records in
557145+0 records out
285258240 bytes (285 MB) copied, 1.02379 s, 279 MB/s
   syscall write() stats
 byte_size   : count distribution
   1 -> 1: 3|  |
   2 -> 3: 0|  |
   4 -> 7: 0|  |
   8 -> 15   : 0|  |
  16 -> 31   : 2|  |
  32 -> 63   : 3|  |
  64 -> 127  : 1|  |
 128 -> 255  : 1|  |
 256 -> 511  : 0|  |
 512 -> 1023 : 1118968  |* |

Ctrl-C at any time. Kernel will auto cleanup maps and programs

$ addr2line -ape ./bld_x64/vmlinux 0x81695995 0x816d0da9
0x81695995: ./bld_x64/../net/ipv4/icmp.c:1038
0x816d0da9: ./bld_x64/../net/unix/af_unix.c:1231

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/Makefile   |4 ++
 samples/bpf/tracex2_kern.c |   86 +++
 samples/bpf/tracex2_user.c |   95 
 3 files changed, 185 insertions(+)
 create mode 100644 samples/bpf/tracex2_kern.c
 create mode 100644 samples/bpf/tracex2_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 51f6f01e5a3a..6dd272143733 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -7,6 +7,7 @@ hostprogs-y += sock_example
 hostprogs-y += sockex1
 hostprogs-y += sockex2
 hostprogs-y += tracex1
+hostprogs-y += tracex2
 
 test_verifier-objs := test_verifier.o libbpf.o
 test_maps-objs := test_maps.o libbpf.o
@@ -14,12 +15,14 @@ sock_example-objs := sock_example.o libbpf.o
 sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
 sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
 tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
+tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
 always += sockex1_kern.o
 always += sockex2_kern.o
 always += tracex1_kern.o
+always += tracex2_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 
@@ -27,6 +30,7 @@ HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include 
-Wno-unused-variable
 HOSTLOADLIBES_sockex1 += -lelf
 HOSTLOADLIBES_sockex2 += -lelf
 HOSTLOADLIBES_tracex1 += -lelf
+HOSTLOADLIBES_tracex2 += -lelf
 
 # point this to your LLVM backend with bpf support
 LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex2_kern.c b/samples/bpf/tracex2_kern.c
new file mode 100644
index ..334348335795
--- /dev/null
+++ b/samples/bpf/tracex2_kern.c
@@ -0,0 +1,86 @@
+/* Copyright (c) 2013-2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") my_map = {
+   .type = BPF_MAP_TYPE_HASH,
+   .key_size = sizeof(long),
+   .value_size = sizeof(long),
+   .max_entries = 1024,
+};
+
+/* kprobe is NOT a stable ABI
+ * This bpf+kprobe example can stop working any time.
+ */
+SEC("kprobe/kfree_skb")
+int bpf_prog2(struct pt_regs *ctx)
+{
+   long loc = 0;
+   long init_val = 1;
+   long *value;
+
+   /* x64 specific: read ip of kfree_skb caller.
+* non-portable version of __builtin_return_address(0)
+*/
+   bpf_probe_read(, sizeof(loc), (void *)ctx->sp);
+
+   value = bpf_map_lookup_elem(_map, );
+   if (value)
+   *value += 1;
+   else
+   bpf_map_update_elem(_map, , _val, BPF_ANY);
+   return 0;
+}
+
+static unsigned int log2(unsigned int v)
+{
+   unsigned int r;
+   unsigned int shift;
+
+   r = (v > 0x) << 4; v >>= r;
+   shift = (v > 0xFF) << 3; v >>= shift; r |= shift;
+   shift = (v > 0xF) << 2; v >>= shift; r |= shift;
+   shift = (v > 0x3) << 1; v >>= shift; r 

[PATCH v6 tip 7/8] samples: bpf: IO latency analysis (iosnoop/heatmap)

2015-03-10 Thread Alexei Starovoitov
BPF C program attaches to blk_mq_start_request/blk_update_request kprobe events
to calculate IO latency.
For every completed block IO event it computes the time delta in nsec
and records in a histogram map: map[log10(delta)*10]++
User space reads this histogram map every 2 seconds and prints it as a 'heatmap'
using gray shades of text terminal. Black spaces have many events and white
spaces have very few events. Left most space is the smallest latency, right most
space is the largest latency in the range.

Usage:
$ sudo ./tracex3
and do 'sudo dd if=/dev/sda of=/dev/null' in other terminal.
Observe IO latencies and how different activity (like 'make kernel') affects it.

Similar experiments can be done for network transmit latencies, syscalls, etc

'-t' flag prints the heatmap using normal ascii characters:

$ sudo ./tracex3 -t
  heatmap of IO latency
  # - many events with this latency
- few events
|1us  |10us |100us|1ms  |10ms |100ms|1s   |10s
 *ooo. *O.#.# 221
  .  *# .   # 125
 ..   .o#*..# 55
.  . .  .  .#O  # 37
 .# # 175
   .#*. # 37
  # # 199
  .  . *#*. # 55
   *#..*# 42
  # # 266
  ...***Oo#*OO**o#* .   # 629
  # # 271
  . .#o* o.*o*  # 221
. . o* *#O..# 50

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/Makefile   |4 ++
 samples/bpf/tracex3_kern.c |   89 ++
 samples/bpf/tracex3_user.c |  150 
 3 files changed, 243 insertions(+)
 create mode 100644 samples/bpf/tracex3_kern.c
 create mode 100644 samples/bpf/tracex3_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 6dd272143733..dcd850546d52 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -8,6 +8,7 @@ hostprogs-y += sockex1
 hostprogs-y += sockex2
 hostprogs-y += tracex1
 hostprogs-y += tracex2
+hostprogs-y += tracex3
 
 test_verifier-objs := test_verifier.o libbpf.o
 test_maps-objs := test_maps.o libbpf.o
@@ -16,6 +17,7 @@ sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
 sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
 tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
 tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
+tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
@@ -23,6 +25,7 @@ always += sockex1_kern.o
 always += sockex2_kern.o
 always += tracex1_kern.o
 always += tracex2_kern.o
+always += tracex3_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 
@@ -31,6 +34,7 @@ HOSTLOADLIBES_sockex1 += -lelf
 HOSTLOADLIBES_sockex2 += -lelf
 HOSTLOADLIBES_tracex1 += -lelf
 HOSTLOADLIBES_tracex2 += -lelf
+HOSTLOADLIBES_tracex3 += -lelf
 
 # point this to your LLVM backend with bpf support
 LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex3_kern.c b/samples/bpf/tracex3_kern.c
new file mode 100644
index ..b9d66766f07a
--- /dev/null
+++ b/samples/bpf/tracex3_kern.c
@@ -0,0 +1,89 @@
+/* Copyright (c) 2013-2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") my_map = {
+   .type = BPF_MAP_TYPE_HASH,
+   .key_size = sizeof(long),
+   .value_size = sizeof(u64),
+   .max_entries = 4096,
+};
+
+/* kprobe is NOT a stable ABI
+ * This bpf+kprobe example can stop working any time.
+ */
+SEC("kprobe/blk_mq_start_request")
+int bpf_prog1(struct pt_regs *ctx)
+{
+   long rq = ctx->di;
+   u64 val = bpf_ktime_get_ns();
+
+   bpf_map_update_elem(_map, , , BPF_ANY);
+   return 0;
+}
+
+static unsigned int log2l(unsigned long long n)
+{
+#define S(k) if (n >= (1ull << k)) { i += k; n >>= k; }
+   int i = -(n == 0);
+   S(32); S(16); S(8); S(4); S(2); S(1);
+   return i;
+#undef S
+}
+
+#define SLOTS 100
+
+struct bpf_map_def SEC("maps") lat_map = {
+   .type = BPF_MAP_TYPE_ARRAY,
+   .key_size = sizeof(u32),
+   

[PATCH v6 tip 8/8] samples: bpf: kmem_alloc/free tracker

2015-03-10 Thread Alexei Starovoitov
One bpf program attaches to kmem_cache_alloc_node() and remembers all allocated
objects in the map.
Another program attaches to kmem_cache_free() and deletes corresponding
object from the map.

User space walks the map every second and prints any objects which are
older than 1 second.

Usage:
$ sudo tracex4

Then start few long living processes. The tracex4 will print:

obj 0x880465928000 is 13sec old was allocated at ip 8105dc32
obj 0x88043181c280 is 13sec old was allocated at ip 8105dc32
obj 0x880465848000 is  8sec old was allocated at ip 8105dc32
obj 0x8804338bc280 is 15sec old was allocated at ip 8105dc32

$ addr2line -fispe vmlinux 8105dc32
do_fork at fork.c:1665

As soon as processes exit the memory is reclaimed and tracex4 prints nothing.

Similar experiment can be done with __kmalloc/kfree pair.

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/Makefile   |4 +++
 samples/bpf/tracex4_kern.c |   54 ++
 samples/bpf/tracex4_user.c |   69 
 3 files changed, 127 insertions(+)
 create mode 100644 samples/bpf/tracex4_kern.c
 create mode 100644 samples/bpf/tracex4_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index dcd850546d52..fe98fb226e6e 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -9,6 +9,7 @@ hostprogs-y += sockex2
 hostprogs-y += tracex1
 hostprogs-y += tracex2
 hostprogs-y += tracex3
+hostprogs-y += tracex4
 
 test_verifier-objs := test_verifier.o libbpf.o
 test_maps-objs := test_maps.o libbpf.o
@@ -18,6 +19,7 @@ sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
 tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
 tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
 tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
+tracex4-objs := bpf_load.o libbpf.o tracex4_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
@@ -26,6 +28,7 @@ always += sockex2_kern.o
 always += tracex1_kern.o
 always += tracex2_kern.o
 always += tracex3_kern.o
+always += tracex4_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 
@@ -35,6 +38,7 @@ HOSTLOADLIBES_sockex2 += -lelf
 HOSTLOADLIBES_tracex1 += -lelf
 HOSTLOADLIBES_tracex2 += -lelf
 HOSTLOADLIBES_tracex3 += -lelf
+HOSTLOADLIBES_tracex4 += -lelf -lrt
 
 # point this to your LLVM backend with bpf support
 LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex4_kern.c b/samples/bpf/tracex4_kern.c
new file mode 100644
index ..5754e21caf3b
--- /dev/null
+++ b/samples/bpf/tracex4_kern.c
@@ -0,0 +1,54 @@
+/* Copyright (c) 2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include "bpf_helpers.h"
+
+struct pair {
+   u64 val;
+   u64 ip;
+};
+
+struct bpf_map_def SEC("maps") my_map = {
+   .type = BPF_MAP_TYPE_HASH,
+   .key_size = sizeof(long),
+   .value_size = sizeof(struct pair),
+   .max_entries = 100,
+};
+
+/* kprobe is NOT a stable ABI
+ * This bpf+kprobe example can stop working any time.
+ */
+SEC("kprobe/kmem_cache_free")
+int bpf_prog1(struct pt_regs *ctx)
+{
+   long ptr = ctx->si;
+
+   bpf_map_delete_elem(_map, );
+   return 0;
+}
+
+SEC("kretprobe/kmem_cache_alloc_node")
+int bpf_prog2(struct pt_regs *ctx)
+{
+   long ptr = ctx->ax;
+   long ip = 0;
+
+   /* get ip address of kmem_cache_alloc_node() caller */
+   bpf_probe_read(, sizeof(ip), (void *)(ctx->bp + sizeof(ip)));
+
+   struct pair v = {
+   .val = bpf_ktime_get_ns(),
+   .ip = ip,
+   };
+
+   bpf_map_update_elem(_map, , , BPF_ANY);
+   return 0;
+}
+char _license[] SEC("license") = "GPL";
+u32 _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/samples/bpf/tracex4_user.c b/samples/bpf/tracex4_user.c
new file mode 100644
index ..bc4a3bdea6ed
--- /dev/null
+++ b/samples/bpf/tracex4_user.c
@@ -0,0 +1,69 @@
+/* Copyright (c) 2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "libbpf.h"
+#include "bpf_load.h"
+
+struct pair {
+   long long val;
+   __u64 ip;
+};
+
+static __u64 time_get_ns(void)
+{
+   struct timespec ts;
+
+   clock_gettime(CLOCK_MONOTONIC, );
+   return ts.tv_sec * 10ull + ts.tv_nsec;
+}
+
+static void print_old_objects(int fd)
+{
+   long long val = time_get_ns();
+   __u64 key, next_key;
+   struct pair v;
+
+   key = write(1, "\e[1;1H\e[2J", 12); /* clear screen */
+
+   key = -1;

[PATCH v6 tip 0/8] tracing: attach eBPF programs to kprobes

2015-03-10 Thread Alexei Starovoitov
Hi Ingo, Steven, Peter,

Please review/ack. Thanks!

V5->V6:
- added simple recursion check to trace_call_bpf()
- added tracex4 example that does kmem_cache_alloc/free tracking.
  It remembers every allocated object in a map and user space periodically
  prints a set of old objects. With more work in can be made into
  simple kmemleak detector.
  It was used as a test of recursive kmalloc/kfree: attached to
  kprobe/__kmalloc and let program to call kmalloc again.

V4->V5:
- switched to ktime_get_mono_fast_ns() as suggested by Peter
- in libbpf.c fixed zero init of 'union bpf_attr' padding
- fresh rebase on tip/master

This is targeting 'tip' tree, since most of the changes are perf_event related.
There will be a small conflict between net-next and tip, since they both
add new bpf_prog_type (BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_KPROBE).

V3 discussion:
https://lkml.org/lkml/2015/2/9/738

V3->V4:
- since the boundary of stable ABI in bpf+tracepoints is not clear yet,
  I've dropped them for now.
- bpf+syscalls are ok from stable ABI point of view, but bpf+seccomp
  would want to do very similar analysis of syscalls, so I've dropped
  them as well to take time and define common bpf+syscalls and bpf+seccomp
  infra in the future.
- so only bpf+kprobes left. kprobes by definition is not a stable ABI,
  so bpf+kprobe is not stable ABI either. To stress on that point added
  kernel version attribute that user space must pass along with the program
  and kernel will reject programs when version code doesn't match.
  So bpf+kprobe is very similar to kernel modules, but unlike modules
  version check is not used for safety, but for enforcing 'non-ABI-ness'.
  (version check doesn't apply to bpf+sockets which are stable)

Patch 1 is in net-next and needs to be in tip too, since patch 2 depends on it.

Patch 2 actually adds bpf+kprobe infra:
programs receive 'struct pt_regs' on input and can walk data structures
using bpf_probe_read() helper which is a wrapper of probe_kernel_read()

Programs are attached to kprobe events via API:

prog_fd = bpf_prog_load(...);
struct perf_event_attr attr = {
  .type = PERF_TYPE_TRACEPOINT,
  .config = event_id, /* ID of just created kprobe event */
};
event_fd = perf_event_open(,...);
ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);

Patch 3 adds bpf_ktime_get_ns() helper function, so that bpf programs can
measure time delta between events to compute disk io latency, etc.

Patch 4 adds bpf_trace_printk() helper that is used to debug programs.
When bpf verifier sees that program is calling bpf_trace_printk() it inits
trace_printk buffers which emits nasty 'this is debug only' banner.
That's exactly what we want. bpf_trace_printk() is for debugging only.

Patch 5 sample code that shows how to use bpf_probe_read/bpf_trace_printk

Patch 6 sample code - combination of kfree_skb and sys_write tracing.

Patch 7 sample code that computes disk io latency and prints it as 'heatmap'

Interesting bit is that patch 6 has log2() function implemented in C
and patch 7 has another log2() function using different algorithm in C.
In the future if 'log2' usage becomes common, we can add it as in-kernel
helper function, but for now bpf programs can implement them on bpf side.

Another interesting bit from patch 7 is that it does approximation of
floating point log10(X)*10 using integer arithmetic, which demonstrates
the power of C->BPF vs traditional tracing language alternatives,
where one would need to introduce new helper functions to add functionality,
whereas bpf can just implement such things in C as part of the program.

Next step is to prototype TCP stack instrumentation (like web10g) using
bpf+kprobe, but without adding any new code tcp stack.
Though kprobes are slow comparing to tracepoints, they are good enough
for prototyping and trace_marker/debug_tracepoint ideas can accelerate
them in the future.

Alexei Starovoitov (7):
  tracing: attach BPF programs to kprobes
  tracing: allow BPF programs to call bpf_ktime_get_ns()
  tracing: allow BPF programs to call bpf_trace_printk()
  samples: bpf: simple non-portable kprobe filter example
  samples: bpf: counting example for kfree_skb and write syscall
  samples: bpf: IO latency analysis (iosnoop/heatmap)
  samples: bpf: kmem_alloc/free tracker

Daniel Borkmann (1):
  bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs

 include/linux/bpf.h |   20 +++-
 include/linux/ftrace_event.h|   14 +++
 include/uapi/linux/bpf.h|5 +
 include/uapi/linux/perf_event.h |1 +
 kernel/bpf/syscall.c|7 +-
 kernel/events/core.c|   59 
 kernel/trace/Makefile   |1 +
 kernel/trace/bpf_trace.c|  198 +++
 kernel/trace/trace_kprobe.c |   10 +-
 samples/bpf/Makefile|   16 
 samples/bpf/bpf_helpers.h   |6 ++
 samples/bpf/bpf_load.c  |  125 ++--
 samples/bpf/bpf_load.h  

[PATCH v6 tip 3/8] tracing: allow BPF programs to call bpf_ktime_get_ns()

2015-03-10 Thread Alexei Starovoitov
bpf_ktime_get_ns() is used by programs to compue time delta between events
or as a timestamp

Signed-off-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h |1 +
 kernel/trace/bpf_trace.c |   11 +++
 2 files changed, 12 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 4486d36d2e9e..101e509d1001 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -165,6 +165,7 @@ enum bpf_func_id {
BPF_FUNC_map_update_elem, /* int map_update_elem(, , , 
flags) */
BPF_FUNC_map_delete_elem, /* int map_delete_elem(, ) */
BPF_FUNC_probe_read,  /* int bpf_probe_read(void *dst, int size, 
void *src) */
+   BPF_FUNC_ktime_get_ns,/* u64 bpf_ktime_get_ns(void) */
__BPF_FUNC_MAX_ID,
 };
 
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 450ea93ac4ab..ee7c2c629e75 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -56,6 +56,12 @@ static u64 bpf_probe_read(u64 r1, u64 r2, u64 r3, u64 r4, 
u64 r5)
return probe_kernel_read(dst, unsafe_ptr, size);
 }
 
+static u64 bpf_ktime_get_ns(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+   /* NMI safe access to clock monotonic */
+   return ktime_get_mono_fast_ns();
+}
+
 static struct bpf_func_proto kprobe_prog_funcs[] = {
[BPF_FUNC_probe_read] = {
.func = bpf_probe_read,
@@ -65,6 +71,11 @@ static struct bpf_func_proto kprobe_prog_funcs[] = {
.arg2_type = ARG_CONST_STACK_SIZE,
.arg3_type = ARG_ANYTHING,
},
+   [BPF_FUNC_ktime_get_ns] = {
+   .func = bpf_ktime_get_ns,
+   .gpl_only = true,
+   .ret_type = RET_INTEGER,
+   },
 };
 
 static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id 
func_id)
-- 
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] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform

2015-03-10 Thread Li, Aubrey
On 2015/3/10 16:06, Ingo Molnar wrote:
> 
> * Li, Aubrey  wrote:
> 
  - in x86_reduced_hw_init() set 'legacy_pic' to 'null_legacy_pic'

  - clean up 'global_clock_event' handling: instead of a global 
variable, move its management into x86_platform_ops::get_clockevent()
and set the method to hpet/pit/abp/etc. specific handlers that
return the right clockevent device.

  - in your x86_reduced_hw_init() function add the hpet clockevent
device to x86_platform_ops::get_clockevent, overriding the default
PIT.
>>
>> how about this one?
>>
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index b9e30da..70955d6 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -1541,6 +1541,16 @@ int __init early_acpi_boot_init(void)
>>   */
>>  early_acpi_process_madt();
>>
>> +/*
>> + * Override x86_init functions and bypass legacy pic
>> + * in hardware-reduced ACPI mode
>> + */
>> +if (acpi_gbl_reduced_hardware) {
>> +x86_init.timers.timer_init = x86_init_noop;
>> +x86_init.irqs.pre_vector_init = x86_init_noop;
>> +legacy_pic = _legacy_pic;
>> +}
> 
> Sounds good to me, assuming it builds, boots and works! :-)

Yeah, it's verified on my ASUS-T100 machine.

> 
> A couple of extra suggestions:
> 
> 1)
> 
> I'd suggest moving it into its own dedicated, appropriately named 
> static function, to make it clear that 'ACPI Reduced Hardware' init 
> happens there.
> 
> 2)
> 
> I'd also initialize it like this:
> 
>   x86_init.timers.timer_init  = x86_init_noop;
>   x86_init.irqs.pre_vector_init   = x86_init_noop;
>   legacy_pic  = _legacy_pic;
> 
> to make the noop patterns stand out better.

Thanks for the suggestions, I'll send the patch out soon.

> 
> 3)
> 
> Once all is said and done, please also make acpi_gbl_reduced_hardware 
> a flag internal to the ACPI code, not exposed to and used by other 
> bits of x86 code.
> 
>> If the above makes sense, I'll send poweroff and reboot change 
>> together in a seperate patch.
> 
> Yeah, please send them in a single series though, so they form a 
> logical group.

Execution flow:

->early_acpi_boot_init()
-->acpi_reduced_hw_init()
->reboot_init()
->acpi_sleep_init()
->efi_shutdown_init()

For poweroff, it will take no effect if we override pm_power_off during
reduced hardware initialization, because acpi_sleep_init() will override
it again to acpi_power_off.

For reboot, it's really a quirk to have to force reboot mode to be
EFI_RESET_WARM, so we can't just set the reboot type and done, there is
also a logic that DMI quirks table takes precedence over EFI quirk.

So, IMHO, we either need an EFI cross function called from ACPI to ask
EFI to reboot and poweroff system in reduced hw mode, or we need a copy
of acpi_gbl_reduced_hardware in EFI to do so.

What do you think?

Thanks,
-Aubrey
--
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/


trust you

2015-03-10 Thread Xu X, Xiaoyan


My name is Gatan Magsino, I work with Mediterranean Bank in Malta. Can i trust 
you with a business worth 8.3 million USD? Please reply ONLY to my private 
email: ta...@rogers.com for more information.
--
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 8/9] selftests/mqueue: Use implicit rules

2015-03-10 Thread Michael Ellerman
There's no need to open-code the build rules, use the implicit ones.

This has the nice side effect of enabling cross compilation.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/mqueue/Makefile | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/mqueue/Makefile 
b/tools/testing/selftests/mqueue/Makefile
index 6ca7261b55dc..ed85a1d7ee36 100644
--- a/tools/testing/selftests/mqueue/Makefile
+++ b/tools/testing/selftests/mqueue/Makefile
@@ -1,6 +1,11 @@
-all:
-   gcc -O2 mq_open_tests.c -o mq_open_tests -lrt
-   gcc -O2 -o mq_perf_tests mq_perf_tests.c -lrt -lpthread -lpopt
+TEST_PROGS := mq_open_tests mq_perf_tests
+
+CFLAGS += -O2
+LDLIBS += -lrt
+
+mq_perf_tests: LDLIBS += -lpthread -lpopt
+
+all: $(TEST_PROGS)
 
 include ../lib.mk
 
@@ -9,12 +14,10 @@ override define RUN_TESTS
@./mq_perf_tests || echo "selftests: mq_perf_tests [FAIL]"
 endef
 
-TEST_PROGS := mq_open_tests mq_perf_tests
-
 override define EMIT_TESTS
echo "./mq_open_tests /test1 || echo \"selftests: mq_open_tests 
[FAIL]\""
echo "./mq_perf_tests || echo \"selftests: mq_perf_tests [FAIL]\""
 endef
 
 clean:
-   rm -f mq_open_tests mq_perf_tests
+   rm -f $(TEST_PROGS)
-- 
2.1.0

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


[PATCH v4 9/9] selftests/mount: Use implicit rules

2015-03-10 Thread Michael Ellerman
There's no need to open-code the build rules, use the implicit ones.

This has the nice side effect of enabling cross compilation.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/mount/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/mount/Makefile 
b/tools/testing/selftests/mount/Makefile
index a5b367f032ba..a6c62bedb0d9 100644
--- a/tools/testing/selftests/mount/Makefile
+++ b/tools/testing/selftests/mount/Makefile
@@ -1,13 +1,13 @@
 # Makefile for mount selftests.
 
-all: unprivileged-remount-test
+TEST_PROGS := unprivileged-remount-test
+
+CFLAGS += -O2 -Wall
 
-unprivileged-remount-test: unprivileged-remount-test.c
-   gcc -Wall -O2 unprivileged-remount-test.c -o unprivileged-remount-test
+all: $(TEST_PROGS)
 
 include ../lib.mk
 
-TEST_PROGS := unprivileged-remount-test
 override RUN_TESTS := if [ -f /proc/self/uid_map ] ; then 
./unprivileged-remount-test ; fi
 override EMIT_TESTS := echo "$(RUN_TESTS)"
 
-- 
2.1.0

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


[PATCH v4 4/9] selftests: Add install target

2015-03-10 Thread Michael Ellerman
This adds make install support to selftests. The basic usage is:

$ cd tools/testing/selftests
$ make install

That installs into tools/testing/selftests/install, which can then be
copied where ever necessary.

The install destination is also configurable using eg:

$ INSTALL_PATH=/mnt/selftests make install

The implementation uses two targets in the child makefiles. The first
"install" is expected to install all files into $(INSTALL_PATH).

The second, "emit_tests", is expected to emit the test instructions (ie.
bash script) on stdout. Separating this from install means the child
makefiles need no knowledge of the location of the test script.

Signed-off-by: Michael Ellerman 
---

v3: Rebase onto 4.0-rc2.
Rename all.sh to run_kselftest.sh.
Add --no-print-directory to emit_tests invocation.
v4: Rebase onto 4.0-rc3, add TEST_FILES to efivars and vm tests, remove
newlines from echoes.

 tools/testing/selftests/Makefile| 33 +
 tools/testing/selftests/efivarfs/Makefile   |  1 +
 tools/testing/selftests/exec/Makefile   |  3 +++
 tools/testing/selftests/lib.mk  | 23 -
 tools/testing/selftests/memory-hotplug/Makefile |  2 ++
 tools/testing/selftests/mount/Makefile  |  2 ++
 tools/testing/selftests/mqueue/Makefile |  7 ++
 tools/testing/selftests/net/Makefile|  1 +
 tools/testing/selftests/sysctl/Makefile |  1 +
 tools/testing/selftests/vm/Makefile |  1 +
 10 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 4e511221a0c1..9af1df28bb26 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -47,7 +47,40 @@ clean_hotplug:
make -C $$TARGET clean; \
done;
 
+INSTALL_PATH ?= install
+INSTALL_PATH := $(abspath $(INSTALL_PATH))
+ALL_SCRIPT := $(INSTALL_PATH)/run_kselftest.sh
+
+install:
+ifdef INSTALL_PATH
+   @# Ask all targets to install their files
+   mkdir -p $(INSTALL_PATH)
+   for TARGET in $(TARGETS); do \
+   mkdir -p $(INSTALL_PATH)/$$TARGET ; \
+   make -C $$TARGET INSTALL_PATH=$(INSTALL_PATH)/$$TARGET install; 
\
+   done;
+
+   @# Ask all targets to emit their test scripts
+   echo "#!/bin/bash" > $(ALL_SCRIPT)
+   echo "cd \$$(dirname \$$0)" >> $(ALL_SCRIPT)
+   echo "ROOT=\$$PWD" >> $(ALL_SCRIPT)
+
+   for TARGET in $(TARGETS); do \
+   echo "echo ; echo Running tests in $$TARGET" >> $(ALL_SCRIPT); \
+   echo "echo " >> 
$(ALL_SCRIPT); \
+   echo "cd $$TARGET" >> $(ALL_SCRIPT); \
+   make -s --no-print-directory -C $$TARGET emit_tests >> 
$(ALL_SCRIPT); \
+   echo "cd \$$ROOT" >> $(ALL_SCRIPT); \
+   done;
+
+   chmod u+x $(ALL_SCRIPT)
+else
+   $(error Error: set INSTALL_PATH to use install)
+endif
+
 clean:
for TARGET in $(TARGETS); do \
make -C $$TARGET clean; \
done;
+
+.PHONY: install
diff --git a/tools/testing/selftests/efivarfs/Makefile 
b/tools/testing/selftests/efivarfs/Makefile
index 3052d0bda24b..9ff04f154bd5 100644
--- a/tools/testing/selftests/efivarfs/Makefile
+++ b/tools/testing/selftests/efivarfs/Makefile
@@ -6,6 +6,7 @@ test_objs = open-unlink create-read
 all: $(test_objs)
 
 TEST_PROGS := efivarfs.sh
+TEST_FILES := $(test_objs)
 
 include ../lib.mk
 
diff --git a/tools/testing/selftests/exec/Makefile 
b/tools/testing/selftests/exec/Makefile
index a0098daeb73d..886cabe307b1 100644
--- a/tools/testing/selftests/exec/Makefile
+++ b/tools/testing/selftests/exec/Makefile
@@ -19,8 +19,11 @@ execveat.denatured: execveat
$(CC) $(CFLAGS) -o $@ $^
 
 TEST_PROGS := execveat
+TEST_FILES := $(DEPS)
 
 include ../lib.mk
 
+override EMIT_TESTS := echo "mkdir -p subdir; (./execveat && echo \"selftests: 
execveat [PASS]\") || echo \"selftests: execveat [FAIL]\""
+
 clean:
rm -rf $(BINARIES) $(DEPS) subdir.moved execveat.moved x*
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index b30c5a49cb61..7bd3dabe2846 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -7,4 +7,25 @@ endef
 run_tests: all
$(RUN_TESTS)
 
-.PHONY: run_tests all clean
+define INSTALL_RULE
+   mkdir -p $(INSTALL_PATH)
+   install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_FILES)
+endef
+
+install: all
+ifdef INSTALL_PATH
+   $(INSTALL_RULE)
+else
+   $(error Error: set INSTALL_PATH to use install)
+endif
+
+define EMIT_TESTS
+   @for TEST in $(TEST_PROGS); do \
+   echo "(./$$TEST && echo \"selftests: $$TEST [PASS]\") || echo 
\"selftests: $$TEST [FAIL]\""; \
+   done;
+endef
+
+emit_tests:
+   $(EMIT_TESTS)
+
+.PHONY: run_tests all clean install emit_tests
diff --git a/tools/testing/selftests/memory-hotplug/Makefile 

[PATCH v4 5/9] selftests: Add install support for the powerpc tests

2015-03-10 Thread Michael Ellerman
The bulk of the selftests are actually below the powerpc sub directory.

This adds support for installing them, when on a powerpc machine, or if
ARCH and CROSS_COMPILE are set appropriately.

This is a little more complicated because of the sub directory structure
under powerpc, but much of the common logic in lib.mk is still used. The
net effect of the patch is still a reduction in code.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/powerpc/Makefile   | 19 -
 tools/testing/selftests/powerpc/copyloops/Makefile | 15 +++
 tools/testing/selftests/powerpc/mm/Makefile| 15 +++
 tools/testing/selftests/powerpc/pmu/Makefile   | 48 --
 tools/testing/selftests/powerpc/pmu/ebb/Makefile   | 13 +++---
 .../testing/selftests/powerpc/primitives/Makefile  | 15 +++
 .../testing/selftests/powerpc/stringloops/Makefile | 15 +++
 tools/testing/selftests/powerpc/tm/Makefile| 15 +++
 8 files changed, 73 insertions(+), 82 deletions(-)

diff --git a/tools/testing/selftests/powerpc/Makefile 
b/tools/testing/selftests/powerpc/Makefile
index 1d5e7ad2c460..22c4f8ffa422 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -22,10 +22,25 @@ all: $(TARGETS)
 $(TARGETS):
$(MAKE) -k -C $@ all
 
-run_tests: all
+include ../lib.mk
+
+override define RUN_TESTS
@for TARGET in $(TARGETS); do \
$(MAKE) -C $$TARGET run_tests; \
done;
+endef
+
+override define INSTALL_RULE
+   @for TARGET in $(TARGETS); do \
+   $(MAKE) -C $$TARGET install; \
+   done;
+endef
+
+override define EMIT_TESTS
+   @for TARGET in $(TARGETS); do \
+   $(MAKE) -s -C $$TARGET emit_tests; \
+   done;
+endef
 
 clean:
@for TARGET in $(TARGETS); do \
@@ -36,4 +51,4 @@ clean:
 tags:
find . -name '*.c' -o -name '*.h' | xargs ctags
 
-.PHONY: all run_tests clean tags $(TARGETS)
+.PHONY: tags $(TARGETS)
diff --git a/tools/testing/selftests/powerpc/copyloops/Makefile 
b/tools/testing/selftests/powerpc/copyloops/Makefile
index 6f2d3be227f9..c05023514ce8 100644
--- a/tools/testing/selftests/powerpc/copyloops/Makefile
+++ b/tools/testing/selftests/powerpc/copyloops/Makefile
@@ -6,24 +6,19 @@ CFLAGS += -D SELFTEST
 # Use our CFLAGS for the implicit .S rule
 ASFLAGS = $(CFLAGS)
 
-PROGS := copyuser_64 copyuser_power7 memcpy_64 memcpy_power7
+TEST_PROGS := copyuser_64 copyuser_power7 memcpy_64 memcpy_power7
 EXTRA_SOURCES := validate.c ../harness.c
 
-all: $(PROGS)
+all: $(TEST_PROGS)
 
 copyuser_64: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_base
 copyuser_power7: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_power7
 memcpy_64:   CPPFLAGS += -D COPY_LOOP=test_memcpy
 memcpy_power7:   CPPFLAGS += -D COPY_LOOP=test_memcpy_power7
 
-$(PROGS): $(EXTRA_SOURCES)
+$(TEST_PROGS): $(EXTRA_SOURCES)
 
-run_tests: all
-   @-for PROG in $(PROGS); do \
-   ./$$PROG; \
-   done;
+include ../../lib.mk
 
 clean:
-   rm -f $(PROGS) *.o
-
-.PHONY: all run_tests clean
+   rm -f $(TEST_PROGS) *.o
diff --git a/tools/testing/selftests/powerpc/mm/Makefile 
b/tools/testing/selftests/powerpc/mm/Makefile
index a14c538dd7f8..41cc3ed66818 100644
--- a/tools/testing/selftests/powerpc/mm/Makefile
+++ b/tools/testing/selftests/powerpc/mm/Makefile
@@ -1,21 +1,16 @@
 noarg:
$(MAKE) -C ../
 
-PROGS := hugetlb_vs_thp_test subpage_prot
+TEST_PROGS := hugetlb_vs_thp_test subpage_prot
 
-all: $(PROGS) tempfile
+all: $(TEST_PROGS) tempfile
 
-$(PROGS): ../harness.c
+$(TEST_PROGS): ../harness.c
 
-run_tests: all
-   @-for PROG in $(PROGS); do \
-   ./$$PROG; \
-   done;
+include ../../lib.mk
 
 tempfile:
dd if=/dev/zero of=tempfile bs=64k count=1
 
 clean:
-   rm -f $(PROGS) tempfile
-
-.PHONY: all run_tests clean
+   rm -f $(TEST_PROGS) tempfile
diff --git a/tools/testing/selftests/powerpc/pmu/Makefile 
b/tools/testing/selftests/powerpc/pmu/Makefile
index c9f4263906a5..5a161175bbd4 100644
--- a/tools/testing/selftests/powerpc/pmu/Makefile
+++ b/tools/testing/selftests/powerpc/pmu/Makefile
@@ -1,38 +1,42 @@
 noarg:
$(MAKE) -C ../
 
-PROGS := count_instructions l3_bank_test per_event_excludes
+TEST_PROGS := count_instructions l3_bank_test per_event_excludes
 EXTRA_SOURCES := ../harness.c event.c lib.c
 
-SUB_TARGETS = ebb
+all: $(TEST_PROGS) ebb
 
-all: $(PROGS) $(SUB_TARGETS)
-
-$(PROGS): $(EXTRA_SOURCES)
+$(TEST_PROGS): $(EXTRA_SOURCES)
 
 # loop.S can only be built 64-bit
 count_instructions: loop.S count_instructions.c $(EXTRA_SOURCES)
$(CC) $(CFLAGS) -m64 -o $@ $^
 
-run_tests: all sub_run_tests
-   @-for PROG in $(PROGS); do \
-   ./$$PROG; \
-   done;
+include ../../lib.mk
 
-clean: sub_clean
-   rm -f $(PROGS) loop.o
+DEFAULT_RUN_TESTS := $(RUN_TESTS)
+override define RUN_TESTS
+   $(DEFAULT_RUN_TESTS)
+   $(MAKE) -C ebb run_tests
+endef
 

[PATCH v4 1/9] kbuild: Don't pass -rR to selftest makefiles

2015-03-10 Thread Michael Ellerman
The makefiles under tools/testing/selftests are not real kbuild
makefiles, they are regular stand alone makefiles. As such they *do*
want all the standard implicit rules and variables defined.

So before calling those makefiles, filter -rR out of MAKEFLAGS.

Without this not all the selftests are built correctly when called via
the top-level Makefile.

Signed-off-by: Michael Ellerman 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 1100ff3c77e3..0836e9d628f0 100644
--- a/Makefile
+++ b/Makefile
@@ -1085,7 +1085,7 @@ headers_check: headers_install
 
 PHONY += kselftest
 kselftest:
-   $(Q)$(MAKE) -C tools/testing/selftests run_tests
+   $(Q)$(MAKE) -C tools/testing/selftests MAKEFLAGS="$(filter-out 
rR,$(MAKEFLAGS))" run_tests
 
 # ---
 # Modules
-- 
2.1.0

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


[PATCH v4 7/9] selftests/timers: Use implicit rules

2015-03-10 Thread Michael Ellerman
There's no need to open-code the build rules, use the implicit ones.

This has the nice side effect of enabling cross compilation.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/timers/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/timers/Makefile 
b/tools/testing/selftests/timers/Makefile
index 149cee3b7b8a..87340405e4b3 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -1,9 +1,9 @@
-all:
-   gcc posix_timers.c -o posix_timers -lrt
-
 TEST_PROGS := posix_timers
+LDLIBS += -lrt
+
+all: $(TEST_PROGS)
 
 include ../lib.mk
 
 clean:
-   rm -f ./posix_timers
+   rm -f $(TEST_PROGS)
-- 
2.1.0

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


[PATCH v4 6/9] selftests: Set CC using CROSS_COMPILE once in lib.mk

2015-03-10 Thread Michael Ellerman
This avoids repeating the logic in every Makefile. We mimic the
top-level Makefile and use $(CROSS_COMPILE)gcc.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/efivarfs/Makefile | 1 -
 tools/testing/selftests/exec/Makefile | 1 -
 tools/testing/selftests/kcmp/Makefile | 1 -
 tools/testing/selftests/lib.mk| 4 
 tools/testing/selftests/net/Makefile  | 1 -
 tools/testing/selftests/powerpc/Makefile  | 3 +--
 tools/testing/selftests/size/Makefile | 2 --
 tools/testing/selftests/vm/Makefile   | 1 -
 8 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/tools/testing/selftests/efivarfs/Makefile 
b/tools/testing/selftests/efivarfs/Makefile
index 9ff04f154bd5..736c3ddfc787 100644
--- a/tools/testing/selftests/efivarfs/Makefile
+++ b/tools/testing/selftests/efivarfs/Makefile
@@ -1,4 +1,3 @@
-CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall
 
 test_objs = open-unlink create-read
diff --git a/tools/testing/selftests/exec/Makefile 
b/tools/testing/selftests/exec/Makefile
index 886cabe307b1..4edb7d0da29b 100644
--- a/tools/testing/selftests/exec/Makefile
+++ b/tools/testing/selftests/exec/Makefile
@@ -1,4 +1,3 @@
-CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall
 BINARIES = execveat
 DEPS = execveat.symlink execveat.denatured script subdir
diff --git a/tools/testing/selftests/kcmp/Makefile 
b/tools/testing/selftests/kcmp/Makefile
index 0eecd183058c..2ae7450a9a89 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -1,4 +1,3 @@
-CC := $(CROSS_COMPILE)$(CC)
 CFLAGS += -I../../../../usr/include/
 
 all: kcmp_test
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 7bd3dabe2846..860906694a10 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -1,3 +1,7 @@
+# This mimics the top-level Makefile. We do it explicitly here so that this
+# Makefile can operate with or without the kbuild infrastructure.
+CC := $(CROSS_COMPILE)gcc
+
 define RUN_TESTS
@for TEST in $(TEST_PROGS); do \
(./$$TEST && echo "selftests: $$TEST [PASS]") || echo 
"selftests: $$TEST [FAIL]"; \
diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index 6ba2ac7bbb0d..fac4782c51d8 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -1,6 +1,5 @@
 # Makefile for net selftests
 
-CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall -O2 -g
 
 CFLAGS += -I../../../../usr/include/
diff --git a/tools/testing/selftests/powerpc/Makefile 
b/tools/testing/selftests/powerpc/Makefile
index 22c4f8ffa422..2958fe9a74e9 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -8,10 +8,9 @@ ifeq ($(ARCH),powerpc)
 
 GIT_VERSION = $(shell git describe --always --long --dirty || echo "unknown")
 
-CC := $(CROSS_COMPILE)$(CC)
 CFLAGS := -Wall -O2 -flto -Wall -Werror -DGIT_VERSION='"$(GIT_VERSION)"' 
-I$(CURDIR) $(CFLAGS)
 
-export CC CFLAGS
+export CFLAGS
 
 TARGETS = pmu copyloops mm tm primitives stringloops
 
diff --git a/tools/testing/selftests/size/Makefile 
b/tools/testing/selftests/size/Makefile
index e4353d74ea6e..bbd0b5398b61 100644
--- a/tools/testing/selftests/size/Makefile
+++ b/tools/testing/selftests/size/Makefile
@@ -1,5 +1,3 @@
-CC = $(CROSS_COMPILE)gcc
-
 all: get_size
 
 get_size: get_size.c
diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index 1a49761df6ed..a5ce9534eb15 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,6 +1,5 @@
 # Makefile for vm selftests
 
-CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall
 BINARIES = hugepage-mmap hugepage-shm map_hugetlb thuge-gen hugetlbfstest
 BINARIES += transhuge-stress
-- 
2.1.0

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


[PATCH v4 2/9] kbuild: Don't pass LDFLAGS to selftest Makefile

2015-03-10 Thread Michael Ellerman
The makefile in arch/x86/Makefile.um sets LDFLAGS and exports it, which
is then propagated to the selftest Makefiles and leads to build errors
there. The build errors occur because we are passing LDFLAGS to CC, but
the option set in Makefile.um (-m elf_x86_64) is not understood by CC.
We could fix that by using -Wl, but that might break the UM build if
it's actually passing that option to LD directly.

We don't actually want the LDFLAGS from kbuild in the selftest Makefile,
so the simplest fix seems to be to clear LDFLAGS before invoking the
selftest Makefile.

Signed-off-by: Michael Ellerman 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 0836e9d628f0..5cef1d4c2ea0 100644
--- a/Makefile
+++ b/Makefile
@@ -1085,7 +1085,7 @@ headers_check: headers_install
 
 PHONY += kselftest
 kselftest:
-   $(Q)$(MAKE) -C tools/testing/selftests MAKEFLAGS="$(filter-out 
rR,$(MAKEFLAGS))" run_tests
+   $(Q)$(MAKE) LDFLAGS= -C tools/testing/selftests MAKEFLAGS="$(filter-out 
rR,$(MAKEFLAGS))" run_tests
 
 # ---
 # Modules
-- 
2.1.0

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


[PATCH v4 3/9] selftests: Introduce minimal shared logic for running tests

2015-03-10 Thread Michael Ellerman
This adds a Make include file which most selftests can then include to
get the run_tests logic.

On its own this has the advantage of some reduction in repetition, and
also means the pass/fail message is defined in fewer places.

However the key advantage is it will allow us to implement install very
simply in a subsequent patch.

The default implementation just executes each program in $(TEST_PROGS).

We use a variable to hold the default implementation of $(RUN_TESTS)
because that gives us a clean way to override it if necessary, ie. using
override. The mount, memory-hotplug and mqueue tests use that to provide
a different implementation.

Tests are not run via /bin/bash, so if they are scripts they must be
executable, we add a+x to several.

Signed-off-by: Michael Ellerman 
---

v3: Rebase onto 4.0-rc2, add +x to more scripts that need it.
v4: Rebase onto 4.0-rc3.

 tools/testing/selftests/breakpoints/Makefile |  5 +++--
 tools/testing/selftests/cpu-hotplug/Makefile |  5 +++--
 tools/testing/selftests/cpu-hotplug/on-off-test.sh   |  0
 tools/testing/selftests/efivarfs/Makefile|  5 +++--
 tools/testing/selftests/efivarfs/efivarfs.sh |  0
 tools/testing/selftests/exec/Makefile|  5 +++--
 tools/testing/selftests/firmware/Makefile| 20 ++--
 tools/testing/selftests/firmware/fw_filesystem.sh|  0
 tools/testing/selftests/firmware/fw_userhelper.sh|  0
 tools/testing/selftests/ftrace/Makefile  |  5 +++--
 tools/testing/selftests/ipc/Makefile |  5 +++--
 tools/testing/selftests/kcmp/Makefile|  5 +++--
 tools/testing/selftests/lib.mk   | 10 ++
 tools/testing/selftests/memfd/Makefile   |  6 +++---
 tools/testing/selftests/memory-hotplug/Makefile  |  5 +++--
 .../testing/selftests/memory-hotplug/on-off-test.sh  |  0
 tools/testing/selftests/mount/Makefile   |  8 ++--
 tools/testing/selftests/mqueue/Makefile  |  9 ++---
 tools/testing/selftests/net/Makefile |  8 
 tools/testing/selftests/net/run_afpackettests|  0
 tools/testing/selftests/net/run_netsocktests |  0
 tools/testing/selftests/ptrace/Makefile  |  5 +++--
 tools/testing/selftests/size/Makefile|  5 +++--
 tools/testing/selftests/sysctl/Makefile  | 11 ++-
 tools/testing/selftests/sysctl/run_numerictests  |  0
 tools/testing/selftests/sysctl/run_stringtests   |  0
 tools/testing/selftests/timers/Makefile  |  5 +++--
 tools/testing/selftests/user/Makefile|  5 +++--
 tools/testing/selftests/vm/Makefile  |  5 +++--
 tools/testing/selftests/vm/run_vmtests   |  0
 30 files changed, 68 insertions(+), 69 deletions(-)
 mode change 100644 => 100755 tools/testing/selftests/cpu-hotplug/on-off-test.sh
 mode change 100644 => 100755 tools/testing/selftests/efivarfs/efivarfs.sh
 mode change 100644 => 100755 tools/testing/selftests/firmware/fw_filesystem.sh
 mode change 100644 => 100755 tools/testing/selftests/firmware/fw_userhelper.sh
 create mode 100644 tools/testing/selftests/lib.mk
 mode change 100644 => 100755 
tools/testing/selftests/memory-hotplug/on-off-test.sh
 mode change 100644 => 100755 tools/testing/selftests/net/run_afpackettests
 mode change 100644 => 100755 tools/testing/selftests/net/run_netsocktests
 mode change 100644 => 100755 tools/testing/selftests/sysctl/run_numerictests
 mode change 100644 => 100755 tools/testing/selftests/sysctl/run_stringtests
 mode change 100644 => 100755 tools/testing/selftests/vm/run_vmtests

diff --git a/tools/testing/selftests/breakpoints/Makefile 
b/tools/testing/selftests/breakpoints/Makefile
index e18b42b254af..182235640209 100644
--- a/tools/testing/selftests/breakpoints/Makefile
+++ b/tools/testing/selftests/breakpoints/Makefile
@@ -16,8 +16,9 @@ else
echo "Not an x86 target, can't build breakpoints selftests"
 endif
 
-run_tests:
-   @./breakpoint_test || echo "breakpoints selftests: [FAIL]"
+TEST_PROGS := breakpoint_test
+
+include ../lib.mk
 
 clean:
rm -fr breakpoint_test
diff --git a/tools/testing/selftests/cpu-hotplug/Makefile 
b/tools/testing/selftests/cpu-hotplug/Makefile
index e9c28d8dc84b..15f02591d22c 100644
--- a/tools/testing/selftests/cpu-hotplug/Makefile
+++ b/tools/testing/selftests/cpu-hotplug/Makefile
@@ -1,7 +1,8 @@
 all:
 
-run_tests:
-   @/bin/bash ./on-off-test.sh || echo "cpu-hotplug selftests: [FAIL]"
+TEST_PROGS := on-off-test.sh
+
+include ../lib.mk
 
 run_full_test:
@/bin/bash ./on-off-test.sh -a || echo "cpu-hotplug selftests: [FAIL]"
diff --git a/tools/testing/selftests/cpu-hotplug/on-off-test.sh 
b/tools/testing/selftests/cpu-hotplug/on-off-test.sh
old mode 100644
new mode 100755
diff --git a/tools/testing/selftests/efivarfs/Makefile 
b/tools/testing/selftests/efivarfs/Makefile
index 

Re: [PATCH man-pages] bpf.2: new page documenting bpf(2)

2015-03-10 Thread Alexei Starovoitov
On Tue, Mar 10, 2015 at 6:16 AM, Silvan Jegen  wrote:
> Hi Alexei
>
> Please find some comments and suggestions below.

Thanks a lot for review!
I think I've addressed all comments:
 man2/bpf.2 |  187 
 1 file changed, 100 insertions(+), 87 deletions(-)
:)

the only thing I didn't change is 's/C/C dialect/ (?)'
Because the word 'dialect' would mean that there are
differences beyond reduced expressions.
It's a normal C. Compiler doesn't allow certain C constructs.
Like it's not possible to have global variables, loops, vararg
functions, passing structures, etc.

I'll add a license and will resend.

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 -next] zsmalloc: Include linux/sched.h to fix build error

2015-03-10 Thread Guenter Roeck
Fix:

mm/zsmalloc.c: In function '__zs_compact':
mm/zsmalloc.c:1747:2: error: implicit declaration of function 'cond_resched'

seen when building mips:allmodconfig.

Fixes: c4d204c38734 ("zsmalloc: support compaction")
Cc: Minchan Kim 
Signed-off-by: Guenter Roeck 
---
 mm/zsmalloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 73400f0..b663a8b 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -94,6 +94,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
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] Documentation: update the CONFIG_DEBUG_PAGEALLOC description

2015-03-10 Thread long.wanglong
On 2015/3/2 15:28, Wang Long wrote:

cc: vegard.nos...@gmail.com

> The CONFIG_DEBUG_PAGEALLOC option now is located under "Kernel
> hacking" / "Memory Debugging" / "Debug page memory allocations".
> so we should update the description in kmemcheck.txt.
> 
> Signed-off-by: Wang Long 
> ---
>  Documentation/kmemcheck.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt
> index a41bdeb..80aae85 100644
> --- a/Documentation/kmemcheck.txt
> +++ b/Documentation/kmemcheck.txt
> @@ -82,8 +82,8 @@ menu to even appear in "menuconfig". These are:
>  
>o CONFIG_DEBUG_PAGEALLOC=n
>  
> - This option is located under "Kernel hacking" / "Debug page memory
> - allocations".
> + This option is located under "Kernel hacking" / "Memory Debugging"
> +  / "Debug page memory allocations".
>  
>  In addition, I highly recommend turning on CONFIG_DEBUG_INFO=y. This is also
>  located under "Kernel hacking". With this, you will be able to get line 
> number
> 


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


Re: [PATCH 2/2 net-next] hyperv: Support batched notification

2015-03-10 Thread Jason Wang



On Wed, Mar 11, 2015 at 2:50 AM, K. Y. Srinivasan  
wrote:

Optimize notifying the host by deferring notification until there
are no more packets to be sent. This will help in batching the 
requests

on the host.

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

diff --git a/drivers/net/hyperv/hyperv_net.h 
b/drivers/net/hyperv/hyperv_net.h

index 4815843..3fd9896 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -184,7 +184,7 @@ struct rndis_device {
 int netvsc_device_add(struct hv_device *device, void 
*additional_info);

 int netvsc_device_remove(struct hv_device *device);
 int netvsc_send(struct hv_device *device,
-   struct hv_netvsc_packet *packet);
+   struct hv_netvsc_packet *packet, bool kick_q);
 void netvsc_linkstatus_callback(struct hv_device *device_obj,
struct rndis_message *resp);
 int netvsc_recv_callback(struct hv_device *device_obj,
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 208eb05..9003b94 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -707,7 +707,7 @@ static u32 netvsc_copy_to_send_buf(struct 
netvsc_device *net_device,

 }
 
 int netvsc_send(struct hv_device *device,

-   struct hv_netvsc_packet *packet)
+   struct hv_netvsc_packet *packet, bool kick_q)
 {
struct netvsc_device *net_device;
int ret = 0;
@@ -719,6 +719,7 @@ int netvsc_send(struct hv_device *device,
u32 msg_size = 0;
struct sk_buff *skb = NULL;
u16 q_idx = packet->q_idx;
+   u32 vmbus_flags = VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED;
 
 
 	net_device = get_outbound_net_device(device);

@@ -768,18 +769,21 @@ int netvsc_send(struct hv_device *device,
return -ENODEV;
 
 	if (packet->page_buf_cnt) {

-   ret = vmbus_sendpacket_pagebuffer(out_channel,
+   ret = vmbus_sendpacket_pagebuffer_ctl(out_channel,
  packet->page_buf,
  packet->page_buf_cnt,
  ,
  sizeof(struct nvsp_message),
- req_id);
+ req_id,
+ vmbus_flags,
+ kick_q);


What if kick_q is false but ret is -EAGAIN here? Looks like in this 
case host won't get notified at all. How about checking whether txq and 
kicking if it has been stopped like what other network driver did?


} else {
-   ret = vmbus_sendpacket(out_channel, ,
+   ret = vmbus_sendpacket_ctl(out_channel, ,
sizeof(struct nvsp_message),
req_id,
VM_PKT_DATA_INBAND,
-   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
+   vmbus_flags,
+   kick_q);
}
 
 	if (ret == 0) {
diff --git a/drivers/net/hyperv/netvsc_drv.c 
b/drivers/net/hyperv/netvsc_drv.c

index a06bd66..80b4b29 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -384,6 +384,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, 
struct net_device *net)

u32 net_trans_info;
u32 hash;
u32 skb_length = skb->len;
+   bool kick_q = !skb->xmit_more;
 
 
 	/* We will atmost need two pages to describe the rndis

@@ -556,7 +557,7 @@ do_send:
packet->page_buf_cnt = init_page_array(rndis_msg, rndis_msg_size,
skb, >page_buf[0]);
 
-	ret = netvsc_send(net_device_ctx->device_ctx, packet);

+   ret = netvsc_send(net_device_ctx->device_ctx, packet, kick_q);
 
 drop:

if (ret == 0) {
diff --git a/drivers/net/hyperv/rndis_filter.c 
b/drivers/net/hyperv/rndis_filter.c

index ca81de0..05f3792 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -238,7 +238,7 @@ static int rndis_filter_send_request(struct 
rndis_device *dev,
 
 	packet->send_completion = NULL;
 
-	ret = netvsc_send(dev->net_dev->dev, packet);

+   ret = netvsc_send(dev->net_dev->dev, packet, true);
return ret;
 }
 
--

1.7.4.1



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


Re: [PATCH v2] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

2015-03-10 Thread Andy Lutomirski
On Tue, Mar 10, 2015 at 12:57 AM, Ingo Molnar  wrote:
>
> * Denys Vlasenko  wrote:
>
>> Old code was trying to avoid having three branch insns,
>> but instead it has a chain of six insns where each insn
>> depends on previos one.
>>
>> And it was touching PT_OLDSS(%esp) unconditionally, even when it may
>> contain bogus data. Elsewhere we have to jump thru hoops
>> just to make sure here PT_OLDSS(%esp) is at least in a valid page.
>>
>> All this just to have one branch instead of three?
>>
>> The new code simply checks each condition.
>> All three checks can run in parallel on an out-of-order CPU.
>> Most of the time, none of branches will be taken.
>>
>> Comparison of object code:
>> Old:
>>  1e6:   8b 44 24 38 mov0x38(%esp),%eax
>>  1ea:   8a 64 24 40 mov0x40(%esp),%ah
>>  1ee:   8a 44 24 34 mov0x34(%esp),%al
>>  1f2:   25 03 04 02 00  and$0x20403,%eax
>>  1f7:   3d 03 04 00 00  cmp$0x403,%eax
>>  1fc:   74 0f   je 20d 
>> New:
>>  1e6:   f6 44 24 3a 02  testb  $0x2,0x3a(%esp)
>>  1eb:   75 0e   jne1fb 
>>  1ed:   f6 44 24 34 03  testb  $0x3,0x34(%esp)
>>  1f2:   74 07   je 1fb 
>>  1f4:   f6 44 24 40 04  testb  $0x4,0x40(%esp)
>>  1f9:   75 0f   jne20a 
>
> Please do some benchmarking of this: a tight loop of getpid or getppid
> syscalls ought to be enough to be able to time this accurately.

Before you benchmark, I think you should reorder it: check CS, then
OLDSS, then EFLAGS.  The case where CS & 3 == 0, OLDSS & 4 == 4, and
EFLAGS & VM == VM should be *extremely* rare.

I'm going to hold off on resending my sp0/sp1/ss cleanups until we
resolve this -- if it turns out that your code is the same or faster
and therefore gets merged, then I think that all the -8 crap can just
be deleted instead of being fixed.

--Andy

>
> Thanks,
>
> Ingo



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


[PATCH 2/2] drm/bridge: Add IT6151 bridge driver

2015-03-10 Thread CK Hu
This patch adds a drm_bridge driver for the IT6151 MIPI to eDP
bridge chip.

Signed-off-by: CK Hu 
Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/bridge/Kconfig  |  10 +
 drivers/gpu/drm/bridge/Makefile |   1 +
 drivers/gpu/drm/bridge/it6151.c | 601 
 include/drm/bridge/it6151.h |  34 +++
 4 files changed, 646 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/it6151.c
 create mode 100644 include/drm/bridge/it6151.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f38bbcd..2b3a78e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -11,3 +11,13 @@ config DRM_PTN3460
select DRM_PANEL
---help---
  ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_IT6151
+   bool "Enable IT6151FN : MIPI to eDP Converter"
+   depends on DRM
+   select DRM_KMS_HELPER
+   help
+ Choose this option if you have IT6151 for display
+ The IT6151 is a high-performance and low-power
+ MIPI to eDP converter
+
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d8a8cfd..98edb74 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_DRM_IT6151) += it6151.o
diff --git a/drivers/gpu/drm/bridge/it6151.c b/drivers/gpu/drm/bridge/it6151.c
new file mode 100644
index 000..039fe4b
--- /dev/null
+++ b/drivers/gpu/drm/bridge/it6151.c
@@ -0,0 +1,601 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+
+#define MIPI_RX_SW_RST0x05
+#define MIPI_RX_INT_MASK  0x09
+#define MIPI_RX_SYS_CFG   0x0c
+#define MIPI_RX_MCLK  0x11
+#define MIPI_RX_PHY_IF_1  0x19
+#define MIPI_RX_PKT_DEC   0x27
+#define MIPI_RX_UFO_BLK_HIGH  0x28
+#define MIPI_RX_UFO_BLK_LOW   0x29
+#define MIPI_RX_UFO_HDE_DELAY 0x2e
+#define MIPI_RX_UFO_RESYNC0x2f
+#define MIPI_RX_RESYNC_POL0x4e
+#define MIPI_RX_PCLK_HSCLK0x80
+#define MIPI_RX_AMP_TERM  0x84
+#define MIPI_RX_TIMER_INT_CNT 0x92
+
+#define DP_TX_VEN_ID_LOW0x00
+#define DP_TX_VEN_ID_HIGH   0x01
+#define DP_TX_DEV_ID_LOW0x02
+#define DP_TX_DEV_ID_HIGH   0x03
+#define DP_TX_REV_ID0x04
+#define DP_TX_SW_RST0x05
+#define DP_TX_INT_STA_0 0x06
+#define DP_TX_INT_STA_1 0x07
+#define DP_TX_INT_STA_2 0x08
+#define DP_TX_INT_MASK_00x09
+#define DP_TX_INT_MASK_10x0a
+#define DP_TX_INT_MASK_20x0b
+#define DP_TX_SYS_CFG   0x0c
+#define DP_TX_SYS_DBG   0x0f
+#define DP_TX_LANE  0x16
+#define DP_TX_TRAIN 0x17
+#define DP_TX_AUX_CH_FIFO   0x21
+#define DP_TX_AUX_CLK   0x22
+#define DP_TX_PC_REQ_FIFO   0x23
+#define DP_TX_PC_REQ_OFST_0 0x24
+#define DP_TX_PC_REQ_OFST_1 0x25
+#define DP_TX_PC_REQ_OFST_2 0x26
+#define DP_TX_PC_REQ_WD_0   0x27
+#define DP_TX_PC_REQ_SEL0x2b
+#define DP_TX_HDP   0x3a
+#define DP_TX_LNPWDB0x5c
+#define DP_TX_EQ0x5f
+#define DP_TX_COL_CONV_19   0x76
+#define DP_TX_COL_CONV_20   0x77
+#define DP_TX_PG_H_DE_END_L 0x7e
+#define DP_TX_PG_H_DE_END_H 0x7f
+#define DP_TX_PG_H_SYNC_START_L 0x80
+#define DP_TX_PG_H_SYNC_START_H 0x81
+#define DP_TX_PG_H_SYNC_END_L   0x82
+#define DP_TX_PG_H_SYNC_END_H   0x83
+#define DP_TX_PG_V_DE_END_L 0x88
+#define DP_TX_PG_V_DE_END_H 0x89
+#define DP_TX_PG_V_DE_START_L   0x8a
+#define DP_TX_IN_VDO_TM_15  0xb5
+#define DP_TX_IN_VDO_TM_17  0xb7
+#define DP_TX_PSR_CTRL_00xc4
+#define DP_TX_PSR_CTRL_10xc5
+#define DP_TX_HDP_IRQ_TM0xc9
+#define DP_TX_AUX_DBG   0xca
+#define DP_TX_AUX_MASTER0xcb
+#define DP_TX_PKT_OPT   0xce
+#define DP_TX_VDO_FIFO  0xd3
+#define DP_TX_VDO_STMP  0xd4
+#define DP_TX_PKT   0xe8
+#define DP_TX_PKT_AVI_VIC   0xec
+#define DP_TX_MIPI_PORT 0xfd
+
+enum {
+   MIPI_1_LANE = 0,
+   MIPI_2_LANE = 1,
+   MIPI_3_LANE = 2,
+   MIPI_4_LANE = 3,
+};
+
+enum {
+   RGB_24b = 0x3E,
+   RGB_30b = 0x0D,
+   RGB_36b = 0x1D,
+   RGB_18b_P   = 0x1E,
+   

[PATCH 1/2] dt-bindings: drm/bridge: Add IT6151 bridge chip driver bindings.

2015-03-10 Thread CK Hu
Add devicetree bindings for IT6151 MIPI to eDP bridge chip driver.
---
 Documentation/devicetree/bindings/drm/bridge/it6151.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/it6151.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/it6151.txt 
b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
new file mode 100644
index 000..ad0ad60
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
@@ -0,0 +1,15 @@
+it6151 bridge bindings
+
+Required properties:
+   - compatible: "ite,it6151"
+   - reg: i2c address of the bridge's dp tx.
+   - rxreg: i2c address of the bridge's mipi rx.
+   - reset-gpio: OF device-tree gpio specification
+
+Example:
+   ite6151: edp-bridge@5c {
+   compatible = "ite,it6151";
+   reg = <0x5c>;
+   rxreg = <0x6c>;
+   reset-gpio = < 94 GPIO_ACTIVE_HIGH>;
+   };
-- 
1.8.1.1.dirty

* Email Confidentiality Notice 
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. 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/


[PATCH -next] of/platform: Fix sparc:allmodconfig build

2015-03-10 Thread Guenter Roeck
sparc:allmodconfig fails to build with:

drivers/built-in.o: In function `platform_bus_init':
(.init.text+0x3684): undefined reference to 
`of_platform_register_reconfig_notifier'

of_platform_register_reconfig_notifier is only declared if both OF_ADDRESS
and OF_DYNAMIC are configured. Yet, the include file only declares a dummy
function if OF_DYNAMIC is not configured. The sparc architecture does not
configure OF_ADDRESS, but does configure OF_DYNAMIC, causing above error.

Fixes: 801d728c10db ("of/reconfig: Add OF_DYNAMIC notifier for 
platform_bus_type")
Cc: Pantelis Antoniou 
Signed-off-by: Guenter Roeck 
---
 include/linux/of_platform.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 8a860f0..611a691 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -84,7 +84,7 @@ static inline int of_platform_populate(struct device_node 
*root,
 static inline void of_platform_depopulate(struct device *parent) { }
 #endif
 
-#ifdef CONFIG_OF_DYNAMIC
+#if defined(CONFIG_OF_DYNAMIC) && defined(CONFIG_OF_ADDRESS)
 extern void of_platform_register_reconfig_notifier(void);
 #else
 static inline void of_platform_register_reconfig_notifier(void) { }
-- 
2.1.0

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


[PATCH 6/8] ARM: time: Provide read_boot_clock64() and read_persistent_clock64()

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64 by converting clock_access_fn to use timespec64.

Signed-off-by: Xunlei Pang 
---
 arch/arm/include/asm/mach/time.h|  3 +--
 arch/arm/kernel/time.c  |  6 +++---
 arch/arm/plat-omap/counter_32k.c| 10 +-
 drivers/clocksource/tegra20_timer.c | 10 +-
 4 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/arch/arm/include/asm/mach/time.h b/arch/arm/include/asm/mach/time.h
index 90c12e1..0f79e4d 100644
--- a/arch/arm/include/asm/mach/time.h
+++ b/arch/arm/include/asm/mach/time.h
@@ -12,8 +12,7 @@
 
 extern void timer_tick(void);
 
-struct timespec;
-typedef void (*clock_access_fn)(struct timespec *);
+typedef void (*clock_access_fn)(struct timespec64 *);
 extern int register_persistent_clock(clock_access_fn read_boot,
 clock_access_fn read_persistent);
 
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 0cc7e58..a66e37e 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -76,7 +76,7 @@ void timer_tick(void)
 }
 #endif
 
-static void dummy_clock_access(struct timespec *ts)
+static void dummy_clock_access(struct timespec64 *ts)
 {
ts->tv_sec = 0;
ts->tv_nsec = 0;
@@ -85,12 +85,12 @@ static void dummy_clock_access(struct timespec *ts)
 static clock_access_fn __read_persistent_clock = dummy_clock_access;
 static clock_access_fn __read_boot_clock = dummy_clock_access;;
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
__read_persistent_clock(ts);
 }
 
-void read_boot_clock(struct timespec *ts)
+void read_boot_clock64(struct timespec64 *ts)
 {
__read_boot_clock(ts);
 }
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index d422e36..aee17ff 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -70,14 +70,6 @@ static void omap_read_persistent_clock64(struct timespec64 
*ts)
*ts = persistent_ts;
 }
 
-static void omap_read_persistent_clock(struct timespec *ts)
-{
-   struct timespec64 ts64;
-
-   omap_read_persistent_clock64();
-   *ts = timespec64_to_timespec(ts64);
-}
-
 /**
  * omap_init_clocksource_32k - setup and register counter 32k as a
  * kernel clocksource
@@ -118,7 +110,7 @@ int __init omap_init_clocksource_32k(void __iomem *vbase)
}
 
sched_clock_register(omap_32k_read_sched_clock, 32, 32768);
-   register_persistent_clock(NULL, omap_read_persistent_clock);
+   register_persistent_clock(NULL, omap_read_persistent_clock64);
pr_info("OMAP clocksource: 32k_counter at 32768 Hz\n");
 
return 0;
diff --git a/drivers/clocksource/tegra20_timer.c 
b/drivers/clocksource/tegra20_timer.c
index 7fc7fb9..8547742 100644
--- a/drivers/clocksource/tegra20_timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@ -141,14 +141,6 @@ static void tegra_read_persistent_clock64(struct 
timespec64 *ts)
*ts = persistent_ts;
 }
 
-static void tegra_read_persistent_clock(struct timespec *ts)
-{
-   struct timespec ts64;
-
-   tegra_read_persistent_clock64();
-   *ts = timespec64_to_timespec(ts64);
-}
-
 static unsigned long tegra_delay_timer_read_counter_long(void)
 {
return readl(timer_reg_base + TIMERUS_CNTR_1US);
@@ -259,7 +251,7 @@ static void __init tegra20_init_rtc(struct device_node *np)
else
clk_prepare_enable(clk);
 
-   register_persistent_clock(NULL, tegra_read_persistent_clock);
+   register_persistent_clock(NULL, tegra_read_persistent_clock64);
 }
 CLOCKSOURCE_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
 
-- 
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/


[PATCH 7/8] s390: time: Provide read_boot_clock64() and read_persistent_clock64()

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64.

Since S390 is a 64bit architecture, also rename some timespec
to timespec64 in time.c and the related references.

Signed-off-by: Xunlei Pang 
---
 arch/s390/include/asm/timex.h | 4 ++--
 arch/s390/kernel/debug.c  | 4 ++--
 arch/s390/kernel/time.c   | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/s390/include/asm/timex.h b/arch/s390/include/asm/timex.h
index 98eb2a5..8b08be3 100644
--- a/arch/s390/include/asm/timex.h
+++ b/arch/s390/include/asm/timex.h
@@ -108,10 +108,10 @@ int get_sync_clock(unsigned long long *clock);
 void init_cpu_timer(void);
 unsigned long long monotonic_clock(void);
 
-void tod_to_timeval(__u64, struct timespec *);
+void tod_to_timeval(__u64, struct timespec64 *);
 
 static inline
-void stck_to_timespec(unsigned long long stck, struct timespec *ts)
+void stck_to_timespec64(unsigned long long stck, struct timespec64 *ts)
 {
tod_to_timeval(stck - TOD_UNIX_EPOCH, ts);
 }
diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
index c1f21ac..20ff016 100644
--- a/arch/s390/kernel/debug.c
+++ b/arch/s390/kernel/debug.c
@@ -1457,14 +1457,14 @@ int
 debug_dflt_header_fn(debug_info_t * id, struct debug_view *view,
 int area, debug_entry_t * entry, char *out_buf)
 {
-   struct timespec time_spec;
+   struct timespec64 time_spec;
char *except_str;
unsigned long caller;
int rc = 0;
unsigned int level;
 
level = entry->id.fields.level;
-   stck_to_timespec(entry->id.stck, _spec);
+   stck_to_timespec64(entry->id.stck, _spec);
 
if (entry->id.fields.exception)
except_str = "*";
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index 20660dd..e4df144 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -76,7 +76,7 @@ unsigned long long monotonic_clock(void)
 }
 EXPORT_SYMBOL(monotonic_clock);
 
-void tod_to_timeval(__u64 todval, struct timespec *xt)
+void tod_to_timeval(__u64 todval, struct timespec64 *xt)
 {
unsigned long long sec;
 
@@ -181,12 +181,12 @@ static void timing_alert_interrupt(struct ext_code 
ext_code,
 static void etr_reset(void);
 static void stp_reset(void);
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
tod_to_timeval(get_tod_clock() - TOD_UNIX_EPOCH, ts);
 }
 
-void read_boot_clock(struct timespec *ts)
+void read_boot_clock64(struct timespec64 *ts)
 {
tod_to_timeval(sched_clock_base_cc - TOD_UNIX_EPOCH, ts);
 }
-- 
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/


[PATCH 5/8] ARM: tegra: clock: Provide y2038-safe tegra_read_persistent_clock() replacement

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

As part of addressing "y2038 problem" for in-kernel uses, this
patch adds the y2038-safe tegra_read_persistent_clock64() using
timespec64.

Because we rely on some subsequent changes to convert arm multiarch
support, tegra_read_persistent_clock() will be removed then.

Signed-off-by: Xunlei Pang 
---
 drivers/clocksource/tegra20_timer.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/clocksource/tegra20_timer.c 
b/drivers/clocksource/tegra20_timer.c
index d2616ef..7fc7fb9 100644
--- a/drivers/clocksource/tegra20_timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@ -51,7 +51,7 @@
 static void __iomem *timer_reg_base;
 static void __iomem *rtc_base;
 
-static struct timespec persistent_ts;
+static struct timespec64 persistent_ts;
 static u64 persistent_ms, last_persistent_ms;
 
 static struct delay_timer tegra_delay_timer;
@@ -120,26 +120,33 @@ static u64 tegra_rtc_read_ms(void)
 }
 
 /*
- * tegra_read_persistent_clock -  Return time from a persistent clock.
+ * tegra_read_persistent_clock64 -  Return time from a persistent clock.
  *
  * Reads the time from a source which isn't disabled during PM, the
  * 32k sync timer.  Convert the cycles elapsed since last read into
- * nsecs and adds to a monotonically increasing timespec.
+ * nsecs and adds to a monotonically increasing timespec64.
  * Care must be taken that this funciton is not called while the
  * tegra_rtc driver could be executing to avoid race conditions
  * on the RTC shadow register
  */
-static void tegra_read_persistent_clock(struct timespec *ts)
+static void tegra_read_persistent_clock64(struct timespec64 *ts)
 {
u64 delta;
-   struct timespec *tsp = _ts;
 
last_persistent_ms = persistent_ms;
persistent_ms = tegra_rtc_read_ms();
delta = persistent_ms - last_persistent_ms;
 
-   timespec_add_ns(tsp, delta * NSEC_PER_MSEC);
-   *ts = *tsp;
+   timespec64_add_ns(_ts, delta * NSEC_PER_MSEC);
+   *ts = persistent_ts;
+}
+
+static void tegra_read_persistent_clock(struct timespec *ts)
+{
+   struct timespec ts64;
+
+   tegra_read_persistent_clock64();
+   *ts = timespec64_to_timespec(ts64);
 }
 
 static unsigned long tegra_delay_timer_read_counter_long(void)
-- 
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/


[PATCH 5/5] of/unittest: replace selftest with unittest

2015-03-10 Thread Wang Long
This patch replace the selftest with unittest.

Signed-off-by: Wang Long 
---
 Documentation/devicetree/bindings/unittest.txt |  44 +-
 drivers/of/unittest-data/tests-overlay.dtsi| 108 ++--
 drivers/of/unittest.c  | 702 -
 3 files changed, 427 insertions(+), 427 deletions(-)

diff --git a/Documentation/devicetree/bindings/unittest.txt 
b/Documentation/devicetree/bindings/unittest.txt
index 8933211..3bf58c2 100644
--- a/Documentation/devicetree/bindings/unittest.txt
+++ b/Documentation/devicetree/bindings/unittest.txt
@@ -1,60 +1,60 @@
-1) OF selftest platform device
+1) OF unittest platform device
 
-** selftest
+** unittest
 
 Required properties:
-- compatible: must be "selftest"
+- compatible: must be "unittest"
 
 All other properties are optional.
 
 Example:
-   selftest {
-   compatible = "selftest";
+   unittest {
+   compatible = "unittest";
status = "okay";
};
 
-2) OF selftest i2c adapter platform device
+2) OF unittest i2c adapter platform device
 
 ** platform device unittest adapter
 
 Required properties:
-- compatible: must be selftest-i2c-bus
+- compatible: must be unittest-i2c-bus
 
-Children nodes contain selftest i2c devices.
+Children nodes contain unittest i2c devices.
 
 Example:
-   selftest-i2c-bus {
-   compatible = "selftest-i2c-bus";
+   unittest-i2c-bus {
+   compatible = "unittest-i2c-bus";
status = "okay";
};
 
-3) OF selftest i2c device
+3) OF unittest i2c device
 
-** I2C selftest device
+** I2C unittest device
 
 Required properties:
-- compatible: must be selftest-i2c-dev
+- compatible: must be unittest-i2c-dev
 
 All other properties are optional
 
 Example:
-   selftest-i2c-dev {
-   compatible = "selftest-i2c-dev";
+   unittest-i2c-dev {
+   compatible = "unittest-i2c-dev";
status = "okay";
};
 
-4) OF selftest i2c mux device
+4) OF unittest i2c mux device
 
-** I2C selftest mux
+** I2C unittest mux
 
 Required properties:
-- compatible: must be selftest-i2c-mux
+- compatible: must be unittest-i2c-mux
 
-Children nodes contain selftest i2c bus nodes per channel.
+Children nodes contain unittest i2c bus nodes per channel.
 
 Example:
-   selftest-i2c-mux {
-   compatible = "selftest-i2c-mux";
+   unittest-i2c-mux {
+   compatible = "unittest-i2c-mux";
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
@@ -64,7 +64,7 @@ Example:
#size-cells = <0>;
i2c-dev {
reg = <8>;
-   compatible = "selftest-i2c-dev";
+   compatible = "unittest-i2c-dev";
status = "okay";
};
};
diff --git a/drivers/of/unittest-data/tests-overlay.dtsi 
b/drivers/of/unittest-data/tests-overlay.dtsi
index 244226c..02ba56c 100644
--- a/drivers/of/unittest-data/tests-overlay.dtsi
+++ b/drivers/of/unittest-data/tests-overlay.dtsi
@@ -4,94 +4,94 @@
overlay-node {
 
/* test bus */
-   selftestbus: test-bus {
+   unittestbus: test-bus {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
 
-   selftest100: test-selftest100 {
-   compatible = "selftest";
+   unittest100: test-unittest100 {
+   compatible = "unittest";
status = "okay";
reg = <100>;
};
 
-   selftest101: test-selftest101 {
-   compatible = "selftest";
+   unittest101: test-unittest101 {
+   compatible = "unittest";
status = "disabled";
reg = <101>;
};
 
-   selftest0: test-selftest0 {
-   compatible = "selftest";
+   unittest0: test-unittest0 {
+   compatible = "unittest";
status = "disabled";
reg = <0>;
};
 
-   selftest1: test-selftest1 {
-   compatible = "selftest";
+   unittest1: test-unittest1 {
+   compatible = 

[PATCH 8/8] time: Remove read_boot_clock()

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

Now we have all the read_boot_clock64() for all implementations,
it's time to remove read_boot_clock() completely from the kernel.

Signed-off-by: Xunlei Pang 
---
read_persistent_clock() and update_persistent_clock() are way more
complex, so we will deal with them gradually in extra patchsets.

 include/linux/timekeeping.h |  1 -
 kernel/time/timekeeping.c   | 14 +++---
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index a7fa96b..72631e8 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -263,7 +263,6 @@ static inline bool has_persistent_clock(void)
 
 extern void read_persistent_clock(struct timespec *ts);
 extern void read_persistent_clock64(struct timespec64 *ts);
-extern void read_boot_clock(struct timespec *ts);
 extern void read_boot_clock64(struct timespec64 *ts);
 extern int update_persistent_clock(struct timespec now);
 extern int update_persistent_clock64(struct timespec64 now);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 0e5a696..d0ca908 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1066,28 +1066,20 @@ void __weak read_persistent_clock64(struct timespec64 
*ts64)
 }
 
 /**
- * read_boot_clock -  Return time of the system start.
+ * read_boot_clock64 -  Return time of the system start.
  *
  * Weak dummy function for arches that do not yet support it.
  * Function to read the exact time the system has been started.
- * Returns a timespec with tv_sec=0 and tv_nsec=0 if unsupported.
+ * Returns a timespec64 with tv_sec=0 and tv_nsec=0 if unsupported.
  *
  *  XXX - Do be sure to remove it once all arches implement it.
  */
-void __weak read_boot_clock(struct timespec *ts)
+void __weak read_boot_clock64(struct timespec64 *ts)
 {
ts->tv_sec = 0;
ts->tv_nsec = 0;
 }
 
-void __weak read_boot_clock64(struct timespec64 *ts64)
-{
-   struct timespec ts;
-
-   read_boot_clock();
-   *ts64 = timespec_to_timespec64(ts);
-}
-
 /*
  * timekeeping_init - Initializes the clocksource and common timekeeping values
  */
-- 
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/


[PATCH 0/5] Update the OF unittest and some small fix

2015-03-10 Thread Wang Long
This series patches do some small fixes in drivers/of/unittest.c,
and update the Documenttion. 
At last, replace selftest with unittest in the c and dtsi files.

Wang Long (5):
  of/unittest: remove the duplicate of_changeset_init
  of/unittest: Fix the wrong expected value in
of_selftest_property_string
  Documentation: update the of_selftest.txt
  Documentation: rename of_selftest.txt to of_unittest.txt
  of/unittest: replace selftest with unittest

 Documentation/devicetree/bindings/unittest.txt |  44 +-
 Documentation/devicetree/of_selftest.txt   | 197 ---
 Documentation/devicetree/of_unittest.txt   | 198 +++
 drivers/of/unittest-data/tests-overlay.dtsi| 108 ++--
 drivers/of/unittest.c  | 703 -
 5 files changed, 625 insertions(+), 625 deletions(-)
 delete mode 100644 Documentation/devicetree/of_selftest.txt
 create mode 100644 Documentation/devicetree/of_unittest.txt

-- 
1.8.3.4

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


[PATCH 3/5] Documentation: update the of_selftest.txt

2015-03-10 Thread Wang Long
Since the directory "drivers/of/testcase-data" is renamed
to "drivers/of/unittest-data". so we should update the path
in the of_selftest.txt.

When the kernel is built with OF_UNITTEST enabled, the output
dtb is testcases.dtb instead of testcase.dtb, also update it
(s/testcase/testcases/).

Signed-off-by: Wang Long 
---
 Documentation/devicetree/of_selftest.txt | 35 
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/of_selftest.txt 
b/Documentation/devicetree/of_selftest.txt
index 57a808b..d79a6bc 100644
--- a/Documentation/devicetree/of_selftest.txt
+++ b/Documentation/devicetree/of_selftest.txt
@@ -1,11 +1,11 @@
-Open Firmware Device Tree Selftest
+Open Firmware Device Tree Unittest
 --
 
 Author: Gaurav Minocha 
 
 1. Introduction
 
-This document explains how the test data required for executing OF selftest
+This document explains how the test data required for executing OF unittest
 is attached to the live tree dynamically, independent of the machine's
 architecture.
 
@@ -22,31 +22,32 @@ most of the device drivers in various use cases.
 
 2. Test-data
 
-The Device Tree Source file (drivers/of/testcase-data/testcases.dts) contains
+The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
 the test data required for executing the unit tests automated in
-drivers/of/selftests.c. Currently, following Device Tree Source Include files
-(.dtsi) are included in testcase.dts:
+drivers/of/unittest.c. Currently, following Device Tree Source Include files
+(.dtsi) are included in testcases.dts:
 
-drivers/of/testcase-data/tests-interrupts.dtsi
-drivers/of/testcase-data/tests-platform.dtsi
-drivers/of/testcase-data/tests-phandle.dtsi
-drivers/of/testcase-data/tests-match.dtsi
+drivers/of/unittest-data/tests-interrupts.dtsi
+drivers/of/unittest-data/tests-platform.dtsi
+drivers/of/unittest-data/tests-phandle.dtsi
+drivers/of/unittest-data/tests-match.dtsi
+drivers/of/unittest-data/tests-overlay.dtsi
 
 When the kernel is build with OF_SELFTEST enabled, then the following make rule
 
 $(obj)/%.dtb: $(src)/%.dts FORCE
$(call if_changed_dep, dtc)
 
-is used to compile the DT source file (testcase.dts) into a binary blob
-(testcase.dtb), also referred as flattened DT.
+is used to compile the DT source file (testcases.dts) into a binary blob
+(testcases.dtb), also referred as flattened DT.
 
 After that, using the following rule the binary blob above is wrapped as an
-assembly file (testcase.dtb.S).
+assembly file (testcases.dtb.S).
 
 $(obj)/%.dtb.S: $(obj)/%.dtb
$(call cmd, dt_S_dtb)
 
-The assembly file is compiled into an object file (testcase.dtb.o), and is
+The assembly file is compiled into an object file (testcases.dtb.o), and is
 linked into the kernel image.
 
 
@@ -98,8 +99,8 @@ child11 -> sibling12 -> sibling13 -> sibling14 -> null
 Figure 1: Generic structure of un-flattened device tree
 
 
-Before executing OF selftest, it is required to attach the test data to
-machine's device tree (if present). So, when selftest_data_add() is called,
+Before executing OF unittest, it is required to attach the test data to
+machine's device tree (if present). So, when unittest_data_add() is called,
 at first it reads the flattened device tree data linked into the kernel image
 via the following kernel symbols:
 
@@ -186,10 +187,10 @@ update_node_properties().
 
 2.2. Removing the test data
 
-Once the test case execution is complete, selftest_data_remove is called in
+Once the test case execution is complete, unittest_data_remove is called in
 order to remove the device nodes attached initially (first the leaf nodes are
 detached and then moving up the parent nodes are removed, and eventually the
-whole tree). selftest_data_remove() calls detach_node_and_children() that uses
+whole tree). unittest_data_remove() calls detach_node_and_children() that uses
 of_detach_node() to detach the nodes from the live device tree.
 
 To detach a node, of_detach_node() either updates the child pointer of given
-- 
1.8.3.4

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


[PATCH 4/5] Documentation: rename of_selftest.txt to of_unittest.txt

2015-03-10 Thread Wang Long
Since the test of the devicetree's OF api use unittest as
its name. so we should rename of_selftest.txt to of_unittest.txt.

Signed-off-by: Wang Long 
---
 Documentation/devicetree/of_selftest.txt | 198 ---
 Documentation/devicetree/of_unittest.txt | 198 +++
 2 files changed, 198 insertions(+), 198 deletions(-)
 delete mode 100644 Documentation/devicetree/of_selftest.txt
 create mode 100644 Documentation/devicetree/of_unittest.txt

diff --git a/Documentation/devicetree/of_selftest.txt 
b/Documentation/devicetree/of_selftest.txt
deleted file mode 100644
index d79a6bc..000
--- a/Documentation/devicetree/of_selftest.txt
+++ /dev/null
@@ -1,198 +0,0 @@
-Open Firmware Device Tree Unittest
---
-
-Author: Gaurav Minocha 
-
-1. Introduction
-
-This document explains how the test data required for executing OF unittest
-is attached to the live tree dynamically, independent of the machine's
-architecture.
-
-It is recommended to read the following documents before moving ahead.
-
-[1] Documentation/devicetree/usage-model.txt
-[2] http://www.devicetree.org/Device_Tree_Usage
-
-OF Selftest has been designed to test the interface (include/linux/of.h)
-provided to device driver developers to fetch the device information..etc.
-from the unflattened device tree data structure. This interface is used by
-most of the device drivers in various use cases.
-
-
-2. Test-data
-
-The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
-the test data required for executing the unit tests automated in
-drivers/of/unittest.c. Currently, following Device Tree Source Include files
-(.dtsi) are included in testcases.dts:
-
-drivers/of/unittest-data/tests-interrupts.dtsi
-drivers/of/unittest-data/tests-platform.dtsi
-drivers/of/unittest-data/tests-phandle.dtsi
-drivers/of/unittest-data/tests-match.dtsi
-drivers/of/unittest-data/tests-overlay.dtsi
-
-When the kernel is build with OF_SELFTEST enabled, then the following make rule
-
-$(obj)/%.dtb: $(src)/%.dts FORCE
-   $(call if_changed_dep, dtc)
-
-is used to compile the DT source file (testcases.dts) into a binary blob
-(testcases.dtb), also referred as flattened DT.
-
-After that, using the following rule the binary blob above is wrapped as an
-assembly file (testcases.dtb.S).
-
-$(obj)/%.dtb.S: $(obj)/%.dtb
-   $(call cmd, dt_S_dtb)
-
-The assembly file is compiled into an object file (testcases.dtb.o), and is
-linked into the kernel image.
-
-
-2.1. Adding the test data
-
-Un-flattened device tree structure:
-
-Un-flattened device tree consists of connected device_node(s) in form of a tree
-structure described below.
-
-// following struct members are used to construct the tree
-struct device_node {
-...
-struct  device_node *parent;
-struct  device_node *child;
-struct  device_node *sibling;
-...
- };
-
-Figure 1, describes a generic structure of machine's un-flattened device tree
-considering only child and sibling pointers. There exists another pointer,
-*parent, that is used to traverse the tree in the reverse direction. So, at
-a particular level the child node and all the sibling nodes will have a parent
-pointer pointing to a common node (e.g. child1, sibling2, sibling3, sibling4's
-parent points to root node)
-
-root ('/')
-   |
-child1 -> sibling2 -> sibling3 -> sibling4 -> null
-   | |   |   |
-   | |   |  null
-   | |   |
-   | |child31 -> sibling32 -> null
-   | |   |  |
-   | |  null   null
-   | |
-   |  child21 -> sibling22 -> sibling23 -> null
-   | |  ||
-   |null   null null
-   |
-child11 -> sibling12 -> sibling13 -> sibling14 -> null
-   |   |   ||
-   |   |   |   null
-   |   |   |
-  nullnull   child131 -> null
-   |
-  null
-
-Figure 1: Generic structure of un-flattened device tree
-
-
-Before executing OF unittest, it is required to attach the test data to
-machine's device tree (if present). So, when unittest_data_add() is called,
-at first it reads the flattened device tree data linked into the kernel image
-via the following kernel symbols:
-
-__dtb_testcases_begin - address marking the start of test data blob
-__dtb_testcases_end   - address marking the end of test data blob
-
-Secondly, it calls of_fdt_unflatten_tree() to unflatten the flattened
-blob. And finally, if the machine's device tree (i.e live tree) is present,
-then it attaches the unflattened test data tree to the live tree, else it
-attaches itself as a live device tree.
-
-attach_node_and_children() uses of_attach_node() to attach the nodes into the
-live tree as explained below. To explain the same, the test data tree described
- in Figure 2 is 

[PATCH 2/5] of/unittest: Fix the wrong expected value in of_selftest_property_string

2015-03-10 Thread Wang Long
This patch fix the wrong expected value of of_property_match_string
in of_selftest_property_string.

Signed-off-by: Wang Long 
---
 drivers/of/unittest.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 199fb23..00ddce7 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -378,9 +378,9 @@ static void __init of_selftest_property_string(void)
rc = of_property_match_string(np, "phandle-list-names", "first");
selftest(rc == 0, "first expected:0 got:%i\n", rc);
rc = of_property_match_string(np, "phandle-list-names", "second");
-   selftest(rc == 1, "second expected:0 got:%i\n", rc);
+   selftest(rc == 1, "second expected:1 got:%i\n", rc);
rc = of_property_match_string(np, "phandle-list-names", "third");
-   selftest(rc == 2, "third expected:0 got:%i\n", rc);
+   selftest(rc == 2, "third expected:2 got:%i\n", rc);
rc = of_property_match_string(np, "phandle-list-names", "fourth");
selftest(rc == -ENODATA, "unmatched string; rc=%i\n", rc);
rc = of_property_match_string(np, "missing-property", "blah");
-- 
1.8.3.4

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


[PATCH 1/5] of/unittest: remove the duplicate of_changeset_init

2015-03-10 Thread Wang Long
Remove the duplicate of_changeset_init. In of_selftest_changeset
testcase, the "struct of_changeset chgset" is initialized twice,
but only once is enough. so, drop the first initializtion code.

Signed-off-by: Wang Long 
---
 drivers/of/unittest.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 0cf9a23..199fb23 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -478,7 +478,6 @@ static void __init of_selftest_changeset(void)
struct device_node *n1, *n2, *n21, *nremove, *parent, *np;
struct of_changeset chgset;
 
-   of_changeset_init();
n1 = __of_node_dup(NULL, "/testcase-data/changeset/n1");
selftest(n1, "testcase setup failure\n");
n2 = __of_node_dup(NULL, "/testcase-data/changeset/n2");
-- 
1.8.3.4

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


[PATCH 0/8] Add y2038 safe replacements for read_boot_clock(), read_persistent_clock() and update_persistent_clock()

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

read_boot_clock(), read_persistent_clock() and update_persistent_clock()
all use timespec which may have "y2038 problem", thus we are planning on
converting all of them to use timespec64.

The approach we're using is:
1) First of all, add the "__weak" implementaion of xxx_clock64() which uses
   xxx_clock() and timespec64.

   Let's take read_persistent_clock() as an example. We can create its
   y2038-safe version below:
void __weak read_persistent_clock64(struct timespec64 *ts64)
{
 struct timespec ts;

read_persistent_clock();
*ts64 = timespec_to_timespec64(ts);
}

   Then, replace all the call sites of xxx_clock() with xxx_clock64() except
   the one used by xxx_clock64().

2) Convert every architecture specific xxx_clock() to xxx_clock64() one by one.
   At this point, we can convert the three functions at a time if needed, 
because
   most time they're correlated.

3) Remove xxx_clock() after all its architecture specific implementations have 
been
   converted to use corresponding y2038 safe xxx_clock64().

This patchset firstly finished the step1 for all the three functions, then 
focused
on read_boot_clock() which is simple to go on with step2 and step3 as a whole 
show.

As for read_persistent_clock() and update_persistent_clock() which are more 
complex,
requiring many efforts to convert every architecture specific implementation 
gradually.

The approach used here is Suggested-by: "Arnd Bergmann "

Xunlei Pang (8):
  time: Add y2038 safe read_boot_clock64()
  time: Add y2038 safe read_persistent_clock64()
  time: Add y2038 safe update_persistent_clock64()
  ARM: OMAP: 32k counter: Provide y2038-safe
omap_read_persistent_clock() replacement
  ARM: tegra: clock: Provide y2038-safe tegra_read_persistent_clock()
replacement
  ARM: time: Provide read_boot_clock64() and read_persistent_clock64()
  s390: time: Provide read_boot_clock64() and read_persistent_clock64()
  time: Remove read_boot_clock()

 arch/arm/include/asm/mach/time.h|  3 +--
 arch/arm/kernel/time.c  |  6 +++---
 arch/arm/plat-omap/counter_32k.c| 18 ++
 arch/mips/lasat/sysctl.c|  4 ++--
 arch/s390/include/asm/timex.h   |  4 ++--
 arch/s390/kernel/debug.c|  4 ++--
 arch/s390/kernel/time.c |  6 +++---
 drivers/clocksource/tegra20_timer.c | 15 +++
 drivers/rtc/systohc.c   |  2 +-
 include/linux/timekeeping.h |  4 +++-
 kernel/time/ntp.c   | 13 -
 kernel/time/timekeeping.c   | 31 ---
 12 files changed, 58 insertions(+), 52 deletions(-)

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


Re: [PATCH 2/9] selftests: Add install target

2015-03-10 Thread Michael Ellerman
On Tue, 2015-03-10 at 09:11 -0600, Shuah Khan wrote:
> On 03/09/2015 04:29 PM, Shuah Khan wrote:
> > On 03/09/2015 08:20 AM, Shuah Khan wrote:
> >> On 03/05/2015 11:53 AM, Dave Jones wrote:
> >>> On Tue, Mar 03, 2015 at 03:51:35PM +1100, Michael Ellerman wrote:
> >>>  > This adds make install support to selftests. The basic usage is:
> >>>  > 
> >>>  > $ cd tools/testing/selftests
> >>>  > $ make install
> >>>  > 
> >>>  > That installs into tools/testing/selftests/install, which can then be
> >>>  > copied where ever necessary.
> >>>  > 
> >>>  > The install destination is also configurable using eg:
> >>>  > 
> >>>  > $ INSTALL_PATH=/mnt/selftests make install
> >>>
> >>>  ...
> >>>
> >>>  > +  @# Ask all targets to emit their test scripts
> >>>  > +  echo "#!/bin/bash\n\n" > $(ALL_SCRIPT)
> >>>
> >>> $ ./all.sh 
> >>> -bash: ./all.sh: /bin/bash\n\n: bad interpreter: No such file or directory
> >>>
> >>> Removing the \n\n fixes it.
> >>>
> >>>  > +  echo "cd \$$ROOT\n" >> $(ALL_SCRIPT); \
> >>>
> >>> ditto
> >>>
> >>>   Dave
> >>
> >> Michael,
> >>
> >> Could you please fix these problems and send the patch.
> >>
> > 
> > Michael,
> > 
> > Did you happen to run run_kselftest.sh from the install
> > directory to make sure all the dependent executables
> > are installed? You are missing a few required dependencies.
> > efivars test for example.
> > 
> > Please run kselftest_install.sh I sent out for review and
> > compare the following:
> > 
> > - contents of install directory created with your patch vs.
> >   my kselftest_install.sh tool
> > - Compare your run_kselftest.sh run with the one that gets
> >   generated with my kselftest_install.sh tool
> > 
> > General rule is all tests that get run when run_tests target
> > is run should run from the install directory using the
> > run_kselftest.sh generated during install.
> > 
> 
> Couple more things. Please change the install directory name
> to kselftest
> 
> tools/testing/selftests/kselftest
> instead of
> tools/testing/selftests/install

I prefer install, that's what it is after all. I don't know why you're so
obsessed with the "kselftest" name.

> Also please flatten the directory structure under the install
> directory. I don't see any value in creating directory for each
> test for install. Also it is makes it cumbersome for users
> to navigate and work with after the install. This would mean cpu
> and memory hot-plug scripts need unique names.

That's not a good idea. To start with different tests might the same name, as
already happens with the memory & cpu hot-plug tests. They may also have data
files that would clobber each other. We'd need to make sure all files used in
all tests have different names, that would be a total mess.

cheers


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


[PATCH 1/8] time: Add y2038 safe read_boot_clock64()

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

As part of addressing in-kernel y2038 issues, this patch adds
read_boot_clock64() and replaces all the call sites of read_boot_clock()
with this function. This is a __weak implementation, which simply
calls the existing y2038 unsafe read_boot_clock().

This allows architecture specific implementations to be converted
independently, and eventually the y2038 unsafe read_boot_clock()
can be removed after all its architecture specific implementations
have been converted to read_boot_clock64().

Suggested-by: Arnd Bergmann 
Signed-off-by: Xunlei Pang 
---
 include/linux/timekeeping.h |  1 +
 kernel/time/timekeeping.c   | 11 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 3eaae47..d53c522 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -263,6 +263,7 @@ static inline bool has_persistent_clock(void)
 
 extern void read_persistent_clock(struct timespec *ts);
 extern void read_boot_clock(struct timespec *ts);
+extern void read_boot_clock64(struct timespec64 *ts);
 extern int update_persistent_clock(struct timespec now);
 
 
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 91db941..7080c21 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1072,6 +1072,14 @@ void __weak read_boot_clock(struct timespec *ts)
ts->tv_nsec = 0;
 }
 
+void __weak read_boot_clock64(struct timespec64 *ts64)
+{
+   struct timespec ts;
+
+   read_boot_clock();
+   *ts64 = timespec_to_timespec64(ts);
+}
+
 /*
  * timekeeping_init - Initializes the clocksource and common timekeeping values
  */
@@ -1093,8 +1101,7 @@ void __init timekeeping_init(void)
} else if (now.tv_sec || now.tv_nsec)
persistent_clock_exist = true;
 
-   read_boot_clock();
-   boot = timespec_to_timespec64(ts);
+   read_boot_clock64();
if (!timespec64_valid_strict()) {
pr_warn("WARNING: Boot clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
-- 
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/


[PATCH 4/8] ARM: OMAP: 32k counter: Provide y2038-safe omap_read_persistent_clock() replacement

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

As part of addressing "y2038 problem" for in-kernel uses, this
patch adds the y2038-safe omap_read_persistent_clock64() using
timespec64.

Because we rely on some subsequent changes to convert arm multiarch
support, omap_read_persistent_clock() will be removed then.

Also remove the needless spinlock, because read_persistent_clock()
doesn't run simultaneously.

Signed-off-by: Xunlei Pang 
---
 arch/arm/plat-omap/counter_32k.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 61b4d70..d422e36 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -44,24 +44,20 @@ static u64 notrace omap_32k_read_sched_clock(void)
 }
 
 /**
- * omap_read_persistent_clock -  Return time from a persistent clock.
+ * omap_read_persistent_clock64 -  Return time from a persistent clock.
  *
  * Reads the time from a source which isn't disabled during PM, the
  * 32k sync timer.  Convert the cycles elapsed since last read into
- * nsecs and adds to a monotonically increasing timespec.
+ * nsecs and adds to a monotonically increasing timespec64.
  */
-static struct timespec persistent_ts;
+static struct timespec64 persistent_ts;
 static cycles_t cycles;
 static unsigned int persistent_mult, persistent_shift;
-static DEFINE_SPINLOCK(read_persistent_clock_lock);
 
-static void omap_read_persistent_clock(struct timespec *ts)
+static void omap_read_persistent_clock64(struct timespec64 *ts)
 {
unsigned long long nsecs;
cycles_t last_cycles;
-   unsigned long flags;
-
-   spin_lock_irqsave(_persistent_clock_lock, flags);
 
last_cycles = cycles;
cycles = sync32k_cnt_reg ? readl_relaxed(sync32k_cnt_reg) : 0;
@@ -69,11 +65,17 @@ static void omap_read_persistent_clock(struct timespec *ts)
nsecs = clocksource_cyc2ns(cycles - last_cycles,
persistent_mult, persistent_shift);
 
-   timespec_add_ns(_ts, nsecs);
+   timespec64_add_ns(_ts, nsecs);
 
*ts = persistent_ts;
+}
+
+static void omap_read_persistent_clock(struct timespec *ts)
+{
+   struct timespec64 ts64;
 
-   spin_unlock_irqrestore(_persistent_clock_lock, flags);
+   omap_read_persistent_clock64();
+   *ts = timespec64_to_timespec(ts64);
 }
 
 /**
-- 
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/


[PATCH 2/8] time: Add y2038 safe read_persistent_clock64()

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

As part of addressing in-kernel y2038 issues, this patch adds
read_persistent_clock64() and replaces all the call sites of
read_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
read_persistent_clock().

This allows architecture specific implementations to be converted
independently, and eventually the y2038 unsafe read_persistent_clock()
can be removed after all its architecture specific implementations
have been converted to read_persistent_clock64().

Suggested-by: Arnd Bergmann 
Signed-off-by: Xunlei Pang 
---
 arch/mips/lasat/sysctl.c|  4 ++--
 include/linux/timekeeping.h |  1 +
 kernel/time/timekeeping.c   | 22 --
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/mips/lasat/sysctl.c b/arch/mips/lasat/sysctl.c
index 3b7f65c..cf9b4633 100644
--- a/arch/mips/lasat/sysctl.c
+++ b/arch/mips/lasat/sysctl.c
@@ -75,11 +75,11 @@ static int rtctmp;
 int proc_dolasatrtc(struct ctl_table *table, int write,
   void *buffer, size_t *lenp, loff_t *ppos)
 {
-   struct timespec ts;
+   struct timespec64 ts;
int r;
 
if (!write) {
-   read_persistent_clock();
+   read_persistent_clock64();
rtctmp = ts.tv_sec;
/* check for time < 0 and set to 0 */
if (rtctmp < 0)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index d53c522..ff56a0f 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -262,6 +262,7 @@ static inline bool has_persistent_clock(void)
 }
 
 extern void read_persistent_clock(struct timespec *ts);
+extern void read_persistent_clock64(struct timespec64 *ts);
 extern void read_boot_clock(struct timespec *ts);
 extern void read_boot_clock64(struct timespec64 *ts);
 extern int update_persistent_clock(struct timespec now);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 7080c21..0e5a696 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1057,6 +1057,14 @@ void __weak read_persistent_clock(struct timespec *ts)
ts->tv_nsec = 0;
 }
 
+void __weak read_persistent_clock64(struct timespec64 *ts64)
+{
+   struct timespec ts;
+
+   read_persistent_clock();
+   *ts64 = timespec_to_timespec64(ts);
+}
+
 /**
  * read_boot_clock -  Return time of the system start.
  *
@@ -1089,10 +1097,8 @@ void __init timekeeping_init(void)
struct clocksource *clock;
unsigned long flags;
struct timespec64 now, boot, tmp;
-   struct timespec ts;
 
-   read_persistent_clock();
-   now = timespec_to_timespec64(ts);
+   read_persistent_clock64();
if (!timespec64_valid_strict()) {
pr_warn("WARNING: Persistent clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
@@ -1163,7 +1169,7 @@ static void __timekeeping_inject_sleeptime(struct 
timekeeper *tk,
  * timekeeping_inject_sleeptime64 - Adds suspend interval to timeekeeping 
values
  * @delta: pointer to a timespec64 delta value
  *
- * This hook is for architectures that cannot support read_persistent_clock
+ * This hook is for architectures that cannot support read_persistent_clock64
  * because their RTC/persistent clock is only accessible when irqs are enabled.
  *
  * This function should only be called by rtc_resume(), and allows
@@ -1210,12 +1216,10 @@ void timekeeping_resume(void)
struct clocksource *clock = tk->tkr.clock;
unsigned long flags;
struct timespec64 ts_new, ts_delta;
-   struct timespec tmp;
cycle_t cycle_now, cycle_delta;
bool suspendtime_found = false;
 
-   read_persistent_clock();
-   ts_new = timespec_to_timespec64(tmp);
+   read_persistent_clock64(_new);
 
clockevents_resume();
clocksource_resume();
@@ -1291,10 +1295,8 @@ int timekeeping_suspend(void)
unsigned long flags;
struct timespec64   delta, delta_delta;
static struct timespec64old_delta;
-   struct timespec tmp;
 
-   read_persistent_clock();
-   timekeeping_suspend_time = timespec_to_timespec64(tmp);
+   read_persistent_clock64(_suspend_time);
 
/*
 * On some systems the persistent_clock can not be detected at
-- 
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/


[PATCH 3/8] time: Add y2038 safe update_persistent_clock64()

2015-03-10 Thread Xunlei Pang
From: Xunlei Pang 

As part of addressing in-kernel y2038 issues, this patch adds
update_persistent_clock64() and replaces all the call sites of
update_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
update_persistent_clock().

This allows architecture specific implementations to be converted
independently, and eventually y2038-unsafe update_persistent_clock()
can be removed after all its architecture specific implementations
have been converted to update_persistent_clock64().

Suggested-by: Arnd Bergmann 
Signed-off-by: Xunlei Pang 
---
 drivers/rtc/systohc.c   |  2 +-
 include/linux/timekeeping.h |  1 +
 kernel/time/ntp.c   | 13 -
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/systohc.c b/drivers/rtc/systohc.c
index eb71872..ef3c07a 100644
--- a/drivers/rtc/systohc.c
+++ b/drivers/rtc/systohc.c
@@ -11,7 +11,7 @@
  * rtc_set_ntp_time - Save NTP synchronized time to the RTC
  * @now: Current time of day
  *
- * Replacement for the NTP platform function update_persistent_clock
+ * Replacement for the NTP platform function update_persistent_clock64
  * that stores time for later retrieval by rtc_hctosys.
  *
  * Returns 0 on successful RTC update, -ENODEV if a RTC update is not
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index ff56a0f..a7fa96b 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -266,6 +266,7 @@ extern void read_persistent_clock64(struct timespec64 *ts);
 extern void read_boot_clock(struct timespec *ts);
 extern void read_boot_clock64(struct timespec64 *ts);
 extern int update_persistent_clock(struct timespec now);
+extern int update_persistent_clock64(struct timespec64 now);
 
 
 #endif
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 0f60b08..42d1bc7 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -459,6 +459,16 @@ out:
return leap;
 }
 
+#ifdef CONFIG_GENERIC_CMOS_UPDATE
+int __weak update_persistent_clock64(struct timespec64 now64)
+{
+   struct timespec now;
+
+   now = timespec64_to_timespec(now64);
+   return update_persistent_clock(now);
+}
+#endif
+
 #if defined(CONFIG_GENERIC_CMOS_UPDATE) || defined(CONFIG_RTC_SYSTOHC)
 static void sync_cmos_clock(struct work_struct *work);
 
@@ -494,8 +504,9 @@ static void sync_cmos_clock(struct work_struct *work)
if (persistent_clock_is_local)
adjust.tv_sec -= (sys_tz.tz_minuteswest * 60);
 #ifdef CONFIG_GENERIC_CMOS_UPDATE
-   fail = update_persistent_clock(timespec64_to_timespec(adjust));
+   fail = update_persistent_clock64(adjust);
 #endif
+
 #ifdef CONFIG_RTC_SYSTOHC
if (fail == -ENODEV)
fail = rtc_set_ntp_time(adjust);
-- 
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/


Re: [PATCH 2/9] selftests: Add install target

2015-03-10 Thread Dave Jones
On Wed, Mar 11, 2015 at 02:15:10PM +1100, Michael Ellerman wrote:
 > On Thu, 2015-03-05 at 13:53 -0500, Dave Jones wrote:
 > > $ ./all.sh 
 > > -bash: ./all.sh: /bin/bash\n\n: bad interpreter: No such file or directory
 > > 
 > > Removing the \n\n fixes it.
 > > 
 > >  > +   echo "cd \$$ROOT\n" >> $(ALL_SCRIPT); \
 > > 
 > > ditto
 > 
 > Weird, I don't see that.
 > 
 >   $ make install
 >   $ head install/run_kselftest.sh
 >   #!/bin/bash
 >   
 >   
 >   cd $(dirname $0)
 > 
 > 
 > Does it depend on the shell? I guess none of the newlines are necessary so 
 > I'll
 > just remove them.

Dunno, bash here too. Maybe the version ? My environment at the office is a 
little
dated. (It's based on ye olde ubuntu lts)

Dave

--
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] soc: Mediatek: Add SCPSYS power domain driver

2015-03-10 Thread James Liao
Hi,

On Tue, 2015-03-10 at 10:41 +0100, Sascha Hauer wrote:
> On Mon, Mar 09, 2015 at 02:35:03PM -0700, Kevin Hilman wrote:
> > Sascha Hauer  writes:
> > 
> > > Signed-off-by: Sascha Hauer 
> > 
> > A bit of a changelog here would be useful describing this driver, that
> > it's only covering part of the device (e.g. power controller) with more
> > to come, dependency on the syscon driver, etc.
> > 
> > > +/*
> > > + * The Infracfg unit has bus protection bits. We enable the bus 
> > > protection
> > > + * for disabled power domains so that the system does not hang when some 
> > > unit
> > > + * accesses the bus while in power down.
> > > + */
> > 
> > Hmm, why don't you want to know if some device is accessing another
> > device which is in a domain that is powered down?   Seems like this is a
> > good way to hide real bugs.
> 
> How I understand it the system just hangs on erroneous accesses without
> these protection bits enabled, so enabling them at least makes sure we
> can output something.
> I must admit though that my understanding of these bits is quite limited
> and the only user of this driver I have available here (audio) doesn't
> make use of these protection bits, so I can't test here.
> 
> James, could you shed some light on this issue?

I asked our designer about the bus protection feature, here is his
response:

"
It's for unexpected signal glitch in Power switch process.

During Power switch process, we have clock switch, reset, isolation
enable/disable and  power switch involved where the transition of
asynchronous reset and  isolation is the most critical one,  which have
risk to introduce a unexpected short period signal transition from
MTCMOS’s interface to other alive HW . 
"

That means it protects unexpected bus accessing from HW, not from SW. So
it will not hide bugs from wrong SW access.


Best regards,

James

* Email Confidentiality Notice 
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. 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 2/9] selftests: Add install target

2015-03-10 Thread Michael Ellerman
On Thu, 2015-03-05 at 13:53 -0500, Dave Jones wrote:
> On Tue, Mar 03, 2015 at 03:51:35PM +1100, Michael Ellerman wrote:
>  > This adds make install support to selftests. The basic usage is:
>  > 
>  > $ cd tools/testing/selftests
>  > $ make install
>  > 
>  > That installs into tools/testing/selftests/install, which can then be
>  > copied where ever necessary.
>  > 
>  > The install destination is also configurable using eg:
>  > 
>  > $ INSTALL_PATH=/mnt/selftests make install
> 
>  ...
> 
>  > +  @# Ask all targets to emit their test scripts
>  > +  echo "#!/bin/bash\n\n" > $(ALL_SCRIPT)
> 
> $ ./all.sh 
> -bash: ./all.sh: /bin/bash\n\n: bad interpreter: No such file or directory
> 
> Removing the \n\n fixes it.
> 
>  > +  echo "cd \$$ROOT\n" >> $(ALL_SCRIPT); \
> 
> ditto

Weird, I don't see that.

  $ make install
  $ head install/run_kselftest.sh
  #!/bin/bash
  
  
  cd $(dirname $0)


Does it depend on the shell? I guess none of the newlines are necessary so I'll
just remove them.

cheers


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


[PATCH v8 0/2] Add Spreadtrum Sharkl64 Platform support

2015-03-10 Thread 张春艳
This patchset adds Spreadtrum's Sharkl64 support in arm64 device tree.

Changes from v7:
- Added Mark Rutland's Acked-by
- Rebased v4.0-rc1

Changes from v6:
- Setted stdout-path with "serial1:115200n8"

Changes from v5:
- Added maintenance interrupt for gic
- Removed reg property from 'soc' and 'apb' nodes


Zhizhou Zhang (2):
  arm64: dts: Add support for Spreadtrum SC9836 SoC in dts and Makefile
  arm64: Add support for Spreadtrum's Sharkl64 Platform in Kconfig and
defconfig

 arch/arm64/Kconfig|  5 ++
 arch/arm64/boot/dts/Makefile  |  1 +
 arch/arm64/boot/dts/sprd/Makefile |  5 ++
 arch/arm64/boot/dts/sprd/sc9836-openphone.dts | 49 ++
 arch/arm64/boot/dts/sprd/sc9836.dtsi  | 74 +++
 arch/arm64/boot/dts/sprd/sharkl64.dtsi| 65 +++
 arch/arm64/configs/defconfig  |  1 +
 7 files changed, 200 insertions(+)
 create mode 100644 arch/arm64/boot/dts/sprd/Makefile
 create mode 100644 arch/arm64/boot/dts/sprd/sc9836-openphone.dts
 create mode 100644 arch/arm64/boot/dts/sprd/sc9836.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sharkl64.dtsi

-- 
1.9.1


[PATCH v8 2/2] arm64: Add support for Spreadtrum's Sharkl64 Platform in Kconfig and defconfig

2015-03-10 Thread 张春艳
From: Zhizhou Zhang 

Adds support for Spreadtrum's SoC Platform in the arm64 Kconfig and
defconfig files.

Signed-off-by: Zhizhou Zhang 
Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
---
 arch/arm64/Kconfig   | 5 +
 arch/arm64/configs/defconfig | 1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..e582fe2 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -208,6 +208,11 @@ config ARCH_TEGRA_132_SOC
  but contains an NVIDIA Denver CPU complex in place of
  Tegra124's "4+1" Cortex-A15 CPU complex.
 
+config ARCH_SPRD
+   bool "Spreadtrum SoC platform"
+   help
+ Support for Spreadtrum ARM based SoCs
+
 config ARCH_THUNDER
bool "Cavium Inc. Thunder SoC Family"
help
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index be1f12a..535307c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -33,6 +33,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_FSL_LS2085A=y
 CONFIG_ARCH_MEDIATEK=y
+CONFIG_ARCH_SPRD=y
 CONFIG_ARCH_THUNDER=y
 CONFIG_ARCH_VEXPRESS=y
 CONFIG_ARCH_XGENE=y
-- 
1.9.1
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf"�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

[PATCH v8 1/2] arm64: dts: Add support for Spreadtrum SC9836 SoC in dts and Makefile

2015-03-10 Thread 张春艳
From: Zhizhou Zhang 

Adds the device tree support for Spreadtrum SC9836 SoC which is based on
Sharkl64 platform.

Sharkl64 platform contains the common nodes of Spreadtrum's arm64-based SoCs.

Signed-off-by: Zhizhou Zhang 
Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
Acked-by: Mark Rutland 
---
 arch/arm64/boot/dts/Makefile  |  1 +
 arch/arm64/boot/dts/sprd/Makefile |  5 ++
 arch/arm64/boot/dts/sprd/sc9836-openphone.dts | 49 ++
 arch/arm64/boot/dts/sprd/sc9836.dtsi  | 74 +++
 arch/arm64/boot/dts/sprd/sharkl64.dtsi| 65 +++
 5 files changed, 194 insertions(+)
 create mode 100644 arch/arm64/boot/dts/sprd/Makefile
 create mode 100644 arch/arm64/boot/dts/sprd/sc9836-openphone.dts
 create mode 100644 arch/arm64/boot/dts/sprd/sc9836.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sharkl64.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index e0350ca..930f7f8 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -5,5 +5,6 @@ dts-dirs += cavium
 dts-dirs += exynos
 dts-dirs += freescale
 dts-dirs += mediatek
+dts-dirs += sprd
 
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/Makefile 
b/arch/arm64/boot/dts/sprd/Makefile
new file mode 100644
index 000..b658c5e
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/sprd/sc9836-openphone.dts 
b/arch/arm64/boot/dts/sprd/sc9836-openphone.dts
new file mode 100644
index 000..e5657c3
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9836-openphone.dts
@@ -0,0 +1,49 @@
+/*
+ * Spreadtrum SC9836 openphone board DTS file
+ *
+ * Copyright (C) 2014, Spreadtrum Communications Inc.
+ *
+ * This file is licensed under a dual GPLv2 or X11 license.
+ */
+
+/dts-v1/;
+
+#include "sc9836.dtsi"
+
+/ {
+   model = "Spreadtrum SC9836 Openphone Board";
+
+   compatible = "sprd,sc9836-openphone", "sprd,sc9836";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0 0x8000 0 0x2000>;
+   };
+
+   chosen {
+   stdout-path = "serial1:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/sprd/sc9836.dtsi 
b/arch/arm64/boot/dts/sprd/sc9836.dtsi
new file mode 100644
index 000..f92f1b4
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9836.dtsi
@@ -0,0 +1,74 @@
+/*
+ * Spreadtrum SC9836 SoC DTS file
+ *
+ * Copyright (C) 2014, Spreadtrum Communications Inc.
+ *
+ * This file is licensed under a dual GPLv2 or X11 license.
+ */
+
+#include "sharkl64.dtsi"
+#include 
+
+/ {
+   compatible = "sprd,sc9836";
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   };
+
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+   };
+
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x3>;
+   enable-method = "psci";
+   };
+   };
+
+   gic: interrupt-controller@12001000 {
+   compatible = "arm,gic-400";
+   reg = <0 0x12001000 0 0x1000>,
+ <0 0x12002000 0 0x2000>,
+ <0 0x12004000 0 0x2000>,
+ <0 0x12006000 0 0x2000>;
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   interrupts = ;
+   };
+
+   psci {
+   compatible  = "arm,psci";
+   method  = "smc";
+   cpu_on  = <0xc403>;
+   cpu_off = <0x8402>;
+   cpu_suspend = <0xc401>;
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+

Re: [PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module

2015-03-10 Thread Chen-Yu Tsai
On Wed, Mar 11, 2015 at 5:32 AM, Maxime Ripard
 wrote:
> On Tue, Mar 10, 2015 at 07:59:24PM +0800, Chen-Yu Tsai wrote:
>> The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The
>> WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO.
>> The IC also takes a power enable signal via GPIO. This is supported
>> with the new power sequencing bindings.
>>
>> The WiFi module supports out-of-band interrupt signaling via GPIO,
>> but this is buggy and not enabled yet.
>>
>> Signed-off-by: Chen-Yu Tsai 
>
> There's two almost identical patches 12/12. Which one am I suppose to
> apply?

This one is the right one. I forgot to clear the patches after changing
the description. The "buggy" part in the description is probably not
needed. Hans explained that the SD resets have nothing to do with
interrupt handling.


ChenYu
--
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/2] Documentation: update the of_selftest.txt

2015-03-10 Thread long.wanglong
On 2015/3/10 23:16, Gaurav Minocha wrote:
> Hi Rob,
> 
> On Mar 10, 2015 7:51 AM, "Rob Herring"  > wrote:
>>
>> On Tue, Mar 10, 2015 at 9:44 AM, Rob Herring > > wrote:
>> > On Sun, Mar 8, 2015 at 9:35 PM, Wang Long > > > wrote:
>> >> Since the directory "drivers/of/testcase-data" is renamed
>> >> to "drivers/of/unittest-data". so we should update the path
>> >> in the of_selftest.txt.
>>
>> [...]
>>
>> >> -Before executing OF selftest, it is required to attach the test data to
>> >> +Before executing OF unittest, it is required to attach the test data to
>> >>  machine's device tree (if present). So, when selftest_data_add() is 
>> >> called,
>> >
>> > This one too.
>>
>> Or not. The functions are all still "selftest". Not sure why Grant
>> left all those...
> 
> I will send a patch to replace the selftest with unitest also will update the 
> document if required..
> 
Hi Gaurav, Rob

I have done the work. before replacing the selftest with unittest, i will fix 
some error in OF unittest.
Please review my patch, and give me some advices.

Thanks.

Best Regards
Wang Long

>>
>> Rob
> 


--
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] video: mxsfb: Make sure axi clock is enabled when accessing registers

2015-03-10 Thread Liu Ying
On Tue, Mar 10, 2015 at 02:02:37PM +0200, Tomi Valkeinen wrote:
> On 04/03/15 09:06, Liu Ying wrote:
> > The LCDIF engines embedded in i.MX6sl and i.MX6sx SoCs need the axi clock
> > as the engine's system clock.  The clock should be enabled when accessing
> > LCDIF registers, otherwise the kernel would hang up.  We should also keep
> > the clock being enabled when the engine is being active to scan out frames
> 
> The text above is a bit confusing. Maybe just "... also keep the clock
> enabled when..."

Okay.

> 
> > from memory.  This patch makes sure the axi clock is enabled when accessing
> > registers so that the kernel hang up issue can be fixed.
> > 
> > Reported-by: Peter Chen 
> > Tested-by: Peter Chen 
> > Cc:  # 3.19+
> > Signed-off-by: Liu Ying 
> > ---
> > v1->v2:
> > * Add 'Tested-by: Peter Chen ' tag.
> > * Add 'Cc:  # 3.19+' tag.
> > 
> >  drivers/video/fbdev/mxsfb.c | 70 
> > -
> >  1 file changed, 56 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
> > index f8ac4a4..a8cf3b2 100644
> > --- a/drivers/video/fbdev/mxsfb.c
> > +++ b/drivers/video/fbdev/mxsfb.c
> > @@ -316,6 +316,18 @@ static int mxsfb_check_var(struct fb_var_screeninfo 
> > *var,
> > return 0;
> >  }
> >  
> > +static inline void mxsfb_enable_axi_clk(struct mxsfb_info *host)
> > +{
> > +   if (host->clk_axi)
> > +   clk_prepare_enable(host->clk_axi);
> > +}
> > +
> > +static inline void mxsfb_disable_axi_clk(struct mxsfb_info *host)
> > +{
> > +   if (host->clk_axi)
> > +   clk_disable_unprepare(host->clk_axi);
> > +}
> > +
> >  static void mxsfb_enable_controller(struct fb_info *fb_info)
> >  {
> > struct mxsfb_info *host = to_imxfb_host(fb_info);
> > @@ -333,14 +345,13 @@ static void mxsfb_enable_controller(struct fb_info 
> > *fb_info)
> > }
> > }
> >  
> > -   if (host->clk_axi)
> > -   clk_prepare_enable(host->clk_axi);
> > -
> > if (host->clk_disp_axi)
> > clk_prepare_enable(host->clk_disp_axi);
> > clk_prepare_enable(host->clk);
> > clk_set_rate(host->clk, PICOS2KHZ(fb_info->var.pixclock) * 1000U);
> >  
> > +   mxsfb_enable_axi_clk(host);
> > +
> 
> Is there some reason to move the clk enable to a different place here?

Moving it to here reflects better that we need to enable it when accessing the
registers.

Another reason is weak, perhaps.  We've got an unannounced new SoC(not yet get
upstreamed).  It has a LCDIF embedded.  The pixel clock(host->clk) and the axi
clock are derived from a same clock gate.  And, the clock gate is defined with
the flag CLK_SET_RATE_GATE, which means it must be gated across rate change.
So, we need to move it beneath clk_set_rate() for the pixel clock sooner or
later.

> 
> > /* if it was disabled, re-enable the mode again */
> > writel(CTRL_DOTCLK_MODE, host->base + LCDC_CTRL + REG_SET);
> >  
> > @@ -380,11 +391,11 @@ static void mxsfb_disable_controller(struct fb_info 
> > *fb_info)
> > reg = readl(host->base + LCDC_VDCTRL4);
> > writel(reg & ~VDCTRL4_SYNC_SIGNALS_ON, host->base + LCDC_VDCTRL4);
> >  
> > +   mxsfb_disable_axi_clk(host);
> > +
> > clk_disable_unprepare(host->clk);
> > if (host->clk_disp_axi)
> > clk_disable_unprepare(host->clk_disp_axi);
> > -   if (host->clk_axi)
> > -   clk_disable_unprepare(host->clk_axi);
> 
> And same here for disable.

This is to make sure the clock disable order is exactly reversed, comparing to
the clock enable order.

> 
> > host->enabled = 0;
> >  
> > @@ -421,6 +432,8 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> > mxsfb_disable_controller(fb_info);
> > }
> >  
> > +   mxsfb_enable_axi_clk(host);
> > +
> > /* clear the FIFOs */
> > writel(CTRL1_FIFO_CLEAR, host->base + LCDC_CTRL1 + REG_SET);
> >  
> > @@ -438,6 +451,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> > ctrl |= CTRL_SET_WORD_LENGTH(3);
> > switch (host->ld_intf_width) {
> > case STMLCDIF_8BIT:
> > +   mxsfb_disable_axi_clk(host);
> > dev_err(>pdev->dev,
> > "Unsupported LCD bus width mapping\n");
> > return -EINVAL;
> > @@ -451,6 +465,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> > writel(CTRL1_SET_BYTE_PACKAGING(0x7), host->base + LCDC_CTRL1);
> > break;
> > default:
> > +   mxsfb_disable_axi_clk(host);
> > dev_err(>pdev->dev, "Unhandled color depth of %u\n",
> > fb_info->var.bits_per_pixel);
> > return -EINVAL;
> > @@ -504,6 +519,8 @@ static int mxsfb_set_par(struct fb_info *fb_info)
> > fb_info->fix.line_length * fb_info->var.yoffset,
> > host->base + host->devdata->next_buf);
> >  
> > +   mxsfb_disable_axi_clk(host);
> > +
> > if (reenable)
> > 

Re: node-hotplug: is memset 0 safe in try_offline_node()?

2015-03-10 Thread Xie XiuQi
On 2015/3/11 9:12, Gu Zheng wrote:
> Hi Xishi,
> 
> What is the condition of this problem now?

Hi Gu,

I have no machine to do this test now. But I've tested the
patch "just remove memset 0" more than 20 hours last week,
it's OK.

Thanks,
Xie XiuQi

> 
> Regards,
> Gu
> On 03/05/2015 05:39 PM, Xishi Qiu wrote:
> 
>> On 2015/3/5 16:26, Gu Zheng wrote:
>>
>>> Hi Xishi,
>>> Could you please try the following one?
>>> It postpones the reset of obsolete pgdat from try_offline_node() to
>>> hotadd_new_pgdat(), and just resetting pgdat->nr_zones and
>>> pgdat->classzone_idx to be 0 rather than the whole reset by memset()
>>> as Kame suggested.
>>>
>>> Regards,
>>> Gu
>>>
>>> ---
>>>  mm/memory_hotplug.c |   13 -
>>>  1 files changed, 4 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index 1778628..c17eebf 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -1092,6 +1092,10 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, 
>>> u64 start)
>>> return NULL;
>>>  
>>> arch_refresh_nodedata(nid, pgdat);
>>> +   } else {
>>> +   /* Reset the nr_zones and classzone_idx to 0 before reuse */
>>> +   pgdat->nr_zones = 0;
>>> +   pgdat->classzone_idx = 0;
>>
>> Hi Gu,
>>
>> This is just to avoid the warning, I think it's no meaning.
>> Here is the changlog from the original patch:
>>
>> commit 88fdf75d1bb51d85ba00c466391770056d44bc03
>> ...
>> Warn if memory-hotplug/boot code doesn't initialize pg_data_t with zero
>> when it is allocated.  Arch code and memory hotplug already initiailize
>> pg_data_t.  So this warning should never happen.  I select fields 
>> *randomly*
>> near the beginning, middle and end of pg_data_t for checking.
>> ...
>>
>> Thanks,
>> Xishi Qiu
>>
>>> }
>>>  
>>> /* we can use NODE_DATA(nid) from here */
>>> @@ -2021,15 +2025,6 @@ void try_offline_node(int nid)
>>>  
>>> /* notify that the node is down */
>>> call_node_notify(NODE_DOWN, (void *)(long)nid);
>>> -
>>> -   /*
>>> -* Since there is no way to guarentee the address of pgdat/zone is not
>>> -* on stack of any kernel threads or used by other kernel objects
>>> -* without reference counting or other symchronizing method, do not
>>> -* reset node_data and free pgdat here. Just reset it to 0 and reuse
>>> -* the memory when the node is online again.
>>> -*/
>>> -   memset(pgdat, 0, sizeof(*pgdat));
>>>  }
>>>  EXPORT_SYMBOL(try_offline_node);
>>>  
>>
>>
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
>> .
>>
> 
> 
> --
> 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] dma: Add Xilinx ZDMA device tree Binding Documentation

2015-03-10 Thread punnaiah choudary kalluri
On Wed, Mar 11, 2015 at 5:31 AM, Sören Brinkmann
 wrote:
> On Tue, 2015-03-10 at 07:46PM +0530, Punnaiah Choudary Kalluri wrote:
>> Device-tree binding documentation for Xilinx ZDMA Engine
>>
>> Signed-off-by: Punnaiah Choudary Kalluri 
>> ---
>>  .../devicetree/bindings/dma/xilinx/zdma.txt|   76 
>> 
>>  1 files changed, 76 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zdma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zdma.txt 
>> b/Documentation/devicetree/bindings/dma/xilinx/zdma.txt
>> new file mode 100644
>> index 000..399a3bc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/xilinx/zdma.txt
>> @@ -0,0 +1,76 @@
>> +Xilinx ZDMA 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.
>> +
>> +Xilinx ZynqMP has two instances of general purpose DMA(ZDMA).
>> +one is located in FPD(full power domain) and other is located in
>> +LPD(low power domain).
>> +
>> +ZDMA instance located in FPD is referred as FPDMA and instance located
>> +in LPD is referred as LPDMA.
>> +
>> +FPDMA is configured with 8 DMA channels and AXI bus width is 128 byte.
>> +LPDMA is configured with 8 DMA channels and AXI bus width is 64 byte.
>
> All these implementation details are good background information, but
> shouldn't be part of the binding.

Ok. i will remove then.

Thanks.
Punnaiah
>
> Sören
> --
> 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] dma: Add Xilinx ZDMA device tree Binding Documentation

2015-03-10 Thread punnaiah choudary kalluri
On Wed, Mar 11, 2015 at 5:27 AM, Josh Cartwright  wrote:
> On Tue, Mar 10, 2015 at 07:46:23PM +0530, Punnaiah Choudary Kalluri wrote:
>> Device-tree binding documentation for Xilinx ZDMA Engine
>>
>> Signed-off-by: Punnaiah Choudary Kalluri 
>> ---
>
> Hey Punnaiah-
>
> Was this intended to be sent out with a driver?

First I would like to complete my review for device tree bindings and
then planning to send the driver for review. please let me know if this is not
the right way to do?

>
>>  .../devicetree/bindings/dma/xilinx/zdma.txt|   76 
>> 
>>  1 files changed, 76 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zdma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zdma.txt 
>> b/Documentation/devicetree/bindings/dma/xilinx/zdma.txt
>> new file mode 100644
>> index 000..399a3bc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/xilinx/zdma.txt
>> @@ -0,0 +1,76 @@
>> +Xilinx ZDMA 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.
>> +
>> +Xilinx ZynqMP has two instances of general purpose DMA(ZDMA).
>> +one is located in FPD(full power domain) and other is located in
>> +LPD(low power domain).
>> +
>> +ZDMA instance located in FPD is referred as FPDMA and instance located
>> +in LPD is referred as LPDMA.
>> +
>> +FPDMA is configured with 8 DMA channels and AXI bus width is 128 byte.
>> +LPDMA is configured with 8 DMA channels and AXI bus width is 64 byte.
>> +
>> +Each channel in a instance has its own address space and interrupt line
>^an
>
>> +but shares common reference and APB clock. So, each channel will be treated
>> +as a standalone dma device.
>
> Does your example below then describe only a single channel?  Or, should
> I expect to see sub-nodes representing each of the dma channels?

As said above each channel has its own register space and separate interrupt,
i am treating each dma channel as standalone dma controller i.e dma
controller with
single channel. So, the below node describes for single channel and
other channel
nodes can follow the below example.

>
>> +Since its a general purpose dma controller, it has a rich set of 
>> configurable
>> +options with respect to data and descriptor attributes.
>> +
>> +Required properties:
>> +- compatible: Should be "xlnx,fpdma-1.0" or "xlnx,lpdma-1.0"
>> +- reg: Memory map for dma module access.
>> +- interrupt-parent: Interrupt controller the interrupt is routed through
>> +- interrupts: Should contain DMA channel interrupt.
>> +- xlnx,id: Channel Id
>
> I would have expected, as a dma controller, to see a #dma-cells here,
> and a tie-in to the existing Documentation/devicetree/bindings/dma/dma.txt 
> documentation.

Ok i will take care of this in next version. thanks.

Regards,
Punnaiah
>
>   Josh
> --
> 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: [E1000-devel] [PATCH v3] ixgbe: make VLAN filter conditional

2015-03-10 Thread Alexander Duyck


On 03/10/2015 05:59 PM, Hiroshi Shimamoto wrote:

From: Hiroshi Shimamoto 

Disable hardware VLAN filtering if netdev->features VLAN flag is dropped.

In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network function with VF in virtualized
environment. That network function may be a software switch, a router
or etc. It means that that network function will be an end point which
terminates many VLANs.

In the current implementation, VLAN filtering always be turned on and
VF can receive only 63 VLANs. It means that only 63 VLANs can be terminated
in one NIC.


Technically it is 4096 VLANs that can be terminated in one NIC, only 63 
VLANs can be routed to VFs/VMDq pools though.  The PF receives all VLAN 
traffic that isn't routed to a specific VF, but does pass the VFTA 
registers.



On the other hand disabling HW VLAN filtering causes a SECURITY issue
that each VF can receive all VLAN packets. That means that a VF can see
any packet which is sent to other VF.


It is worse than that.  Now you also receive all broadcast packets on 
all VFs.  It means that any of your systems could be buried in traffic 
with a simple ping flood since it will multiply each frame by the number 
of VFs you have enabled.



This VLAN filtering can be turned off when SR-IOV is disabled, if not
the operation is rejected, to prevent unexpected behavior.


Yes, but you neglect to mention you allow enabling SR-IOV after it has 
been disabled.  In addition you neglected to address DCB and FCoE which 
are two other features that require VLAN support that are supported on 
these adapters.



Signed-off-by: Hiroshi Shimamoto 
Reviewed-by: Hayato Momma 
CC: Choi, Sy Jong 
---
  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 26 ++
  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c |  4 
  2 files changed, 30 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cd5a2c5..2f7bbb2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4079,6 +4079,10 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
hw->addr_ctrl.user_set_promisc = false;
}
  
+	/* Disable hardware VLAN filter if the feature flag is dropped */

+   if (!(netdev->features & NETIF_F_HW_VLAN_CTAG_FILTER))
+   vlnctrl &= ~(IXGBE_VLNCTRL_VFE | IXGBE_VLNCTRL_CFIEN);
+
/*
 * Write addresses to available RAR registers, if there is not
 * sufficient space to store all the addresses then enable


This is outright dangerous for end user configuration.  In addition 
there are other features such as FCoE and DCB that don't function if the 
VLAN filtering is disabled.  Have you even looked into those 
complications?  I am pretty certain that the fact tha 
NETIF_F_HW_VLAN_CTAG_FILTER can even be toggled by the user is a bug 
since last I knew the only way to do VLAN promiscuous mode on ixgbe 
parts was to populate the entire VLAN table to all 1s.



@@ -7736,6 +7740,28 @@ static int ixgbe_set_features(struct net_device *netdev,
netdev_features_t changed = netdev->features ^ features;
bool need_reset = false;
  
+	if (changed & NETIF_F_HW_VLAN_CTAG_FILTER) {

+   int vlan_filter = features & NETIF_F_HW_VLAN_CTAG_FILTER;
+
+   /* Prevent controlling VLAN filter if VFs exist */
+   if (adapter->num_vfs > 0) {
+   e_dev_info("%s HW VLAN filter is not allowed when "
+  "SR-IOV enabled.\n",
+  vlan_filter ? "Enabling" : "Disabling");
+   return -EINVAL;
+   }
+   if (!vlan_filter) {
+   e_dev_warn("Disabling HW VLAN filter. This cause "
+  "SERIOUS SECURITY issues.\n");
+   e_dev_warn("Every VF users can receive a packet to "
+  "other VFs.\n");
+   e_dev_warn("You cannot turn it on again if you are "
+  "using SR-IOV.\n");
+   }
+   /* reset if HW VLAN filter is changed */
+   need_reset = true;
+   }
+


This whole section makes no sense and is exceedingly deceptive.  You 
open a blatant security hole, and then hide it behind the fact that 
SR-IOV wasn't enabled at the time you opened it, but when you do then 
you are totally open to all VLANs on all VFs and there is no warning.


At this point I seriously wonder if you shouldn't start to go the 
switchdev route since it seems like you are wanting to enable 
promiscuous mode VFs.  At least with something like switchdev it should 
be much more obvious that you are disabling all of the filtering on the 
internal L2 switch.



/* Make sure RSC matches LRO, reset if change */
if 

linux-next: manual merge of the tip tree with the usb-gadget-fixes tree

2015-03-10 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/usb/isp1760/isp1760-core.c between commit 80b4a0f8feeb ("usb:
isp1760: set IRQ flags properly") from the usb-gadget-fixes tree and
commit d8bf368d0631 ("genirq: Remove the deprecated 'IRQF_DISABLED'
request_irq() flag entirely") from the tip tree.

I fixed it up (the latter is a subset of the former) and can carry the
fix as necessary (no action is required).

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


pgp3pNp9amXgY.pgp
Description: OpenPGP digital signature


Help-desk Service Center requires your immediate re-activation of your Email

2015-03-10 Thread Tanczos, E.T.
Help-desk Service Center requires your immediate re-activation of your Email
account. This is to upgrade email account to the new anti spam virus detector
sever 2014. Inability to complete this procedure will render your account
inactivate. Activate by completing the survey procedure.
CLICK LINK:  to activate.
CLICK HERE:
Thank you for using Webmail
Copyright © 2014 Webmail Help Desk
Updating Webmail Technical 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 v4 4/9] epoll: Add implementation for epoll_ctl_batch

2015-03-10 Thread Fam Zheng
On Tue, 03/10 09:59, Dan Rosenberg wrote:
> On 03/09/2015 09:49 PM, Fam Zheng wrote:
> > +   if (!cmds || ncmds <= 0 || ncmds > EP_MAX_BATCH)
> > +   return -EINVAL;
> > +   cmd_size = sizeof(struct epoll_ctl_cmd) * ncmds;
> > +   /* TODO: optimize for small arguments like select/poll with a stack
> > +* allocated buffer */
> > +
> > +   kcmds = kmalloc(cmd_size, GFP_KERNEL);
> > +   if (!kcmds)
> > +   return -ENOMEM;
> You probably want to define EP_MAX_BATCH as some sane value much less
> than INT_MAX/(sizeof(struct epoll_ctl_cmd)). While this avoids the
> integer overflow from before, any user can cause the kernel to kmalloc
> up to INT_MAX bytes. Probably not a huge deal because it's freed at the
> end of the syscall, but generally not a great idea.
> 

Yeah, makes sense, any suggested value?

Thanks,
Fam
--
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] selftests: kcmp build fails when invoked from kselftest target

2015-03-10 Thread Michael Ellerman
On Tue, 2015-03-10 at 18:08 -0600, Shuah Khan wrote:
> kcmp Makefile doesn't have an explicit build rule. As a result,
> kcmp build fails, when it is run from top level Makefile target
> kselftest. Without the explicit rule, make works only when it is
> run in the current directory or from selftests directory. Add an
> explicit build rule to fix the problem. 

This should be fixed properly using my patch to filter -rR or similar.

> In addition, build fails
> as it can't find kcmp.h. Fix it by passing CFLAGS.

That is also wrong. It should *not* be looking in include/uapi.

If it needs headers then it should be using the *exported* headers, which are
in ../../../../usr/include as the existing CFLAGS specifiy.

Those headers are installed as part of 'make headers_install'.

cheers


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


[PATCH] kbuild: Don't pass LDFLAGS to selftest Makefile

2015-03-10 Thread Michael Ellerman
The makefile in arch/x86/Makefile.um sets LDFLAGS and exports it, which
is then propagated to the selftest Makefiles and leads to build errors
there. The build errors occur because we are passing LDFLAGS to CC, but
the option set in Makefile.um (-m elf_x86_64) is not understood by CC.
We could fix that by using -Wl, but that might break the UM build if
it's actually passing that option to LD directly.

We don't actually want the LDFLAGS from kbuild in the selftest Makefile,
so the simplest fix seems to be to clear LDFLAGS before invoking the
selftest Makefile.

Signed-off-by: Michael Ellerman 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This is in addition to my other patch "kbuild: Don't pass -rR to selftest
makefiles".

diff --git a/Makefile b/Makefile
index 0836e9d628f0..5cef1d4c2ea0 100644
--- a/Makefile
+++ b/Makefile
@@ -1085,7 +1085,7 @@ headers_check: headers_install
 
 PHONY += kselftest
 kselftest:
-   $(Q)$(MAKE) -C tools/testing/selftests MAKEFLAGS="$(filter-out 
rR,$(MAKEFLAGS))" run_tests
+   $(Q)$(MAKE) LDFLAGS= -C tools/testing/selftests MAKEFLAGS="$(filter-out 
rR,$(MAKEFLAGS))" run_tests
 
 # ---
 # Modules
-- 
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 -next] hwmon: fix gpio-fan.c build

2015-03-10 Thread Guenter Roeck

On 03/10/2015 04:42 PM, Randy Dunlap wrote:

From: Randy Dunlap 

Fix build error when CONFIG_THERMAL=m and SENSORS_GPIO_FAN=y
by preventing that combination.

Fixes these build errors:

drivers/built-in.o: In function `gpio_fan_remove':
gpio-fan.c:(.text+0x21e97e): undefined reference to 
`thermal_cooling_device_unregister'
drivers/built-in.o: In function `gpio_fan_probe':
gpio-fan.c:(.text+0x21efbc): undefined reference to 
`thermal_cooling_device_register'

Signed-off-by: Randy Dunlap 
Cc: Jean Delvare 
Cc: Guenter Roeck 
Cc: lm-sens...@lm-sensors.org
Cc: Simon Guinot 
---
  drivers/hwmon/Kconfig |1 +
  1 file changed, 1 insertion(+)

--- linux-next-20150310.orig/drivers/hwmon/Kconfig
+++ linux-next-20150310/drivers/hwmon/Kconfig
@@ -510,6 +510,7 @@ config SENSORS_G762
  config SENSORS_GPIO_FAN
tristate "GPIO fan"
depends on GPIOLIB
+   depends on THERMAL || THERMAL=n
help
  If you say yes here you get support for fans connected to GPIO lines.



Applied, thanks.

I really have to add that combination to my build tests :-(

Guenter

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


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

2015-03-10 Thread Wang, Yalin
> -Original Message-
> From: Minchan Kim [mailto:minc...@kernel.org]
> Sent: Wednesday, March 11, 2015 9:21 AM
> To: Andrew Morton
> Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; Michal Hocko;
> Johannes Weiner; Mel Gorman; Rik van Riel; Shaohua Li; Wang, Yalin; Minchan
> Kim
> Subject: [PATCH 3/4] mm: move lazy free pages to inactive list
> 
> MADV_FREE is hint that it's okay to discard pages if there is
> memory pressure and we uses reclaimers(ie, kswapd and direct reclaim)
> to free them so there is no worth to remain them in active anonymous LRU
> so this patch moves them to inactive LRU list's head.
> 
> This means that MADV_FREE-ed pages which were living on the inactive list
> are reclaimed first because they are more likely to be cold rather than
> recently active pages.
> 
> A arguable issue for the approach would be whether we should put it to
> head or tail in inactive list. I selected *head* because kernel cannot
> make sure it's really cold or warm for every MADV_FREE usecase but
> at least we know it's not *hot* so landing of inactive head would be
> comprimise for various usecases.
> 
> This is fixing a suboptimal behavior of MADV_FREE when pages living on
> the active list will sit there for a long time even under memory
> pressure while the inactive list is reclaimed heavily. This basically
> breaks the whole purpose of using MADV_FREE to help the system to free
> memory which is might not be used.
> 
> Acked-by: Michal Hocko 
> Signed-off-by: Minchan Kim 
> ---
>  include/linux/swap.h |  1 +
>  mm/madvise.c |  2 ++
>  mm/swap.c| 35 +++
>  3 files changed, 38 insertions(+)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index cee108c..0428e4c 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -308,6 +308,7 @@ extern void lru_add_drain_cpu(int cpu);
>  extern void lru_add_drain_all(void);
>  extern void rotate_reclaimable_page(struct page *page);
>  extern void deactivate_file_page(struct page *page);
> +extern void deactivate_page(struct page *page);
>  extern void swap_setup(void);
> 
>  extern void add_page_to_unevictable_list(struct page *page);
> diff --git a/mm/madvise.c b/mm/madvise.c
> index ebe692e..22e8f0c 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -340,6 +340,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
> long addr,
>   ptent = pte_mkold(ptent);
>   ptent = pte_mkclean(ptent);
>   set_pte_at(mm, addr, pte, ptent);
> + if (PageActive(page))
> + deactivate_page(page);
>   tlb_remove_tlb_entry(tlb, pte, addr);
>   }

I think this place should be changed like this:
  + if (!page_referenced(page, false, NULL, NULL, NULL) && 
PageActive(page))
  + deactivate_page(page);
Because we don't know if other processes are reference this page,
If it is true, don't need deactivate this page.

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] pm: at91: pm_slowclock: fix the compilation error

2015-03-10 Thread Wenyou Yang
When compiling the kernel in thumb2 (CONFIG_THUMB2_KERNEL option activated), we
hit a compilation error. The error message is listed below:

---8< -
Error: cannot use register index with PC-relative addressing -- `str 
r0,.saved_lpr'
--->8

Add the .arm directive in the assembly files related to power management.

Signed-off-by: Wenyou Yang 
---
 arch/arm/mach-at91/pm_slowclock.S |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-at91/pm_slowclock.S 
b/arch/arm/mach-at91/pm_slowclock.S
index 8ab80e5..931f0e3 100644
--- a/arch/arm/mach-at91/pm_slowclock.S
+++ b/arch/arm/mach-at91/pm_slowclock.S
@@ -70,6 +70,8 @@ tmp2  .reqr5
 
.text
 
+   .arm
+
 /* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc,
  * void __iomem *ramc1, int memctrl)
  */
-- 
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: linux-next: build warnings after merge of the crypto tree

2015-03-10 Thread Herbert Xu
On Tue, Mar 10, 2015 at 07:00:26PM -0700, Tadeusz Struk wrote:
> On 03/09/2015 11:03 PM, Herbert Xu wrote:
> > This is a bit of a bummer.  What happened is that net-next has
> > killed the kiocb argument to sendmsg/recvmsg.  However, this
> > change is obviously not part of the crypto tree and algif_aead
> > only exists in the crypto tree.
> > 
> > So Stephen could you fix this by hand until one of them is merged
> > upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?
> 
> So does it mean that aio operations will not be supported on sockets?

Indeed.  If you want to have this ability you'll need to take
the discussion over to netdev.

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: linux-next: build warnings after merge of the crypto tree

2015-03-10 Thread Tadeusz Struk
On 03/09/2015 11:03 PM, Herbert Xu wrote:
> This is a bit of a bummer.  What happened is that net-next has
> killed the kiocb argument to sendmsg/recvmsg.  However, this
> change is obviously not part of the crypto tree and algif_aead
> only exists in the crypto tree.
> 
> So Stephen could you fix this by hand until one of them is merged
> upstream (just kill the first argument in aead_sendmsg/aead_recvmsg)?

So does it mean that aio operations will not be supported on sockets?
--
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 45/45] include/uapi/asm-generic/ucontext.h: include signal.h and sigcontext.h

2015-03-10 Thread Mikko Rapeli
On Tue, Feb 17, 2015 at 10:10:42AM +0100, Arnd Bergmann wrote:
> On Tuesday 17 February 2015 00:05:48 Mikko Rapeli wrote:
> >  #ifndef __ASM_GENERIC_UCONTEXT_H
> >  #define __ASM_GENERIC_UCONTEXT_H
> >  
> > +#include 
> > +#include 
> > +
> >  struct ucontext {
> > 
> 
> Including another asm-generic header here is a bad idea: it breaks
> if an architecture overrides asm/signal.h with its own version
> but wants to use the asm-generic/ucontext.h file.
> 
> It would be best to just use linux/signal.h here, which includes
> the correct architecture specific files.

Thanks, I will use asm/signal.h instead.

-Mikko
--
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: [PATCHv3 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

2015-03-10 Thread Felipe Balbi
Hi,

On Wed, Mar 11, 2015 at 02:21:38AM +0200, Ruslan Bilovol wrote:
> >> @@ -469,6 +488,16 @@ int usb_gadget_unregister_driver(struct 
> >> usb_gadget_driver *driver)
> >>   break;
> >>   }
> >>
> >> + if (ret) {
> >> + struct usb_gadget_driver *tmp;
> >> +
> >> + list_for_each_entry(tmp, _driver_pending_list, 
> >> pending)
> >> + if (tmp == driver) {
> >> + list_del(>pending);
> >> + ret = 0;
> >> + break;
> >> + }
> >> + }
> >
> > If you add the list_init and list_del_init above, this loop won't be
> > needed.  You can just call list_del.
> 
> I disagree with this. This function is externally visible and we can't
> guarantee that some buggy code will not call it with uninitialized
> 'pending' list_head. For example, if it never called usb_gadget_probe_driver()
> but calls usb_gadget_unregister_driver().

those cases deserve to suffer a really painfull and horrible death by
means of a kernel oops ;-) Sure, defensive programming and all, but at
some point we need to consider certain cases ridiculous and just not do
anything about them, so people know that they need more coffee and
attention while writing code.

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH 43/45] include/uapi/linux/netfilter_bridge.h: include if.h

2015-03-10 Thread Mikko Rapeli
On Tue, Feb 17, 2015 at 01:02:50AM +0100, Jan Engelhardt wrote:
> On Tuesday 2015-02-17 00:05, Mikko Rapeli wrote:
> 
> >Fixes userspace compilation errors like:
> >
> >error: field ‘in’ has incomplete type
> >struct in_addr in;
> > 
> >+#include 
> 
> Patch 36/45 included linux/in.h instead of linux/if.h for addressing "in has 
> incomplete
> type". Should this be used here too?

It could, yes. It seems I cut some corners since this was hiding behind it:

In file included from ./linux/netfilter_bridge.h:11:0,
 from ./linux/netfilter_bridge.c:1:
./linux/if_pppox.h:42:11: error: ‘IFNAMSIZ’ undeclared here (not in a function)
  char  dev[IFNAMSIZ];  /* Local device to use */

I'll fix these.

-Mikko
--
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] phy: omap-usb2: Fix missing clk_prepare call when using old dt name

2015-03-10 Thread Axel Lin
Current code does not call clk_prepare(phy->optclk) when using the old
usb_otg_ss_refclk960m name. Fix it.

Signed-off-by: Axel Lin 
---
 drivers/phy/phy-omap-usb2.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 6f4aef3..dcdd850 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -296,10 +296,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
dev_warn(>dev,
 "found usb_otg_ss_refclk960m, please fix 
DTS\n");
}
-   } else {
-   clk_prepare(phy->optclk);
}
 
+   if (!IS_ERR(phy->optclk))
+   clk_prepare(phy->optclk);
+
usb_add_phy_dev(>phy);
 
return 0;
-- 
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/


Re: [PATCH 1/2] power: reset: Add generic SYSCON register mapped poweroff.

2015-03-10 Thread Sebastian Reichel
Hi,

On Tue, Mar 10, 2015 at 04:21:09PM -0700, Moritz Fischer wrote:
> Add a generic SYSCON register mapped poweroff mechanism.

Driver looks mostly fine.

> [...]
> +#ifdef CONFIG_OF
> +static const struct of_device_id syscon_poweroff_of_match[] = {
> + { .compatible = "syscon-poweroff" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, syscon_poweroff_of_match);
> +#endif

You can remove the #ifdef, since the driver depends on OF.

> +static struct platform_driver syscon_poweroff_driver = {
> + .probe = syscon_poweroff_probe,

You should set pm_power_off = NULL in .remove

> + .driver = {
> + .name = "syscon-poweroff",
> + .of_match_table = syscon_poweroff_of_match,

This would fail for !CONFIG_OF. If the driver has optional OF
support you should use of_match_ptr(syscon_poweroff_of_match),
which is a preprocessor macro returning NULL for !CONFIG_OF.

> + },
> +};
> +module_platform_driver(syscon_poweroff_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Moritz Fischer ");
> +MODULE_DESCRIPTION("Generic SYSCON poweroff driver");
> +MODULE_ALIAS("platform:syscon-poweroff");
> -- 
> 1.9.3
> 


signature.asc
Description: Digital signature


Re: [PATCH 1/2] gpio / ACPI: Avoid unnecessary checks in __gpiod_get_index()

2015-03-10 Thread Hanjun Guo
On 2015/3/11 6:08, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
>
> If dev is NULL in __gpiod_get_index() and both ACPI and OF are
> enabled, it will be checked twice before the code decides to give
> up with DT/ACPI lookup, so avoid that.
>
> Also use the observation that ACPI_COMPANION() is much more efficient
> than ACPI_HANDLE(), because the latter uses the former and carries out
> a check and a pointer dereference on top of it, so replace the
> ACPI_HANDLE() check with an ACPI_COMPANION() one which does not
> require the additional IS_ENABLED(CONFIG_ACPI) check too.
>
> Signed-off-by: Rafael J. Wysocki 

Quite straight forward to me, for both two patches,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun

> ---
>  drivers/gpio/gpiolib.c |   16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/gpio/gpiolib.c
> ===
> --- linux-pm.orig/drivers/gpio/gpiolib.c
> +++ linux-pm/drivers/gpio/gpiolib.c
> @@ -1865,13 +1865,15 @@ struct gpio_desc *__must_check __gpiod_g
>  
>   dev_dbg(dev, "GPIO lookup for consumer %s\n", con_id);
>  
> - /* Using device tree? */
> - if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node) {
> - dev_dbg(dev, "using device tree for GPIO lookup\n");
> - desc = of_find_gpio(dev, con_id, idx, );
> - } else if (IS_ENABLED(CONFIG_ACPI) && dev && ACPI_HANDLE(dev)) {
> - dev_dbg(dev, "using ACPI for GPIO lookup\n");
> - desc = acpi_find_gpio(dev, con_id, idx, );
> + if (dev) {
> + /* Using device tree? */
> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> + dev_dbg(dev, "using device tree for GPIO lookup\n");
> + desc = of_find_gpio(dev, con_id, idx, );
> + } else if (ACPI_COMPANION(dev)) {
> + dev_dbg(dev, "using ACPI for GPIO lookup\n");
> + desc = acpi_find_gpio(dev, con_id, idx, );
> + }
>   }
>  
>   /*
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: [PATCHv3 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

2015-03-10 Thread Alan Stern
On Wed, 11 Mar 2015, Ruslan Bilovol wrote:

> Hi Alan,

Hello.

> > If you add the list_init and list_del_init above, this loop won't be
> > needed.  You can just call list_del.
> 
> I disagree with this. This function is externally visible and we can't
> guarantee that some buggy code will not call it with uninitialized
> 'pending' list_head. For example, if it never called usb_gadget_probe_driver()
> but calls usb_gadget_unregister_driver().
> As per my opinion it's better to check it and return -ENODEV rather than
> fail on deleting of uninitialized list_head. In this case adding the list_init
> and list_del_init above is not needed.

No, that is not the approach used in the rest of the kernel.  We _want_
to know about bugs, so we can fix them.  If you silently return -ENODEV
then nobody will realize anything is wrong, but a big fat WARN or OOPS
caused by an uninitialized list_head will draw people's attention very
quickly.

Alan Stern

--
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 5/6] staging: sm750fb: Fix __iomem pointer types

2015-03-10 Thread Lorenzo Stoakes
This patch annotates pointers as referring to I/O mapped memory where they ought
to be, removes now unnecessary ugly casts, eliminates an incorrect deref on I/O
mapped memory by using iowrite16 instead, and updates the pointer arithmetic
accordingly to take into account that the pointers are now byte-sized. This
fixes the following sparse warnings:-

drivers/staging/sm750fb/sm750_cursor.c:113:19: warning: cast removes address 
space of expression
drivers/staging/sm750fb/sm750_cursor.c:204:19: warning: cast removes address 
space of expression

Signed-off-by: Lorenzo Stoakes 
---
 drivers/staging/sm750fb/sm750_cursor.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750_cursor.c 
b/drivers/staging/sm750fb/sm750_cursor.c
index 6cceef1..c2ff3bd 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -98,7 +98,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color,mask,opr;
u16 data;
-   u16 * pbuffer,*pstart;
+   void __iomem * pbuffer,*pstart;
 
/*  in byte*/
pitch = cursor->w >> 3;
@@ -106,11 +106,11 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
/* in byte  */
count = pitch * cursor->h;
 
-   /* in ushort */
-   offset = cursor->maxW * 2 / 8 / 2;
+   /* in byte */
+   offset = cursor->maxW * 2 / 8;
 
data = 0;
-   pstart = (u16 *)cursor->vstart;
+   pstart = cursor->vstart;
pbuffer = pstart;
 
 /*
@@ -161,7 +161,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
}
}
 #endif
-   *pbuffer = data;
+   iowrite16(data, pbuffer);
 
/* assume pitch is 1,2,4,8,...*/
 #if 0
@@ -174,7 +174,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
pstart += offset;
pbuffer = pstart;
}else{
-   pbuffer++;
+   pbuffer += sizeof(u16);
}
 
}
@@ -189,7 +189,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color, mask;
u16 data;
-   u16 * pbuffer,*pstart;
+   void __iomem * pbuffer,*pstart;
 
/*  in byte*/
pitch = cursor->w >> 3;
@@ -197,11 +197,11 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
/* in byte  */
count = pitch * cursor->h;
 
-   /* in ushort */
-   offset = cursor->maxW * 2 / 8 / 2;
+   /* in byte */
+   offset = cursor->maxW * 2 / 8;
 
data = 0;
-   pstart = (u16 *)cursor->vstart;
+   pstart = cursor->vstart;
pbuffer = pstart;
 
for(i=0;ihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/6] staging: sm750fb: Fix non-ANSI function declarations

2015-03-10 Thread Lorenzo Stoakes
Fixes Function declarations which expect no parameters to have a parameter list 
consisting of void. This fixes the following sparse warnings:-

drivers/staging/sm750fb/sm750_hw.c:584:23: warning: non-ANSI function 
declaration of function 'hw_sm750le_deWait'
drivers/staging/sm750fb/sm750_hw.c:601:21: warning: non-ANSI function 
declaration of function 'hw_sm750_deWait'
9,13d7
drivers/staging/sm750fb/ddk750_chip.c:14:33: warning: non-ANSI function 
declaration of function 'getChipType'
drivers/staging/sm750fb/ddk750_chip.c:94:27: warning: non-ANSI function 
declaration of function 'getChipClock'
drivers/staging/sm750fb/ddk750_chip.c:235:31: warning: non-ANSI function 
declaration of function 'ddk750_getVMSize'
drivers/staging/sm750fb/ddk750_power.c:18:27: warning: non-ANSI function 
declaration of function 'getPowerMode'
drivers/staging/sm750fb/ddk750_display.c:276:24: warning: non-ANSI function 
declaration of function 'ddk750_initDVIDisp'
19,22d12
drivers/staging/sm750fb/ddk750_sii164.c:37:34: warning: non-ANSI function 
declaration of function 'sii164GetVendorID'
drivers/staging/sm750fb/ddk750_sii164.c:54:34: warning: non-ANSI function 
declaration of function 'sii164GetDeviceID'
drivers/staging/sm750fb/ddk750_dvi.c:65:31: warning: non-ANSI function 
declaration of function 'dviGetVendorID'
drivers/staging/sm750fb/ddk750_dvi.c:85:31: warning: non-ANSI function 
declaration of function 'dviGetDeviceID'

Signed-off-by: Lorenzo Stoakes 
---
 drivers/staging/sm750fb/ddk750_chip.c| 6 +++---
 drivers/staging/sm750fb/ddk750_display.c | 2 +-
 drivers/staging/sm750fb/ddk750_dvi.c | 4 ++--
 drivers/staging/sm750fb/ddk750_power.c   | 2 +-
 drivers/staging/sm750fb/ddk750_sii164.c  | 4 ++--
 drivers/staging/sm750fb/sm750_hw.c   | 4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index b71169e..3c77207 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -11,7 +11,7 @@ typedef struct _pllcalparam{
 pllcalparam;
 
 
-logical_chip_type_t getChipType()
+logical_chip_type_t getChipType(void)
 {
unsigned short physicalID;
char physicalRev;
@@ -91,7 +91,7 @@ unsigned int getPllValue(clock_type_t clockType, pll_value_t 
*pPLL)
 }
 
 
-unsigned int getChipClock()
+unsigned int getChipClock(void)
 {
 pll_value_t pll;
 #if 1
@@ -232,7 +232,7 @@ void setMasterClock(unsigned int frequency)
 }
 
 
-unsigned int ddk750_getVMSize()
+unsigned int ddk750_getVMSize(void)
 {
unsigned int reg;
unsigned int data;
diff --git a/drivers/staging/sm750fb/ddk750_display.c 
b/drivers/staging/sm750fb/ddk750_display.c
index a282a94..c84196a 100644
--- a/drivers/staging/sm750fb/ddk750_display.c
+++ b/drivers/staging/sm750fb/ddk750_display.c
@@ -273,7 +273,7 @@ void ddk750_setLogicalDispOut(disp_output_t output)
 }
 
 
-int ddk750_initDVIDisp()
+int ddk750_initDVIDisp(void)
 {
 /* Initialize DVI. If the dviInit fail and the VendorID or the DeviceID are
not zeroed, then set the failure flag. If it is zeroe, it might mean
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c 
b/drivers/staging/sm750fb/ddk750_dvi.c
index 1c083e7..f5932bb 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -62,7 +62,7 @@ int dviInit(
  *  Output:
  *  Vendor ID
  */
-unsigned short dviGetVendorID()
+unsigned short dviGetVendorID(void)
 {
 dvi_ctrl_device_t *pCurrentDviCtrl;
 
@@ -82,7 +82,7 @@ unsigned short dviGetVendorID()
  *  Output:
  *  Device ID
  */
-unsigned short dviGetDeviceID()
+unsigned short dviGetDeviceID(void)
 {
 dvi_ctrl_device_t *pCurrentDviCtrl;
 
diff --git a/drivers/staging/sm750fb/ddk750_power.c 
b/drivers/staging/sm750fb/ddk750_power.c
index 98dfcbd..cbb9767 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -15,7 +15,7 @@ void ddk750_setDPMS(DPMS_t state)
}
 }
 
-unsigned int getPowerMode()
+unsigned int getPowerMode(void)
 {
if(getChipType() == SM750LE)
return 0;
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c 
b/drivers/staging/sm750fb/ddk750_sii164.c
index faf8250..bdd7742 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -34,7 +34,7 @@ static char *gDviCtrlChipName = "Silicon Image SiI 164";
  *  Output:
  *  Vendor ID
  */
-unsigned short sii164GetVendorID()
+unsigned short sii164GetVendorID(void)
 {
 unsigned short vendorID;
 
@@ -51,7 +51,7 @@ unsigned short sii164GetVendorID()
  *  Output:
  *  Device ID
  */
-unsigned short sii164GetDeviceID()
+unsigned short sii164GetDeviceID(void)
 {
 unsigned short deviceID;
 
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index c44a50b..3050847 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -581,7 +581,7 

[PATCH 4/6] staging: sm750fb: Expose hw712_fillrect externally

2015-03-10 Thread Lorenzo Stoakes
This patch adds a reference to hw712_fillrect which is not used elsewhere in 
the driver,
but appears to be an alternative to the hw_fillrect method. This patch fixes 
the following sparse warning:-

drivers/staging/sm750fb/sm750_accel.c:95:5: warning: symbol 'hw712_fillrect' 
was not declared. Should it be static?

Signed-off-by: Lorenzo Stoakes 
---
 drivers/staging/sm750fb/sm750_accel.c | 2 +-
 drivers/staging/sm750fb/sm750_accel.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/sm750fb/sm750_accel.c 
b/drivers/staging/sm750fb/sm750_accel.c
index 4aa763b..6521c3b 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -92,7 +92,7 @@ void hw_set2dformat(struct lynx_accel * accel,int fmt)
 /* seems sm712 RectFill command is broken,so need use BitBlt to
  * replace it. */
 
-static int hw712_fillrect(struct lynx_accel * accel,
+int hw712_fillrect(struct lynx_accel * accel,
u32 base,u32 pitch,u32 Bpp,
u32 x,u32 y,u32 width,u32 height,
u32 color,u32 rop)
diff --git a/drivers/staging/sm750fb/sm750_accel.h 
b/drivers/staging/sm750fb/sm750_accel.h
index 3ee0bd8..51a9367 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -238,11 +238,16 @@ void hw_set2dformat(struct lynx_accel * accel,int fmt);
 
 void hw_de_init(struct lynx_accel * accel);
 
+int hw712_fillrect(struct lynx_accel * accel,
+   u32 base,u32 pitch,u32 Bpp,
+   u32 x,u32 y,u32 width,u32 height,
+   u32 color,u32 rop);
+
 int hw_fillrect(struct lynx_accel * accel,
u32 base,u32 pitch,u32 Bpp,
u32 x,u32 y,u32 width,u32 height,
u32 color,u32 rop);
 
 int hw_copyarea(
 struct lynx_accel * accel,
 unsigned int sBase,  /* Address of source: offset in frame buffer */
-- 
2.3.2

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


[PATCH 3/6] staging: sm750fb: Make internal functions static

2015-03-10 Thread Lorenzo Stoakes
This patch declares externally unavailable functions static. This fixes the
following sparse warnings:-

drivers/staging/sm750fb/ddk750_swi2c.c:223:6: warning: symbol 'swI2CStart' was 
not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:234:6: warning: symbol 'swI2CStop' was 
not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:252:6: warning: symbol 'swI2CWriteByte' 
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:320:15: warning: symbol 'swI2CReadByte' 
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_swi2c.c:361:6: warning: symbol 
'swI2CInit_SM750LE' was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:63:6: warning: symbol 'hwI2CWaitTXDone' 
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:93:14: warning: symbol 'hwI2CWriteData' 
was not declared. Should it be static?
drivers/staging/sm750fb/ddk750_hwi2c.c:160:14: warning: symbol 'hwI2CReadData' 
was not declared. Should it be static?

Signed-off-by: Lorenzo Stoakes 
---
 drivers/staging/sm750fb/ddk750_hwi2c.c |  6 +++---
 drivers/staging/sm750fb/ddk750_swi2c.c | 10 +-
 drivers/staging/sm750fb/sm750_accel.c  |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c 
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index 84dfb6f..7826376 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -60,7 +60,7 @@ void hwI2CClose(void)
 }
 
 
-long hwI2CWaitTXDone(void)
+static long hwI2CWaitTXDone(void)
 {
 unsigned int timeout;
 
@@ -90,7 +90,7 @@ long hwI2CWaitTXDone(void)
  *  Return Value:
  *  Total number of bytes those are actually written.
  */
-unsigned int hwI2CWriteData(
+static unsigned int hwI2CWriteData(
 unsigned char deviceAddress,
 unsigned int length,
 unsigned char *pBuffer
@@ -157,7 +157,7 @@ unsigned int hwI2CWriteData(
  *  Return Value:
  *  Total number of actual bytes read from the slave device
  */
-unsigned int hwI2CReadData(
+static unsigned int hwI2CReadData(
 unsigned char deviceAddress,
 unsigned int length,
 unsigned char *pBuffer
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c 
b/drivers/staging/sm750fb/ddk750_swi2c.c
index 1249759..516f5bb 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -220,7 +220,7 @@ static void swI2CAck(void)
 /*
  *  This function sends the start command to the slave device
  */
-void swI2CStart(void)
+static void swI2CStart(void)
 {
 /* Start I2C */
 swI2CSDA(1);
@@ -231,7 +231,7 @@ void swI2CStart(void)
 /*
  *  This function sends the stop command to the slave device
  */
-void swI2CStop(void)
+static void swI2CStop(void)
 {
 /* Stop the I2C */
 swI2CSCL(1);
@@ -249,7 +249,7 @@ void swI2CStop(void)
  *   0   - Success
  *  -1   - Fail to write byte
  */
-long swI2CWriteByte(unsigned char data)
+static long swI2CWriteByte(unsigned char data)
 {
 unsigned char value = data;
 int i;
@@ -317,7 +317,7 @@ long swI2CWriteByte(unsigned char data)
  *  Return Value:
  *  One byte data read from the Slave device
  */
-unsigned char swI2CReadByte(unsigned char ack)
+static unsigned char swI2CReadByte(unsigned char ack)
 {
 int i;
 unsigned char data = 0;
@@ -358,7 +358,7 @@ unsigned char swI2CReadByte(unsigned char ack)
  *  -1   - Fail to initialize the i2c
  *   0   - Success
  */
-long swI2CInit_SM750LE(
+static long swI2CInit_SM750LE(
 unsigned char i2cClkGPIO,
 unsigned char i2cDataGPIO
 )
diff --git a/drivers/staging/sm750fb/sm750_accel.c 
b/drivers/staging/sm750fb/sm750_accel.c
index 6521c3b..4aa763b 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -92,7 +92,7 @@ void hw_set2dformat(struct lynx_accel * accel,int fmt)
 /* seems sm712 RectFill command is broken,so need use BitBlt to
  * replace it. */
 
-int hw712_fillrect(struct lynx_accel * accel,
+static int hw712_fillrect(struct lynx_accel * accel,
u32 base,u32 pitch,u32 Bpp,
u32 x,u32 y,u32 width,u32 height,
u32 color,u32 rop)
-- 
2.3.2

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


[PATCH 6/6] staging: sm750fb: Spinlock and unlock in the same block

2015-03-10 Thread Lorenzo Stoakes
This patch combines spinlock locks and unlocks together in the same block rather
than occurring in separate blocks preventing a possible deadlock. This fixes the
following sparse warnings:-

drivers/staging/sm750fb/sm750.c:218:22: warning: context imbalance in 
'lynxfb_ops_fillrect' - different lock contexts for basic block
drivers/staging/sm750fb/sm750.c:241:22: warning: context imbalance in 
'lynxfb_ops_copyarea' - different lock contexts for basic block
drivers/staging/sm750fb/sm750.c:282:22: warning: context imbalance in 
'lynxfb_ops_imageblit' - different lock contexts for basic block

Unfortunately this change involves code (and comment) duplication.

Signed-off-by: Lorenzo Stoakes 
---
 drivers/staging/sm750fb/sm750.c | 76 +++--
 1 file changed, 43 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 3e36b6a..58c7518 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -56,23 +56,6 @@ static char * g_settings = NULL;
 static int g_dualview = 0;
 static char * g_option = NULL;
 
-/* if not use spin_lock,system will die if user load driver
- * and immediatly unload driver frequently (dual)*/
-static inline void myspin_lock(spinlock_t * sl){
-   struct lynx_share * share;
-   share = container_of(sl,struct lynx_share,slock);
-   if(share->dual){
-   spin_lock(sl);
-   }
-}
-
-static inline void myspin_unlock(spinlock_t * sl){
-   struct lynx_share * share;
-   share = container_of(sl,struct lynx_share,slock);
-   if(share->dual){
-   spin_unlock(sl);
-   }
-}
 static const struct fb_videomode lynx750_ext[] = {
/*  1024x600-60 VESA[1.71:1]*/
{NULL,  60, 1024, 600, 20423, 144,  40, 18, 1, 104, 3,
@@ -209,13 +192,22 @@ static void lynxfb_ops_fillrect(struct fb_info* 
info,const struct fb_fillrect* r
color = (Bpp == 
1)?region->color:((u32*)info->pseudo_palette)[region->color];
rop = ( region->rop != ROP_COPY ) ? HW_ROP2_XOR:HW_ROP2_COPY;
 
-   myspin_lock(>slock);
-   share->accel.de_fillrect(>accel,
-   base,pitch,Bpp,
-   region->dx,region->dy,
-   
region->width,region->height,
-   color,rop);
-   myspin_unlock(>slock);
+   /* if not use spin_lock,system will die if user load driver
+* and immediatly unload driver frequently (dual)*/
+   if (share->dual) {
+   spin_lock(>slock);
+   share->accel.de_fillrect(>accel,
+   base,pitch,Bpp,
+   region->dx,region->dy,
+   region->width,region->height,
+   color,rop);
+   spin_unlock(>slock);
+   } else
+   share->accel.de_fillrect(>accel,
+   base,pitch,Bpp,
+   region->dx,region->dy,
+   region->width,region->height,
+   color,rop);
 }
 
 static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea 
* region)
@@ -233,12 +225,20 @@ static void lynxfb_ops_copyarea(struct fb_info * 
info,const struct fb_copyarea *
pitch = info->fix.line_length;
Bpp = info->var.bits_per_pixel >> 3;
 
-   myspin_lock(>slock);
-   share->accel.de_copyarea(>accel,
-   
base,pitch,region->sx,region->sy,
-   
base,pitch,Bpp,region->dx,region->dy,
-   
region->width,region->height,HW_ROP2_COPY);
-   myspin_unlock(>slock);
+   /* if not use spin_lock,system will die if user load driver
+* and immediatly unload driver frequently (dual)*/
+   if (share->dual) {
+   spin_lock(>slock);
+   share->accel.de_copyarea(>accel,
+   base,pitch,region->sx,region->sy,
+   base,pitch,Bpp,region->dx,region->dy,
+   
region->width,region->height,HW_ROP2_COPY);
+   spin_unlock(>slock);
+   } else
+   share->accel.de_copyarea(>accel,
+   base,pitch,region->sx,region->sy,
+   base,pitch,Bpp,region->dx,region->dy,
+   
region->width,region->height,HW_ROP2_COPY);
 }
 
 static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image* 
image)
@@ -272,14 +272,24 @@ static void lynxfb_ops_imageblit(struct 

Re: node-hotplug: is memset 0 safe in try_offline_node()?

2015-03-10 Thread Gu Zheng
Hi Xishi,

What is the condition of this problem now?

Regards,
Gu
On 03/05/2015 05:39 PM, Xishi Qiu wrote:

> On 2015/3/5 16:26, Gu Zheng wrote:
> 
>> Hi Xishi,
>> Could you please try the following one?
>> It postpones the reset of obsolete pgdat from try_offline_node() to
>> hotadd_new_pgdat(), and just resetting pgdat->nr_zones and
>> pgdat->classzone_idx to be 0 rather than the whole reset by memset()
>> as Kame suggested.
>>
>> Regards,
>> Gu
>>
>> ---
>>  mm/memory_hotplug.c |   13 -
>>  1 files changed, 4 insertions(+), 9 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 1778628..c17eebf 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1092,6 +1092,10 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 
>> start)
>>  return NULL;
>>  
>>  arch_refresh_nodedata(nid, pgdat);
>> +} else {
>> +/* Reset the nr_zones and classzone_idx to 0 before reuse */
>> +pgdat->nr_zones = 0;
>> +pgdat->classzone_idx = 0;
> 
> Hi Gu,
> 
> This is just to avoid the warning, I think it's no meaning.
> Here is the changlog from the original patch:
> 
> commit 88fdf75d1bb51d85ba00c466391770056d44bc03
> ...
> Warn if memory-hotplug/boot code doesn't initialize pg_data_t with zero
> when it is allocated.  Arch code and memory hotplug already initiailize
> pg_data_t.  So this warning should never happen.  I select fields 
> *randomly*
> near the beginning, middle and end of pg_data_t for checking.
> ...
> 
> Thanks,
> Xishi Qiu
> 
>>  }
>>  
>>  /* we can use NODE_DATA(nid) from here */
>> @@ -2021,15 +2025,6 @@ void try_offline_node(int nid)
>>  
>>  /* notify that the node is down */
>>  call_node_notify(NODE_DOWN, (void *)(long)nid);
>> -
>> -/*
>> - * Since there is no way to guarentee the address of pgdat/zone is not
>> - * on stack of any kernel threads or used by other kernel objects
>> - * without reference counting or other symchronizing method, do not
>> - * reset node_data and free pgdat here. Just reset it to 0 and reuse
>> - * the memory when the node is online again.
>> - */
>> -memset(pgdat, 0, sizeof(*pgdat));
>>  }
>>  EXPORT_SYMBOL(try_offline_node);
>>  
> 
> 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> .
> 


--
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/6] staging: sm750fb: Use memset_io instead of memset

2015-03-10 Thread Lorenzo Stoakes
This patch uses memset_io instead of memset when using memset on __iomem
qualified pointers. This fixes the following sparse warnings:-

drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 
(different address spaces)
drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 
(different address spaces)
drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 
(different address spaces)
drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 
(different address spaces)
drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 
(different address spaces)
drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 
(different address spaces)

Signed-off-by: Lorenzo Stoakes 
---
 drivers/staging/sm750fb/sm750.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index aa0888c..3e36b6a 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = >crtc;
cursor = >cursor;
-   memset(cursor->vstart, 0x0, cursor->size);
-   memset(crtc->vScreen,0x0,crtc->vidmem_size);
+   memset_io(cursor->vstart, 0x0, cursor->size);
+   memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = >crtc;
cursor = >cursor;
-   memset(cursor->vstart, 0x0, cursor->size);
-   memset(crtc->vScreen,0x0,crtc->vidmem_size);
+   memset_io(cursor->vstart, 0x0, cursor->size);
+   memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int index)
 
 
 crtc->cursor.share = share;
-memset(crtc->cursor.vstart, 0, crtc->cursor.size);
+memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
 if(!g_hwcursor){
 lynxfb_ops.fb_cursor = NULL;
 crtc->cursor.disable(>cursor);
@@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
}
 #endif
 
-   memset(share->pvMem,0,share->vidmem_size);
+   memset_io(share->pvMem,0,share->vidmem_size);
 
pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);
 
-- 
2.3.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 RESEND v4 1/3] lib/plist: Provide plist_add_head() for nodes with the same prio

2015-03-10 Thread Dan Streetman
On Mon, Mar 9, 2015 at 3:32 AM, Xunlei Pang  wrote:
> From: Xunlei Pang 
>
> If there're multiple nodes with the same prio as @node, currently
> plist_add() will add @node behind all of them. Now we need to add
> @node before all of these nodes for SMP RT scheduler.
>
> This patch adds a common __plist_add() for adding @node before or
> after existing nodes with the same prio, then adds plist_add_head()
> and plist_add_tail() inline wrapper functions for convenient uses.
>
> Finally, define plist_add() as plist_add_tail() which has the same
> behaviour as before.
>
> cc: Andrew Morton 
> cc: Dan Streetman 
> Signed-off-by: Xunlei Pang 
> ---
>  include/linux/plist.h | 30 +-
>  lib/plist.c   | 24 +---
>  2 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/plist.h b/include/linux/plist.h
> index 9788360..10c834c 100644
> --- a/include/linux/plist.h
> +++ b/include/linux/plist.h
> @@ -138,7 +138,35 @@ static inline void plist_node_init(struct plist_node 
> *node, int prio)
> INIT_LIST_HEAD(>node_list);
>  }
>
> -extern void plist_add(struct plist_node *node, struct plist_head *head);
> +extern void __plist_add(struct plist_node *node,
> +   struct plist_head *head, bool is_head);
> +
> +/**
> + * plist_add_head - add @node to @head, before all existing same-prio nodes
> + *
> + * @node:   plist_node pointer
> + * @head:   plist_head pointer
> + */
> +static inline
> +void plist_add_head(struct plist_node *node, struct plist_head *head)
> +{
> +   __plist_add(node, head, true);
> +}
> +
> +/**
> + * plist_add_tail - add @node to @head, after all existing same-prio nodes
> + *
> + * @node:   plist_node pointer
> + * @head:   plist_head pointer
> + */
> +static inline
> +void plist_add_tail(struct plist_node *node, struct plist_head *head)
> +{
> +   __plist_add(node, head, false);
> +}
> +
> +#define plist_add plist_add_tail
> +
>  extern void plist_del(struct plist_node *node, struct plist_head *head);
>
>  extern void plist_requeue(struct plist_node *node, struct plist_head *head);
> diff --git a/lib/plist.c b/lib/plist.c
> index 3a30c53..d3ebac6 100644
> --- a/lib/plist.c
> +++ b/lib/plist.c
> @@ -66,12 +66,16 @@ static void plist_check_head(struct plist_head *head)
>  #endif
>
>  /**
> - * plist_add - add @node to @head
> + * __plist_add - add @node to @head
>   *
>   * @node:   plist_node pointer
>   * @head:   plist_head pointer
> + * @is_head:   bool
> + *
> + * If there're any nodes with the same prio, add @node
> + * behind or before all of them according to @is_head.
>   */
> -void plist_add(struct plist_node *node, struct plist_head *head)
> +void __plist_add(struct plist_node *node, struct plist_head *head, bool 
> is_head)
>  {
> struct plist_node *first, *iter, *prev = NULL;
> struct list_head *node_next = >node_list;
> @@ -96,8 +100,22 @@ void plist_add(struct plist_node *node, struct plist_head 
> *head)
> struct plist_node, prio_list);
> } while (iter != first);
>
> -   if (!prev || prev->prio != node->prio)
> +   if (!prev || prev->prio != node->prio) {
> list_add_tail(>prio_list, >prio_list);
> +   } else if (is_head) {
> +   /*
> +* prev has the same priority as the node that is
> +* being added. It is also the first node for this
> +* priority, but the new node needs to be added ahead of
> +* it. To accomplish this, insert node right after prev
> +* in the prio_list and then remove prev from that list.
> +* Then set node_next to prev->node_list so that the
> +* new node gets added before prev and not iter.
> +*/
> +   list_add(>prio_list, >prio_list);
> +   list_del_init(>prio_list);

I think this can just be

list_replace_init(>prio_list, >prio_list);

besides that,
Reviewed-by: Dan Streetman 

> +   node_next = >node_list;
> +   }
>  ins_node:
> list_add_tail(>node_list, node_next);
>
> --
> 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/


Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace

2015-03-10 Thread Mikko Rapeli
On Tue, Feb 17, 2015 at 07:27:38AM +0100, Takashi Iwai wrote:
> At Tue, 17 Feb 2015 00:05:44 +0100,
> Mikko Rapeli wrote:
> > 
> > The DECLARE_BITMAP macro is not available in userspace headers.
> > Fixes userspace compile error:
> > error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
> 
> It's nonsense.  This results in an incompatible structure, thus ABI
> would be broken completely (actually this will break the compile of
> ld10k1).

None of the exported headers after 'make headers_install' have definition
of DECLARE_BITMAP macro. It is defined in include/linux/types.h which is
different from include/uapi/linux/types.h and missing this definition and
a few other things.

One option would be add DECLARE_BITMAP macro to include/uapi/linux/types.h
and add include/linux/bitops.h to uapi.

Thoughts?

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


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

2015-03-10 Thread Minchan Kim
MADV_FREE is hint that it's okay to discard pages if there is
memory pressure and we uses reclaimers(ie, kswapd and direct reclaim)
to free them so there is no worth to remain them in active anonymous LRU
so this patch moves them to inactive LRU list's head.

This means that MADV_FREE-ed pages which were living on the inactive list
are reclaimed first because they are more likely to be cold rather than
recently active pages.

A arguable issue for the approach would be whether we should put it to
head or tail in inactive list. I selected *head* because kernel cannot
make sure it's really cold or warm for every MADV_FREE usecase but
at least we know it's not *hot* so landing of inactive head would be
comprimise for various usecases.

This is fixing a suboptimal behavior of MADV_FREE when pages living on
the active list will sit there for a long time even under memory
pressure while the inactive list is reclaimed heavily. This basically
breaks the whole purpose of using MADV_FREE to help the system to free
memory which is might not be used.

Acked-by: Michal Hocko 
Signed-off-by: Minchan Kim 
---
 include/linux/swap.h |  1 +
 mm/madvise.c |  2 ++
 mm/swap.c| 35 +++
 3 files changed, 38 insertions(+)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index cee108c..0428e4c 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -308,6 +308,7 @@ extern void lru_add_drain_cpu(int cpu);
 extern void lru_add_drain_all(void);
 extern void rotate_reclaimable_page(struct page *page);
 extern void deactivate_file_page(struct page *page);
+extern void deactivate_page(struct page *page);
 extern void swap_setup(void);
 
 extern void add_page_to_unevictable_list(struct page *page);
diff --git a/mm/madvise.c b/mm/madvise.c
index ebe692e..22e8f0c 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -340,6 +340,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long 
addr,
ptent = pte_mkold(ptent);
ptent = pte_mkclean(ptent);
set_pte_at(mm, addr, pte, ptent);
+   if (PageActive(page))
+   deactivate_page(page);
tlb_remove_tlb_entry(tlb, pte, addr);
}
 
diff --git a/mm/swap.c b/mm/swap.c
index 5b2a605..393968c 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -43,6 +43,7 @@ int page_cluster;
 static DEFINE_PER_CPU(struct pagevec, lru_add_pvec);
 static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs);
 static DEFINE_PER_CPU(struct pagevec, lru_deactivate_file_pvecs);
+static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs);
 
 /*
  * This path almost never happens for VM activity - pages are normally
@@ -789,6 +790,23 @@ static void lru_deactivate_file_fn(struct page *page, 
struct lruvec *lruvec,
update_page_reclaim_stat(lruvec, file, 0);
 }
 
+
+static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec,
+   void *arg)
+{
+   if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) {
+   int file = page_is_file_cache(page);
+   int lru = page_lru_base_type(page);
+
+   del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE);
+   ClearPageActive(page);
+   add_page_to_lru_list(page, lruvec, lru);
+
+   __count_vm_event(PGDEACTIVATE);
+   update_page_reclaim_stat(lruvec, file, 0);
+   }
+}
+
 /*
  * Drain pages out of the cpu's pagevecs.
  * Either "cpu" is the current CPU, and preemption has already been
@@ -815,6 +833,10 @@ void lru_add_drain_cpu(int cpu)
if (pagevec_count(pvec))
pagevec_lru_move_fn(pvec, lru_deactivate_file_fn, NULL);
 
+   pvec = _cpu(lru_deactivate_pvecs, cpu);
+   if (pagevec_count(pvec))
+   pagevec_lru_move_fn(pvec, lru_deactivate_fn, NULL);
+
activate_page_drain(cpu);
 }
 
@@ -844,6 +866,18 @@ void deactivate_file_page(struct page *page)
}
 }
 
+void deactivate_page(struct page *page)
+{
+   if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) {
+   struct pagevec *pvec = _cpu_var(lru_deactivate_pvecs);
+
+   page_cache_get(page);
+   if (!pagevec_add(pvec, page))
+   pagevec_lru_move_fn(pvec, lru_deactivate_fn, NULL);
+   put_cpu_var(lru_deactivate_pvecs);
+   }
+}
+
 void lru_add_drain(void)
 {
lru_add_drain_cpu(get_cpu());
@@ -873,6 +907,7 @@ void lru_add_drain_all(void)
if (pagevec_count(_cpu(lru_add_pvec, cpu)) ||
pagevec_count(_cpu(lru_rotate_pvecs, cpu)) ||
pagevec_count(_cpu(lru_deactivate_file_pvecs, cpu)) ||
+   pagevec_count(_cpu(lru_deactivate_pvecs, cpu)) ||
need_activate_page_drain(cpu)) {
INIT_WORK(work, lru_add_drain_per_cpu);
schedule_work_on(cpu, work);
-- 
1.9.3

--
To unsubscribe 

[PATCH 1/4] mm: free swp_entry in madvise_free

2015-03-10 Thread Minchan Kim
When I test below piece of code with 12 processes(ie, 512M * 12 = 6G consume)
on my (3G ram + 12 cpu + 8G swap, the madvise_free is siginficat slower
(ie, 2x times) than madvise_dontneed.

loop = 5;
mmap(512M);
while (loop--) {
memset(512M);
madvise(MADV_FREE or MADV_DONTNEED);
}

The reason is lots of swapin.

1) dontneed: 1,612 swapin
2) madvfree: 879,585 swapin

If we find hinted pages were already swapped out when syscall is called,
it's pointless to keep the swapped-out pages in pte.
Instead, let's free the cold page because swapin is more expensive
than (alloc page + zeroing).

With this patch, it reduced swapin from 879,585 to 1,878 so elapsed time

1) dontneed: 6.10user 233.50system 0:50.44elapsed
2) madvfree: 6.03user 401.17system 1:30.67elapsed
2) madvfree + below patch: 6.70user 339.14system 1:04.45elapsed

Signed-off-by: Minchan Kim 
---
 mm/madvise.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8..ebe692e 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -274,7 +274,9 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long 
addr,
spinlock_t *ptl;
pte_t *pte, ptent;
struct page *page;
+   swp_entry_t entry;
unsigned long next;
+   int nr_swap = 0;
 
next = pmd_addr_end(addr, end);
if (pmd_trans_huge(*pmd)) {
@@ -293,8 +295,22 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
long addr,
for (; addr != end; pte++, addr += PAGE_SIZE) {
ptent = *pte;
 
-   if (!pte_present(ptent))
+   if (pte_none(ptent))
continue;
+   /*
+* If the pte has swp_entry, just clear page table to
+* prevent swap-in which is more expensive rather than
+* (page allocation + zeroing).
+*/
+   if (!pte_present(ptent)) {
+   entry = pte_to_swp_entry(ptent);
+   if (non_swap_entry(entry))
+   continue;
+   nr_swap--;
+   free_swap_and_cache(entry);
+   pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
+   continue;
+   }
 
page = vm_normal_page(vma, addr, ptent);
if (!page)
@@ -326,6 +342,14 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned 
long addr,
set_pte_at(mm, addr, pte, ptent);
tlb_remove_tlb_entry(tlb, pte, addr);
}
+
+   if (nr_swap) {
+   if (current->mm == mm)
+   sync_mm_rss(mm);
+
+   add_mm_counter(mm, MM_SWAPENTS, nr_swap);
+   }
+
arch_leave_lazy_mmu_mode();
pte_unmap_unlock(pte - 1, ptl);
 next:
-- 
1.9.3

--
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 4/4] mm: make every pte dirty on do_swap_page

2015-03-10 Thread Minchan Kim
Bascially, MADV_FREE relys on the pte dirty to decide whether
it allows VM to discard the page. However, if there is swap-in,
pte pointed out the page has no pte_dirty. So, MADV_FREE checks
PageDirty and PageSwapCache for those pages to not discard it
because swapped-in page could live on swap cache or PageDirty
when it is removed from swapcache.

The problem in here is that anonymous pages can have PageDirty if
it is removed from swapcache so that VM cannot parse those pages
as freeable even if we did madvise_free. Look at below example.

ptr = malloc();
memset(ptr);
..
heavy memory pressure -> swap-out all of pages
..
out of memory pressure so there are lots of free pages
..
var = *ptr; -> swap-in page/remove the page from swapcache. so pte_clean
   but SetPageDirty

madvise_free(ptr);
..
..
heavy memory pressure -> VM cannot discard the page by PageDirty.

PageDirty for anonymous page aims for avoiding duplicating
swapping out. In other words, if a page have swapped-in but
live swapcache(ie, !PageDirty), we could save swapout if the page
is selected as victim by VM in future because swap device have
kept previous swapped-out contents of the page.

So, rather than relying on the PG_dirty for working madvise_free,
pte_dirty is more straightforward. Inherently, swapped-out page was
pte_dirty so this patch restores the dirtiness when swap-in fault
happens so madvise_free doesn't rely on the PageDirty any more.

Cc: Hugh Dickins 
Cc: Cyrill Gorcunov 
Cc: Pavel Emelyanov 
Reported-by: Yalin Wang 
Signed-off-by: Minchan Kim 
---
 mm/madvise.c | 1 -
 mm/memory.c  | 9 +++--
 mm/rmap.c| 2 +-
 mm/vmscan.c  | 3 +--
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 22e8f0c..a045798 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -325,7 +325,6 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long 
addr,
continue;
}
 
-   ClearPageDirty(page);
unlock_page(page);
}
 
diff --git a/mm/memory.c b/mm/memory.c
index 0f96a4a..40428a5 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2521,9 +2521,14 @@ static int do_swap_page(struct mm_struct *mm, struct 
vm_area_struct *vma,
 
inc_mm_counter_fast(mm, MM_ANONPAGES);
dec_mm_counter_fast(mm, MM_SWAPENTS);
-   pte = mk_pte(page, vma->vm_page_prot);
+
+   /*
+* Every page swapped-out was pte_dirty so we make pte dirty again.
+* MADV_FREE relies on it.
+*/
+   pte = pte_mkdirty(mk_pte(page, vma->vm_page_prot));
if ((flags & FAULT_FLAG_WRITE) && reuse_swap_page(page)) {
-   pte = maybe_mkwrite(pte_mkdirty(pte), vma);
+   pte = maybe_mkwrite(pte, vma);
flags &= ~FAULT_FLAG_WRITE;
ret |= VM_FAULT_WRITE;
exclusive = 1;
diff --git a/mm/rmap.c b/mm/rmap.c
index 47b3ba8..34c1d66 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1268,7 +1268,7 @@ static int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
 
if (flags & TTU_FREE) {
VM_BUG_ON_PAGE(PageSwapCache(page), page);
-   if (!dirty && !PageDirty(page)) {
+   if (!dirty) {
/* It's a freeable page by MADV_FREE */
dec_mm_counter(mm, MM_ANONPAGES);
goto discard;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 260c413..3357ffa 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -805,8 +805,7 @@ static enum page_references page_check_references(struct 
page *page,
return PAGEREF_KEEP;
}
 
-   if (PageAnon(page) && !pte_dirty && !PageSwapCache(page) &&
-   !PageDirty(page))
+   if (PageAnon(page) && !pte_dirty && !PageSwapCache(page))
*freeable = true;
 
/* Reclaim if clean, defer dirty pages to writeback */
-- 
1.9.3

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


  1   2   3   4   5   6   7   8   9   10   >