Re: [PATCH v2] Staging: fixed multiple spelling errors.

[Sudip Mukherjee]

On Fri, Apr 24, 2015 at 09:40:42AM -0400, Carlos E. Garcia wrote:
> 
> Fixed multiple spelling errors.
> 
> Signed-off-by: Carlos E. Garcia 
initials are usually discouraged in the Signed-off-by. The name here
should be the name the way you use it to sign legal documents. But i
can see that you already have one patch accepted and applied with
initials in your name.

regards
sudip

--
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] [media] xilinx: Reflect dma header file move

[Guenter Roeck]

Commit 937abe88aea3 ("dmaengine: xilinx-dma: move header file to common
location") moved xilinx_dma.h to a common location but neglected to reflect
this move in all its users.

This causes compile errors for several builds.

drivers/media/platform/xilinx/xilinx-dma.c:15:35:
fatal error: linux/amba/xilinx_dma.h: No such file or directory

Cc: Kedareswara rao Appana 
Fixes: 937abe88aea3 ("dmaengine: xilinx-dma: move header file to common
location")
Signed-off-by: Guenter Roeck 
---
 drivers/media/platform/xilinx/xilinx-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 10209c294168..efde88adf624 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -12,7 +12,7 @@
  * published by the Free Software Foundation.
  */
 
-#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/

[GIT PULL] platform/chrome: Updates for v4.1

[Olof Johansson]

Hi Linus,

Almost forgot to send this one in. Grmbl.

The patch from Dmitry for sorting out probing of chrome_laptop is just
now applied -- but given that it sorts out probing for the rare cases
where the trackpad comes up in bootloader mode I figured it's worth
including even if it hasn't baked in -next.

Please merge.

Thanks,

-Olof


The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

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

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/olof/chrome-platform.git 
tags/chrome-for-linus

for you to fetch changes up to 96cba9b00e297303774bec59e192064d20adeb3d:

  platform/chrome: chromeos_laptop - instantiate Atmel at primary address 
(2015-04-24 22:07:14 -0700)


platform/chrome: Updates for v4.1

Here's a set of updates to the Chrome OS platform drivers for this merge window.

Main new things this cycle is:

- Driver changes to expose the lightbar to users. With this, you can make your
  own blinkenlights on Chromebook Pixels.
- Changes in the way that the atmel_mxt trackpads are probed. The laptop driver
  is trying to be smart and not instantiate the devices that don't answer to
  probe. For the trackpad that can come up in two modes (bootloader or regular),
  this gets complicated since the driver already knows how to handle the two
  modes including the actual addresses used. So now the laptop driver needs to
  know more too, instantiating the regular address even if the bootloader one
  is the probe that passed.
- mfd driver improvements by Javier Martines Canillas, and a few bugfixes
  from him, kbuild and myself.


Bill Richardson (4):
  platform/chrome: Add cros_ec_lpc driver for x86 devices
  platform/chrome: Add Chrome OS EC userspace device interface
  platform/chrome: Create sysfs attributes for the ChromeOS EC
  platform/chrome: Expose Chrome OS Lightbar to users

Dmitry Torokhov (1):
  platform/chrome: chromeos_laptop - instantiate Atmel at primary address

Javier Martinez Canillas (5):
  mfd: cros_ec: Use fixed size arrays to transfer data with the EC
  mfd: cros_ec: Add char dev and virtual dev pointers
  mfd: cros_ec: Instantiate ChromeOS EC character device
  platform/chrome: cros_ec_lpc - Include linux/io.h header file
  platform/chrome: cros_ec_lpc - Depend on X86 || COMPILE_TEST

Olof Johansson (2):
  platform/chrome: cros_ec_dev - fix Unknown escape '%' warning
  platform/chrome: cros_ec_lightbar - fix duplicate const warning

kbuild test robot (1):
  platform/chrome: fix platform_no_drv_owner.cocci warnings

 Documentation/ioctl/ioctl-number.txt   |   1 +
 drivers/i2c/busses/i2c-cros-ec-tunnel.c|  51 +---
 drivers/input/keyboard/cros_ec_keyb.c  |  13 +-
 drivers/mfd/cros_ec.c  |  19 +-
 drivers/platform/chrome/Kconfig|  26 +-
 drivers/platform/chrome/Makefile   |   3 +
 drivers/platform/chrome/chromeos_laptop.c  |  35 ++-
 drivers/platform/chrome/cros_ec_dev.c  | 274 +
 drivers/platform/chrome/cros_ec_dev.h  |  53 +
 drivers/platform/chrome/cros_ec_lightbar.c | 367 +
 drivers/platform/chrome/cros_ec_lpc.c  | 319 +
 drivers/platform/chrome/cros_ec_sysfs.c| 271 +
 include/linux/mfd/cros_ec.h|  23 +-
 13 files changed, 1384 insertions(+), 71 deletions(-)
 create mode 100644 drivers/platform/chrome/cros_ec_dev.c
 create mode 100644 drivers/platform/chrome/cros_ec_dev.h
 create mode 100644 drivers/platform/chrome/cros_ec_lightbar.c
 create mode 100644 drivers/platform/chrome/cros_ec_lpc.c
 create mode 100644 drivers/platform/chrome/cros_ec_sysfs.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2 resend] show isolated & nohz_full cpus in sysfs

[Mike Galbraith]

On Fri, 2015-04-24 at 15:24 -0400, r...@redhat.com wrote:
> Currently there is no good way to get the isolated and nohz_full
> CPUs at runtime, because the kernel may have changed the CPUs
> specified on the commandline (when specifying all CPUs as
> isolated, or CPUs that do not exist, ...)
> 
> This series adds two files to /sys/devices/system/cpu, which can
> be used by system management tools like libvirt, openstack, etc.
> to ensure proper task placement.
> 
> These patches were kind of (but not formally) acked by
> Mike and Frederic, see https://lkml.org/lkml/2015/3/27/852

Acked-by: Mike Galbraith 


--
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] dgnc: Cleanup of unnecessary braces

[Joe Perches]

On Fri, 2015-04-24 at 23:48 -0500, Robert Callicotte wrote:
> Removed curly braces and trailing whitespace from else clause.

Do please compile the files modified by your patches
_before_ sending them.

> Signed-off-by: Robert Callicotte 
> ---
>  drivers/staging/dgnc/dgnc_tty.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
> index ce4187f..2418150 100644
> --- a/drivers/staging/dgnc/dgnc_tty.c
> +++ b/drivers/staging/dgnc/dgnc_tty.c
> @@ -898,9 +898,8 @@ void dgnc_check_queue_flow_control(struct channel_t *ch)
>   ch->ch_bd->bd_ops->send_start_character(ch);
>   }
>   /* No FLOW */
> - else {
> + else
>   /* Nothing needed. */
> - }
>   }
>  }
>  



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

Re: [PATCH 00/21] ARCNET: Defibrillation

[Joe Perches]

On Fri, 2015-04-24 at 23:58 -0400, David Miller wrote:
> From: Marc Kleine-Budde 
> Date: Fri, 24 Apr 2015 23:14:41 +0200
> > On 04/24/2015 08:47 PM, Joe Perches wrote:
> >> On Fri, 2015-04-24 at 19:20 +0200, Michael Grzeschik wrote:
> >>> This patch series tries to reanimate the ARCNET hardware layer to be
> >>> somehow readable and maintainable again. It includes a lot of cleanup
> >>> patches. It also adds some fixes which leads the layer to become usable
> >>> again. And as a special treatment it adds more features like correct
> >>> loading and unloading of the com20020 card.
> >> Wow.  Good for you, but why?  Does anyone still use these?
> > Yes, there are parts of the industry where "old" machines are
> > retrofitted with new hardware...and a lot of these machines still talk
> > ARCNET :)
> 
> But the real issue is, this layer is development wise in the same
> category as the IDE layer.
> 
> Any non-trivial change is nothing but pure risk, especially given the
> low level of test coverage the code gets.
> 
> So I really only want to see the most critical obvious bug fixes
> submitted for this layer and drivers.
> 
> And no I will not accept an argument stating that you have to
> restructure and clean this code up in order to fix the bugs.  That's
> bogus.

I think that arcnet is a fairly simple protocol.

Given the current state of the code, if someone wants to
make the code better, it might be better to wholesale
replace what's there instead of incrementally modifying it.

It's not that difficult to make what's there style cleaner
though.  Most if it is trivial sed style replacements.

Dunno. It doesn't look like that big a job actually, but I
don't use it nor could I do testing on actual hardware.

If pengutronix wants help, I probably could.


--
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] platform/chrome: chromeos_laptop - do not probe devices on Pixel 1

[Olof Johansson]

On Tue, Apr 14, 2015 at 01:50:09PM -0700, Dmitry Torokhov wrote:
> On Fri, Apr 10, 2015 at 10:41:54AM -0700, Dmitry Torokhov wrote:
> > On Thu, Apr 09, 2015 at 04:57:59PM -0700, Dmitry Torokhov wrote:
> > > Atmel MXT devices use different i2c addresses, depending on the current
> > > mode of operation (bootloader or application). The new Atmel MXT driver
> > > expects i2c client's address contain the application address of the
> > > chip, and calculates the expected bootloader address form the
> > > application address. Unfortunately chromeos_laptop does probe the
> > > devices and if touchpad (or touchscreen, or both) comes up in bootloader
> > > mode, the i2c device gets instantiated with the bootloader address
> > > instead of application address, which confuses the driver.
> > > 
> > > Given that hardware on Pixel is set and is not going to change let's not
> > > try to probe devices to see if they are present or not, but rather
> > > instantiate them always at expected addresses.
> > > 
> > > Since all devices are now probed and/or instantiated at given address,
> > > we no longer need to support probing multiple addresses for the same
> > 
> > Hmm, that strategy won't work on C720 since there are devices with 
> > touchscreen
> > and without one, so we do want to probe but always instantiate at primary
> > address. V3 will be upcoming...
> 
> OK, new version. Not sending to the wide world for now in case we decide
> it is too ugly...

I'm not a huge fan of this, but as mentioned in person, the whole situation is
somewhat awkward and we don't really have any better ideas.

I've applied this now, and will include it in the 4.1 branch since it's needed
for stable operation on pixel 1 going forward.


-Olof
--
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: Thunderbolt hotplug not working on MacMini7,1

[Adam Goode]

On Fri, Apr 24, 2015 at 2:39 PM, Adam Goode  wrote:
> On Fri, Apr 24, 2015 at 7:46 AM, Andreas Noever
>  wrote:
>> On Fri, Apr 24, 2015 at 6:50 AM, Adam Goode  wrote:
>>> On Thu, Apr 23, 2015 at 1:15 PM, Adam Goode  wrote:
 On Thu, Apr 23, 2015 at 12:12 PM, Andreas Noever
  wrote:
> On Thu, Apr 23, 2015 at 5:10 PM, Adam Goode  wrote:
>> On Thu, Apr 23, 2015 at 9:28 AM, Adam Goode  wrote:
>>>
>>> On Thu, Apr 23, 2015 at 6:08 AM, Andreas Noever
>>>  wrote:
>>> > Hi Adam,
>>> >
>>> > On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
>>> > controller both use 0x1547 and are only differentiated by
>>> > subvendor/subdevice.
>>> >
>>> > 0x156c is the 4 channel TB2 controller and was originally added by
>>> > Matthew. Judging from his patch it looks like the subvendor/subdevice
>>> > is set on his system:
>>> > http://patchwork.ozlabs.org/patch/354626/
>>> >
>>> > But it also indicates that the bridges already use different ids. If
>>> > that is the case then we can drop the subvendor/subdevice for 0x156c.
>>> > Matthew can you confirm that on your system 0x156c is used only for
>>> > the controller?
>>> >
>>> > Adam, could you check that suspend/resume works properly? Also your
>>> > bugzilla report suggest that hotplug might now work without the
>>> > driver. Could you try to revert the _OSI check (and disable the
>>> > driver) and check whether everything "just works"?
>>> >
>>>
>>> In _OSI("Darwin") mode, suspend/resume doesn't work. It failed to come
>>> back from suspend.
>>>
>>> I have to rebuild the kernel and remove Darwin again, but I will test
>>> suspend/resume in "Windows 2012" mode later.
>>>
>>> From previous testing, hotplug doesn't automatically work in "Windows
>>> 2012" mode. It exhibits the standard no-driver behavior where devices
>>> are not detected after boot. But even in "Windows 2012" mode I still
>>> do get the 0x156c device, which I think used to be hidden if !Darwin.
>>>
>>> More testing coming...
>>>
>>
>> I've booted into _OSI(Windows 2012) mode. I am not physically at the
>> device right now, but here is the current dmesg with 1 thunderbolt
>> device plugged in:
>>
>> [   15.576766] thunderbolt :06:00.0: NHI initialized, starting 
>> thunderbolt
>> [   15.577868] thunderbolt :06:00.0: allocating TX ring 0 of size 10
>> [   15.578939] thunderbolt :06:00.0: allocating RX ring 0 of size 10
>> [   15.580008] thunderbolt :06:00.0: control channel created
>> [   15.581068] thunderbolt :06:00.0: control channel starting...
>> [   15.582122] thunderbolt :06:00.0: starting TX ring 0
>> [   15.583173] thunderbolt :06:00.0: enabling interrupt at
>> register 0x38200 bit 0 (0x0 -> 0x1)
>> [   15.584228] thunderbolt :06:00.0: starting RX ring 0
>> [   15.585281] thunderbolt :06:00.0: enabling interrupt at
>> register 0x38200 bit 12 (0x1 -> 0x1001)
>> [   15.586463] thunderbolt :06:00.0: initializing Switch at 0x0
>> (depth: 0, up port: 5)
>> [   15.587526] thunderbolt :06:00.0: old switch config:
>> [   15.588569] thunderbolt :06:00.0:  Switch: 8086:156d (Revision:
>> 0, TB Version: 2)
>> [   15.589581] thunderbolt :06:00.0:   Max Port Number: 12
>> [   15.590557] thunderbolt :06:00.0:   Config:
>> [   15.591532] thunderbolt :06:00.0:Upstream Port Number: 5
>> Depth: 0 Route String: 0x0 Enabled: 1, PlugEventsDelay: 255ms
>> [   15.592530] thunderbolt :06:00.0:unknown1: 0x0 unknown4: 0x0
>> [   15.593530] thunderbolt :06:00.0: 0: unsupported switch device id 
>> 0x156d
>> [   15.625612] thunderbolt :06:00.0: 0: uid: 0x1001500947a60
>> [   15.626919] thunderbolt :06:00.0:  Port 0: 8086:156d (Revision:
>> 0, TB Version: 1, Type: Port (0x1))
>> [   15.628028] thunderbolt :06:00.0:   Max hop id (in/out): 7/7
>> [   15.629050] thunderbolt :06:00.0:   Max counters: 8
>> [   15.630156] thunderbolt :06:00.0:   NFC Credits: 0x70
>> [   15.631685] thunderbolt :06:00.0:  Port 1: 8086:156d (Revision:
>> 0, TB Version: 1, Type: Port (0x1))
>> [   15.632896] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
>> [   15.634000] thunderbolt :06:00.0:   Max counters: 16
>> [   15.635001] thunderbolt :06:00.0:   NFC Credits: 0x3c0
>> [   15.636582] thunderbolt :06:00.0:  Port 2: 8086:156d (Revision:
>> 0, TB Version: 1, Type: Port (0x1))
>> [   15.637737] thunderbolt :06:00.0:   Max hop id (in/out): 15/15
>> [   15.638862] thunderbolt :06:00.0:   Max counters: 16
>> [   15.639875] thunderbolt :06:00.0:   NFC Credits: 0x3c0
>> [   15.641452] thunderbolt :06:00.0:  Port 3: 8086:156d (Revision:
>> 0, TB 

Re: [PATCH] perf/x86/intel/uncore: fix IMC missing box initialization

[Andi Kleen]

> This leads me to believe that this patch:
> 
> commit c05199e5a57a579fea1e8fa65e2b511ceb524ffc
> Author: Kan Liang 
> Date:   Tue Jan 20 04:54:25 2015 +
> 
> perf/x86/intel/uncore: Move uncore_box_init() out of driver initialization
> 
> If I revert it, I bet things will work again.

Yes the initialization needs to be moved out of the IPI context.

-Andi


-- 
a...@linux.intel.com -- Speaking for myself only
--
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] dgnc: Cleanup of unnecessary braces

[Robert Callicotte]

Removed curly braces and trailing whitespace from else clause.

Signed-off-by: Robert Callicotte 
---
 drivers/staging/dgnc/dgnc_tty.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index ce4187f..2418150 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -898,9 +898,8 @@ void dgnc_check_queue_flow_control(struct channel_t *ch)
ch->ch_bd->bd_ops->send_start_character(ch);
}
/* No FLOW */
-   else {
+   else
/* Nothing needed. */
-   }
}
 }
 
-- 
2.2.2

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

Re: Interacting with coherent memory on external devices

[Benjamin Herrenschmidt]

On Fri, 2015-04-24 at 22:32 -0400, Rik van Riel wrote:
> >   The result would be that the kernel would allocate only
> migratable
> >   pages within the CCAD device's memory, and even then only if
> >   memory was otherwise exhausted.
> 
> Does it make sense to allocate the device's page tables in memory
> belonging to the device?
> 
> Is this a necessary thing with some devices? Jerome's HMM comes
> to mind...

In our case, the device's MMU shares the host page tables (which is why
we can't use HMM, ie we can't have a page with different permissions on
CPU vs. device which HMM does).

However the device has a pretty fast path to system memory, the best
thing we can do is pin the workload to the same chip the device is
connected to so those page tables arent' too far away.

Cheers,
Ben.


--
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 06/21] ARCNET: com20020: remove unneeded macros

[David Miller]

From: Joe Perches 
Date: Fri, 24 Apr 2015 16:04:45 -0700

> On Fri, 2015-04-24 at 19:20 +0200, Michael Grzeschik wrote:
>> The macros SET_SUBADR, ARCRESET, ARCRESET0, ACOMMAND, ASTATUS, AINTMASK
>> and ADIAGSTATUS are unnecessary indirections to the use of registers.
>> This patch removes them and improves the readability of the code.
> 
> This breaks compilation.
> 
> Please compile test your patches before sending them.

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

Re: [PATCH 00/21] ARCNET: Defibrillation

[David Miller]

From: Marc Kleine-Budde 
Date: Fri, 24 Apr 2015 23:14:41 +0200

> On 04/24/2015 08:47 PM, Joe Perches wrote:
>> On Fri, 2015-04-24 at 19:20 +0200, Michael Grzeschik wrote:
>>> Hi!
>> 
>> Hello.
>> 
>>> This patch series tries to reanimate the ARCNET hardware layer to be
>>> somehow readable and maintainable again. It includes a lot of cleanup
>>> patches. It also adds some fixes which leads the layer to become usable
>>> again. And as a special treatment it adds more features like correct
>>> loading and unloading of the com20020 card.
>> 
>> Wow.  Good for you, but why?  Does anyone still use these?
> 
> Yes, there are parts of the industry where "old" machines are
> retrofitted with new hardware...and a lot of these machines still talk
> ARCNET :)

But the real issue is, this layer is development wise in the same
category as the IDE layer.

Any non-trivial change is nothing but pure risk, especially given the
low level of test coverage the code gets.

So I really only want to see the most critical obvious bug fixes
submitted for this layer and drivers.

And no I will not accept an argument stating that you have to
restructure and clean this code up in order to fix the bugs.  That's
bogus.

I'm rejecting this patch series, sorry.
--
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] mm/hugetlb: reduce arch dependent code about hugetlb_prefault_arch_hook

[Zhang Zhen]

Currently we have many duplicates in definitions of hugetlb_prefault_arch_hook.
In all architectures this function is empty.

Signed-off-by: Zhang Zhen 
---
 arch/arm/include/asm/hugetlb.h | 4 
 arch/arm64/include/asm/hugetlb.h   | 4 
 arch/ia64/include/asm/hugetlb.h| 4 
 arch/metag/include/asm/hugetlb.h   | 4 
 arch/mips/include/asm/hugetlb.h| 4 
 arch/powerpc/include/asm/hugetlb.h | 5 -
 arch/s390/include/asm/hugetlb.h| 1 -
 arch/sh/include/asm/hugetlb.h  | 3 ---
 arch/sparc/include/asm/hugetlb.h   | 4 
 arch/tile/include/asm/hugetlb.h| 4 
 arch/x86/include/asm/hugetlb.h | 3 ---
 fs/hugetlbfs/inode.c   | 1 -
 12 files changed, 41 deletions(-)

diff --git a/arch/arm/include/asm/hugetlb.h b/arch/arm/include/asm/hugetlb.h
index 1f1b1cd..31bb7dc 100644
--- a/arch/arm/include/asm/hugetlb.h
+++ b/arch/arm/include/asm/hugetlb.h
@@ -53,10 +53,6 @@ static inline int prepare_hugepage_range(struct file *file,
return 0;
 }

-static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
-{
-}
-
 static inline int huge_pte_none(pte_t pte)
 {
return pte_none(pte);
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
index 5b7ca8a..734c17e 100644
--- a/arch/arm64/include/asm/hugetlb.h
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -86,10 +86,6 @@ static inline int prepare_hugepage_range(struct file *file,
return 0;
 }

-static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
-{
-}
-
 static inline int huge_pte_none(pte_t pte)
 {
return pte_none(pte);
diff --git a/arch/ia64/include/asm/hugetlb.h b/arch/ia64/include/asm/hugetlb.h
index aa91005..ff1377b 100644
--- a/arch/ia64/include/asm/hugetlb.h
+++ b/arch/ia64/include/asm/hugetlb.h
@@ -20,10 +20,6 @@ static inline int is_hugepage_only_range(struct mm_struct 
*mm,
REGION_NUMBER((addr)+(len)-1) == RGN_HPAGE);
 }

-static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
-{
-}
-
 static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
   pte_t *ptep, pte_t pte)
 {
diff --git a/arch/metag/include/asm/hugetlb.h b/arch/metag/include/asm/hugetlb.h
index 471f481..f730b39 100644
--- a/arch/metag/include/asm/hugetlb.h
+++ b/arch/metag/include/asm/hugetlb.h
@@ -14,10 +14,6 @@ static inline int is_hugepage_only_range(struct mm_struct 
*mm,
 int prepare_hugepage_range(struct file *file, unsigned long addr,
unsigned long len);

-static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
-{
-}
-
 static inline void hugetlb_free_pgd_range(struct mmu_gather *tlb,
  unsigned long addr, unsigned long end,
  unsigned long floor,
diff --git a/arch/mips/include/asm/hugetlb.h b/arch/mips/include/asm/hugetlb.h
index fe0d15d..4a5bb54 100644
--- a/arch/mips/include/asm/hugetlb.h
+++ b/arch/mips/include/asm/hugetlb.h
@@ -38,10 +38,6 @@ static inline int prepare_hugepage_range(struct file *file,
return 0;
 }

-static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
-{
-}
-
 static inline void hugetlb_free_pgd_range(struct mmu_gather *tlb,
  unsigned long addr,
  unsigned long end,
diff --git a/arch/powerpc/include/asm/hugetlb.h 
b/arch/powerpc/include/asm/hugetlb.h
index 1d53a65..4bbd3c8 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -112,11 +112,6 @@ static inline int prepare_hugepage_range(struct file *file,
return 0;
 }

-static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
-{
-}
-
-
 static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
   pte_t *ptep, pte_t pte)
 {
diff --git a/arch/s390/include/asm/hugetlb.h b/arch/s390/include/asm/hugetlb.h
index 11eae5f..dfb542a 100644
--- a/arch/s390/include/asm/hugetlb.h
+++ b/arch/s390/include/asm/hugetlb.h
@@ -35,7 +35,6 @@ static inline int prepare_hugepage_range(struct file *file,
return 0;
 }

-#define hugetlb_prefault_arch_hook(mm) do { } while (0)
 #define arch_clear_hugepage_flags(page)do { } while (0)

 int arch_prepare_hugepage(struct page *page);
diff --git a/arch/sh/include/asm/hugetlb.h b/arch/sh/include/asm/hugetlb.h
index 699255d..b788a9b 100644
--- a/arch/sh/include/asm/hugetlb.h
+++ b/arch/sh/include/asm/hugetlb.h
@@ -26,9 +26,6 @@ static inline int prepare_hugepage_range(struct file *file,
return 0;
 }

-static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm) {
-}
-
 static inline void hugetlb_free_pgd_range(struct mmu_gather *tlb,
  unsigned long addr, unsigned long end,
  unsigned long floor,
diff --git 

Re: [PATCH v2] livepatch: x86: make kASLR logic more accurate

[Minfei Huang]

On 04/24/15 at 09:59P, Jiri Kosina wrote:
> We give up old_addr hint from the coming patch module in cases when kernel 
> load
> base has been randomized (as in such case, the coming module has no idea about
> the exact randomization offset).
> 
> We are currently too pessimistic, and give up immediately as soon as 
> CONFIG_RANDOMIZE_BASE is set; this doesn't however directly imply that the 
> load base has actually been randomized. There are config options that 
> disable kASLR (such as hibernation), user could have disabled kaslr on 
> kernel command-line, etc.
> 
> The loader propagates the information whether kernel has been randomized 
> through bootparams. This allows us to have the condition more accurate.
> 
> On top of that, it seems unnecessary to give up old_addr hints even if 
> randomization is active. The relocation offset can be computed as 
> difference between _text start and __START_KERNEL, and therefore old_addr 
> can be adjusted accordingly.
> 
> Signed-off-by: Jiri Kosina 
> ---
> 
> v1 -> v2: I accidentally used kgr_ suffix (which we use in kGraft) instead 
> of klp_ in v1.
> 
>  arch/x86/include/asm/livepatch.h | 4 
>  arch/x86/kernel/livepatch.c  | 5 +
>  kernel/livepatch/core.c  | 5 +++--
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/livepatch.h 
> b/arch/x86/include/asm/livepatch.h
> index 2d29197..84a3247 100644
> --- a/arch/x86/include/asm/livepatch.h
> +++ b/arch/x86/include/asm/livepatch.h
> @@ -23,8 +23,12 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_LIVEPATCH
> +
> +extern unsigned long klp_vmlinux_relocation_offset(void);
> +
>  static inline int klp_check_compiler_support(void)
>  {
>  #ifndef CC_USING_FENTRY
> diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
> index ff3c3101d..6df7902 100644
> --- a/arch/x86/kernel/livepatch.c
> +++ b/arch/x86/kernel/livepatch.c
> @@ -88,3 +88,8 @@ int klp_write_module_reloc(struct module *mod, unsigned 
> long type,
>  
>   return ret;
>  }
> +
> +unsigned long klp_vmlinux_relocation_offset(void)
> +{
> + return (unsigned long)&_text - __START_KERNEL;
> +}

Is it possible to put above function into arch/x86/include/asm/setup.h?
It is more elegant, so that the function is re-used by other module.

> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 284e269..ff4c35c 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -234,8 +234,9 @@ static int klp_find_verify_func_addr(struct klp_object 
> *obj,
>   int ret;
>  
>  #if defined(CONFIG_RANDOMIZE_BASE)
> - /* KASLR is enabled, disregard old_addr from user */
> - func->old_addr = 0;
> + /* If KASLR has been enabled, adjust old_addr accordingly */
> + if (kaslr_enabled())
> + func->old_addr += klp_vmlinux_relocation_offset();

Since KASLR only works for x86 arch now, it is better to put it into the
specfied arch (x86 now), or implement a weak function to let be overwritten
by specified arch.

Thanks
Minfei

>  #endif
>  
>   if (!func->old_addr || klp_is_module(obj))
> 
> -- 
> Jiri Kosina
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe live-patching" 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: [PATCH v2 1/2] soc: qcom: Add device tree binding for SMEM

[Andy Gross]

On Thu, Apr 23, 2015 at 02:01:28PM -0600, Jeffrey Hugo wrote:
> On 4/11/2015 5:32 PM, Bjorn Andersson wrote:
> >Add device tree binding documentation for the Qualcom Shared Memory
> >manager.
> >
> >Signed-off-by: Bjorn Andersson 
> >---
> >
> >Changes since v1:
> >- None
> >
> >  .../devicetree/bindings/soc/qcom/qcom,smem.txt | 49 
> > ++
> >  1 file changed, 49 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
> >
> >diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt 
> >b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
> >new file mode 100644
> >index 000..d90f839
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt
> >@@ -0,0 +1,49 @@
> >+Qualcomm Shared Memory binding
> >+
> >+This binding describes the Qualcomm Shared Memory, used to share data 
> >between
> >+various subsystems and OSes in Qualcomm platforms.
> >+
> >+- compatible:
> >+Usage: required
> >+Value type: 
> >+Definition: must be:
> >+"qcom,smem"
> >+
> >+- memory-region:
> >+Usage: required
> >+Value type: 
> >+Definition: handle to memory reservation for main smem memory region.
> >+
> >+- reg:
> >+Usage: optional
> >+Value type: 
> >+Definition: base address and size pair for any additional memory areas
> >+of the shared memory.
> >+
> >+- hwspinlocks:
> >+Usage: required
> >+Value type: 
> >+Definition: reference to a hwspinlock used to protect allocations from
> >+the shared memory
> >+
> >+= EXAMPLE
> >+
> >+reserved-memory {
> >+#address-cells = <1>;
> >+#size-cells = <1>;
> >+ranges;
> >+
> >+smem_region: smem@fa0 {
> >+reg = <0xfa0 0x20>;
> >+no-map;
> >+};
> >+};
> >+
> >+smem@fa0 {
> >+compatible = "qcom,smem";
> >+
> >+memory-region = <_region>;
> >+reg = <0xfc428000 0x4000>;
> >+
> >+hwlocks = <_mutex 3>;
> >+};
> >
> 
> For my information, is there any intention to support the
> relocatable smem_region by looking it up at init time?  It does not
> seem like it would be possible to support that with this binding.

The APPS processor really doesn't need anything except the memory region in the
DT.  If it was truly going to be dynamic, we could modify the DT in the
bootloader to set the correct address.  We can let the other processors get the
information through the WONCE TCSR registers.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the 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] capabilities: Ambient capabilities

[Serge Hallyn]

Quoting Andy Lutomirski (l...@amacapital.net):
> On Apr 24, 2015 2:15 PM, "Serge E. Hallyn"  wrote:
> >
> > On Fri, Apr 24, 2015 at 01:18:44PM -0700, Andy Lutomirski wrote:
> > > On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter  wrote:
> > > > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> > > >
> > > >> That's sort of what my patch does -- you need CAP_SETPCAP to switch
> > > >> the securebit.
> > > >>
> > > >> But Christoph's patch required it to add caps to the ambient set, 
> > > >> right?
> > > >
> > > > Yes but you seem to be just adding one additional step without too much 
> > > > of
> > > > a benefit because you still need CAP_SETPCAP.
> > > >
> > >
> > > No, because I set the default to on :)
> >
> > Right - I definately prefer
> >
> > . default off
> > . CAP_SETPCAP required to turn it on (for self and children)
> > . once on, anyone can copy bits from (whatever we decided) to pA.
> >
> 
> Why default off?  If there's some weird reason that switching it on
> could cause a security problem, then I'd agree, but I haven't spotted
> a reason yet.

Cause it's less scary?

I'll just wait for the new patchset :)
--
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/4] regmap: cache: Add "was_reset" argument to regcache_sync_region()

[Kevin Cernekee]

On Fri, Apr 24, 2015 at 3:36 PM, Kevin Cernekee  wrote:
> regcache_sync() and regcache_sync_region() currently assume that the
> hardware has just emerged from a clean reset, and that all registers are
> in their default states.  But that isn't the only possibility; the device
> may have been in a different state in which the registers were
> inaccessible but have retained their contents, e.g. clock gating.
>
> So we will extend the more versatile of the two functions,
> regcache_sync_region(), to let the caller decide what assumptions should
> be made.
>
> One driver that can benefit from this is adau1977, which has hacks to
> overwrite the registers that regcache_sync() might have missed.  Also,
> the powerdown pin on tas571x does not reset the register contents either,
> so a similar feature will be required by that driver.
>
> This commit just adds the new argument by changing the function
> declarations and call sites, but doesn't wire it up yet.

The last two lines of the changelog were inadvertently carried over
from an older version of the patch, and should be deleted.  Will fix
in V3.
--
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] tick: Fix hang caused by hrtimer in broadcast mode

[Preeti U Murthy]

On 04/24/2015 06:36 PM, Andreas Sandberg wrote:
> The hrtimer callback in the hrtimer's tick broadcast code sometimes
> incorrectly ends up scheduling events at the current tick causing the
> kernel to hang servicing the same hrtimer forever. This typically
> happens when a device is swapped out by
> tick_install_broadcast_device(), which replaces the event handler with
> clock_events_handle_noop() and sets the device mode to
> CLOCK_EVT_MODE_UNUSED. If the timer is scheduled when this happens,
> the next_event field will not be updated and the hrtimer ends up being
> restarted at the current tick. To prevent this from happening, only
> try to restart the hrtimer if the broadcast clock event device is in
> one of the active modes and try to cancel the timer when entering the
> CLOCK_EVT_MODE_UNUSED mode.
> 
> Signed-off-by: Andreas Sandberg 
> Acked-by: Mark Rutland 
> Tested-by: Catalin Marinas 
> ---
>  kernel/time/tick-broadcast-hrtimer.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/time/tick-broadcast-hrtimer.c 
> b/kernel/time/tick-broadcast-hrtimer.c
> index 6aac4be..a20c605 100644
> --- a/kernel/time/tick-broadcast-hrtimer.c
> +++ b/kernel/time/tick-broadcast-hrtimer.c
> @@ -22,6 +22,7 @@ static void bc_set_mode(enum clock_event_mode mode,
>   struct clock_event_device *bc)
>  {
>   switch (mode) {
> + case CLOCK_EVT_MODE_UNUSED:
>   case CLOCK_EVT_MODE_SHUTDOWN:
>   /*
>* Note, we cannot cancel the timer here as we might
> @@ -99,10 +100,14 @@ static enum hrtimer_restart bc_handler(struct hrtimer *t)
>  {
>   ce_broadcast_hrtimer.event_handler(_broadcast_hrtimer);
>  
> - if (ce_broadcast_hrtimer.next_event.tv64 == KTIME_MAX)
> + switch (ce_broadcast_hrtimer.mode) {
> + case CLOCK_EVT_MODE_PERIODIC:
> + case CLOCK_EVT_MODE_ONESHOT:
> + if (ce_broadcast_hrtimer.next_event.tv64 != KTIME_MAX)
> + return HRTIMER_RESTART;
> + default:
>   return HRTIMER_NORESTART;
> -
> - return HRTIMER_RESTART;
> + }
>  }
>  
>  void tick_setup_hrtimer_broadcast(void)
> 
Looks good.

Reviewed-by: Preeti U. Murthy 

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

Re: Interacting with coherent memory on external devices

[Rik van Riel]

On 04/21/2015 05:44 PM, Paul E. McKenney wrote:

> AUTONUMA
> 
>   The Linux kernel's autonuma facility supports migrating both
>   memory and processes to promote NUMA memory locality.  It was
>   accepted into 3.13 and is available in RHEL 7.0 and SLES 12.
>   It is enabled by the Kconfig variable CONFIG_NUMA_BALANCING.
> 
>   This approach uses a kernel thread "knuma_scand" that periodically
>   marks pages inaccessible.  The page-fault handler notes any
>   mismatches between the NUMA node that the process is running on
>   and the NUMA node on which the page resides.

Minor nit: marking pages inaccessible is done from task_work
nowadays, there no longer is a kernel thread.

>   The result would be that the kernel would allocate only migratable
>   pages within the CCAD device's memory, and even then only if
>   memory was otherwise exhausted.

Does it make sense to allocate the device's page tables in memory
belonging to the device?

Is this a necessary thing with some devices? Jerome's HMM comes
to mind...

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

[GIT PULL] More ACPI and power management updates for v4.1-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm+acpi-4.1-rc1-2

to receive additional power management and ACPI material for v4.1-rc1
with top-most commit e0155a99b28f63e007c0c74076ad8ae486a3c9d3

 Merge branches 'acpi-dock', 'acpi-ec' and 'acpi-scan'

on top of commit 0f5abd4020bfd2b1eec6975b91bd5068aa674a93

 Merge tag 'acpica-4.1-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

These are fixes mostly (intel_pstate, ACPI core, ACPI EC driver, cpupower
tool), a new CPU ID for the Intel RAPL driver and one intel_pstate driver
improvement that didn't make it to my previous pull requests due to timing.

Specifics:

 - Fix a build warning in the intel_pstate driver showing up in non-SMP
   builds (Borislav Petkov).

 - Change one of the intel_pstate's P-state selection parameters for
   Baytrail and Cherrytrail CPUs to significantly improve performance
   at the cost of a small increase in energy consumption (Kristen
   Carlson Accardi).

 - Fix a NULL pointer dereference in the ACPI EC driver due to an unsafe
   list walk in the query handler removal routine (Chris Bainbridge).

 - Get rid of a false-positive lockdep warning in the ACPI container
   hot-remove code (Rafael J Wysocki).

 - Prevent the ACPI device enumeration code from creating device
   objects of a wrong type in some cases (Rafael J Wysocki).

 - Add Skylake processors support to the Intel RAPL power capping
   driver (Brian Bian).

 - Drop the stale MAINTAINERS entry for the ACPI dock driver that is
   regarded as part of the ACPI core and maintained along with it now
   (Chao Yu).

 - Fix cpupower tool breakage caused by a library API change in libpci
   3.3.0 (Lucas Stach).

Thanks!


---

Borislav Petkov (1):
  cpufreq: intel_pstate: Fix an annoying !CONFIG_SMP warning

Brian Bian (1):
  powercap / RAPL: Add support for Intel Skylake processors

Chao Yu (1):
  MAINTAINERS: remove maintainship entry of docking station driver

Chris Bainbridge (1):
  ACPI / EC: fix NULL pointer dereference in acpi_ec_remove_query_handler()

Kristen Carlson Accardi (1):
  intel_pstate: Change the setpoint for Atom params

Lucas Stach (1):
  cpupower: fix breakage from libpci API change

Rafael J. Wysocki (2):
  ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()
  ACPI / scan: Add a scan handler for PRP0001

---

 MAINTAINERS  |  6 -
 drivers/acpi/ec.c|  2 +-
 drivers/acpi/scan.c  | 39 +++-
 drivers/cpufreq/intel_pstate.c   | 14 ++--
 drivers/powercap/intel_rapl.c|  1 +
 tools/power/cpupower/utils/helpers/pci.c | 11 +++--
 6 files changed, 51 insertions(+), 22 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[Denys Vlasenko]

On Fri, Apr 24, 2015 at 10:50 PM, Andy Lutomirski  wrote:
> On Fri, Apr 24, 2015 at 1:46 PM, Denys Vlasenko
>>> This might be way more trouble than it's worth.
>>
>> Exactly my feeling. What are you trying to save? About four CPU
>> cycles of checking %ss != __KERNEL_DS on each switch_to?
>> That's not worth bothering about. Your last patch seems to be perfect.
>
> We'll have to do the write to ss almost every time an AMD CPU sleeps
> in a syscall.

Why do you think so?
Scheduling from a syscall which decided to block won't require
writing to %ss, since in this case %ss isn't NULL.

Writing to %ss will happen every time we schedule from an interrupt.
With timer interrupt every 1 ms it means scheduling at most ~1000
times per second, if _every_ such interrupt causes task switch.
This is still not often enough to worry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] mm: catch memory commitment underflow

[Sasha Levin]

On 01/18/2015 01:36 PM, Konstantin Khlebnikov wrote:
> On Sun, Jan 18, 2015 at 2:34 PM, Sasha Levin  wrote:
>> On 06/24/2014 04:16 PM, Konstantin Khlebnikov wrote:
>>> This patch prints warning (if CONFIG_DEBUG_VM=y) when
>>> memory commitment becomes too negative.
>>>
>>> Signed-off-by: Konstantin Khlebnikov 
>>
>> Hi Konstantin,
>>
>> I seem to be hitting this warning when fuzzing on the latest -next kernel:
> 
> That might be unexpected change of shmem file which holds anon-vma data,
> thanks to checkpoint-restore they are expoted via /proc/.../map_files
> 
> I've fixed truncate (https://lkml.org/lkml/2014/6/24/729) but there
> are some other ways
> to change i_size: write, fallocate and maybe something else.

deja vu!

With the latest -next:

[  884.898243] [ cut here ]
[  884.899983] [ cut here ]
[  884.900013] WARNING: CPU: 5 PID: 17543 at mm/mmap.c:159 
__vm_enough_memory+0x3b7/0x440()
[  884.900017] [ cut here ]
[  884.900155] memory commitment underflow
[  884.900158] Modules linked in:
[  884.900167] CPU: 5 PID: 17543 Comm: trinity-c102 Not tainted 
4.0.0-next-20150424-sasha-00038-ga61bf14 #2171
[  884.900180] WARNING: CPU: 0 PID: 18483 at mm/mmap.c:159 
__vm_enough_memory+0x3b7/0x440()
[  884.900185]  88017e18
[  884.900188] memory commitment underflow
[  884.900190]  12331894
[  884.900193] Modules linked in:
[  884.900195]  8807dd8bf5a8
[  884.900196]
[  884.900200]  a9abbf32
[  884.900211]   8807dd8bf628 8807dd8bf5f8 
9f1f1c2a
[  884.900222]  8807dd8bf5d8 9f5efb27 8807dd8bf628 
ed00fbb17ec1
[  884.900230] Call Trace:
[  884.900247] dump_stack (lib/dump_stack.c:52)
[  884.900260] warn_slowpath_common (kernel/panic.c:447)
[  884.900270] ? __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[  884.900278] warn_slowpath_fmt (kernel/panic.c:453)
[  884.900286] ? warn_slowpath_common (kernel/panic.c:453)
[  884.900300] ? find_get_entry (include/linux/rcupdate.h:969 mm/filemap.c:1003)
[  884.900310] __vm_enough_memory (mm/mmap.c:157 (discriminator 3))
[  884.900317] ? find_get_entry (mm/filemap.c:967)
[  884.900334] cap_vm_enough_memory (security/commoncap.c:954)
[  884.900344] security_vm_enough_memory_mm (security/security.c:235)
[  884.900355] shmem_getpage_gfp (mm/shmem.c:1156)
[  884.900369] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[  884.900382] ? lockdep_init (include/linux/list.h:28 
kernel/locking/lockdep.c:4065)
[  884.900391] ? shmem_add_to_page_cache (mm/shmem.c:1034)
[  884.900402] ? __wake_up_locked_key (kernel/sched/wait.c:456)
[  884.900414] ? __bdi_update_bandwidth (mm/page-writeback.c:1579)
[  884.900422] ? __lock_is_held (kernel/locking/lockdep.c:3572)
[  884.900432] ? iov_iter_single_seg_count (lib/iov_iter.c:310)
[  884.900441] shmem_write_begin (mm/shmem.c:1492)
[  884.900450] generic_perform_write (mm/filemap.c:2467)
[  884.900461] ? generic_write_checks (mm/filemap.c:2427)
[  884.900475] ? file_update_time (fs/inode.c:1746)
[  884.900483] ? file_remove_suid (fs/inode.c:1718)
[  884.900492] ? generic_file_write_iter (include/linux/sched.h:3091 
include/linux/sched.h:3102 mm/filemap.c:2269 mm/filemap.c:2622)
[  884.900501] ? mutex_trylock (kernel/locking/mutex.c:615)
[  884.900510] __generic_file_write_iter (mm/filemap.c:2597)
[  884.900521] ? get_parent_ip (kernel/sched/core.c:2556)
[  884.900531] generic_file_write_iter (mm/filemap.c:2625)
[  884.900543] do_iter_readv_writev (fs/read_write.c:665)
[  884.900551] ? do_readv_writev (include/linux/fs.h:2417 fs/read_write.c:804)
[  884.900558] ? do_loop_readv_writev (fs/read_write.c:657)
[  884.900567] ? rw_verify_area (fs/read_write.c:406 (discriminator 4))
[  884.900576] do_readv_writev (fs/read_write.c:808)
[  884.900583] ? __generic_file_write_iter (mm/filemap.c:2616)
[  884.900591] ? vfs_write (fs/read_write.c:777)
[  884.900601] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[  884.900609] ? get_lock_stats (kernel/locking/lockdep.c:249)
[  884.900621] ? vtime_account_user (kernel/sched/cputime.c:701)
[  884.900630] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[  884.900639] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 
kernel/locking/lockdep.c:2636)
[  884.900646] ? trace_hardirqs_on (kernel/locking/lockdep.c:2644)
[  884.900654] vfs_writev (fs/read_write.c:848)
[  884.900663] SyS_writev (fs/read_write.c:881 fs/read_write.c:872)
[  884.900671] ? SyS_readv (fs/read_write.c:872)
[  884.900684] ? syscall_trace_enter_phase2 (arch/x86/kernel/ptrace.c:1592)
[  884.900693] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[  884.900703] tracesys_phase2 (arch/x86/kernel/entry_64.S:337)
[  884.900716] ? __percpu_counter_sum (lib/percpu_counter.c:107)
[  884.900723] ---[ end trace 957b1b1a507acb40 ]---
[  884.900730] CPU: 0 PID: 18483 C

Re: [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing

[Rafael J. Wysocki]

On Friday, April 24, 2015 04:08:31 PM Suravee Suthikulpanit wrote:
> On 4/16/15 20:45, Zheng, Lv wrote:
> > Before back porting this to ACPICA, let me ask one simple question.
> > According to the spec, the _CLS is optional and PCI specific.
> > So why should we implement it in ACPICA core not OSPM specific modules?
> > If this need to be implemented in ACPICA, then what about the following 
> > device identification objects?
> > _DDN, _HRV, _MLS, _PLD, _STR, _SUN
> >
> > Thanks and best regards
> > -Lv
> 
> Hi,
> 
> Sorry for late reply. As for the justification for introducing the _CLS 
> support in the ACPICA, this is mainly because ACPI does not currently 
> define _CID for certain device classes, which used to mostly be PCI 
> devices. Instead, ACPI spec mentioned that _CLS can be used for loading 
> generic drivers on hardware that is compatible with PCI-defined device 
> classes, but that is not implemented on the PCI bus (and is therefore 
> enumerated by ACPI.)

I think it would be good to point to the particular part of the spec
making that provision.  In what section is that mentioned, exactly?


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

Re: [Update][PATCH] ACPI / scan: Add a scan handler for PRP0001

[Rafael J. Wysocki]

On Friday, April 24, 2015 03:21:00 PM Darren Hart wrote:
> On Fri, Apr 24, 2015 at 02:15:22AM +0200, Rafael Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > If the special PRP0001 device ID is present in the given device's list
> > of ACPI/PNP IDs and the device has a valid "compatible" property in
> > the _DSD, it should be enumerated using the default mechanism,
> > unless some scan handlers match the IDs preceding PRP0001 in the
> > device's list of ACPI/PNP IDs.  In addition to that, no scan handlers
> > matching the IDs following PRP0001 in that list should be attached
> > to the device.
> > 
> > To make that happen, define a scan handler that will match PRP0001
> > and trigger the default enumeration for the matching devices if the
> > "compatible" property is present for them.
> > 
> > Since that requires the check for platform_id and device->handler
> > to be removed from acpi_default_enumeration(), move the fallback
> > invocation of acpi_default_enumeration() to acpi_bus_attach()
> > (after it's checked if there's a matching ACPI driver for the
> > device), which is a better place to call it, and do the platform_id
> > check in there too (device->handler is guaranteed to be unset at
> > the point where the function is looking for a matching ACPI driver).
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > Acked-by: Darren Hart 
> > ---
> > 
> > The change from the original patch is to change the scan handler
> > behavior to make it return 1 also if the "compatible" property is
> > not present, in which case the additional scan handlers should not
> > trigger too *and* the default enumeration should not trigger either
> > (as there's no ID to match to), which will allow things like
> > auxiliary nodes (think GPIO buttons/LEDs etc) to be easily represented.
> 
> 
> This should probably be spelled out in the commit message itself as it's a 
> fairly
> unique condition.

I'm going to document that in Documentation/acpi/enumeration.txt anyway.

> > Darren, I've tentatively added your Acked-by tag to this one, please
> > let me know if that's not appropriate.
> 
> Spent a bit more time on it this time, so:
> 
> Reviewed-by: Darren Hart 

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] pxa168: fix double deallocation of managed resources

[Alexey Khoroshilov]

Commit 43d3ddf87a57 ("net: pxa168_eth: add device tree support") starts
to use managed resources by adding devm_clk_get() and
devm_ioremap_resource(), but it leaves explicit iounmap() and clock_put()
in pxa168_eth_remove() and in failure handling code of pxa168_eth_probe().
As a result double free can happen.

The patch removes explicit resource deallocation. Also it converts
clk_disable() to clk_disable_unprepare() to make it symmetrical with
clk_prepare_enable().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/net/ethernet/marvell/pxa168_eth.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c 
b/drivers/net/ethernet/marvell/pxa168_eth.c
index af829c578400..7ace07dad6a3 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1508,7 +1508,8 @@ static int pxa168_eth_probe(struct platform_device *pdev)
np = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
if (!np) {
dev_err(>dev, "missing phy-handle\n");
-   return -EINVAL;
+   err = -EINVAL;
+   goto err_netdev;
}
of_property_read_u32(np, "reg", >phy_addr);
pep->phy_intf = of_get_phy_mode(pdev->dev.of_node);
@@ -1526,7 +1527,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
pep->smi_bus = mdiobus_alloc();
if (pep->smi_bus == NULL) {
err = -ENOMEM;
-   goto err_base;
+   goto err_netdev;
}
pep->smi_bus->priv = pep;
pep->smi_bus->name = "pxa168_eth smi";
@@ -1551,13 +1552,10 @@ err_mdiobus:
mdiobus_unregister(pep->smi_bus);
 err_free_mdio:
mdiobus_free(pep->smi_bus);
-err_base:
-   iounmap(pep->base);
 err_netdev:
free_netdev(dev);
 err_clk:
-   clk_disable(clk);
-   clk_put(clk);
+   clk_disable_unprepare(clk);
return err;
 }
 
@@ -1574,13 +1572,9 @@ static int pxa168_eth_remove(struct platform_device 
*pdev)
if (pep->phy)
phy_disconnect(pep->phy);
if (pep->clk) {
-   clk_disable(pep->clk);
-   clk_put(pep->clk);
-   pep->clk = NULL;
+   clk_disable_unprepare(pep->clk);
}
 
-   iounmap(pep->base);
-   pep->base = NULL;
mdiobus_unregister(pep->smi_bus);
mdiobus_free(pep->smi_bus);
unregister_netdev(dev);
-- 
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: Interacting with coherent memory on external devices

[Benjamin Herrenschmidt]

On Fri, 2015-04-24 at 11:58 -0500, Christoph Lameter wrote:
> On Fri, 24 Apr 2015, Jerome Glisse wrote:
> 
> > > What exactly is the more advanced version's benefit? What are the features
> > > that the other platforms do not provide?
> >
> > Transparent access to device memory from the CPU, you can map any of the GPU
> > memory inside the CPU and have the whole cache coherency including proper
> > atomic memory operation. CAPI is not some mumbo jumbo marketing name there
> > is real hardware behind it.
> 
> Got the hardware here but I am getting pretty sobered given what I heard
> here. The IBM mumbo jumpo marketing comes down to "not much" now.

Ugh ... first nothing we propose precludes using it with explicit memory
management the way you want. So I don't know why you have a problem
here. We are trying to cover a *different* usage model than yours
obviously. But they aren't exclusive.

Secondly, none of what we are discussing here is supported by *existing*
hardware, so whatever you have is not concerned. There is no CAPI based
coprocessor today that provides cachable memory to the system (though
CAPI as a technology supports it), and no GPU doing that either *yet*.
Today CAPI adapters can own host cache lines but don't expose large
swath of cachable local memory.

Finally, this discussion is not even specifically about CAPI or its
performances. It's about the *general* case of a coherent coprocessor
sharing the MMU. Whether it's using CAPI or whatever other technology
that allows that sort of thing that we may or may not be able to mention
at this point.

CAPI is just an example because architecturally it allows that too.

Ben.



--
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-nvdimm] [PATCH 08/21] nd: ndctl.h, the nd ioctl abi

[Toshi Kani]

On Fri, 2015-04-24 at 10:45 -0700, Dan Williams wrote:
> On Fri, Apr 24, 2015 at 10:18 AM, Toshi Kani  wrote:
> > On Fri, 2015-04-24 at 09:25 -0700, Dan Williams wrote:
> >> On Fri, Apr 24, 2015 at 8:56 AM, Toshi Kani  wrote:
> >> > On Fri, 2015-04-17 at 21:35 -0400, Dan Williams wrote:
> >> >> Most configuration of the nd-subsystem is done via nd-sysfs.  However,
> >> >> the NFIT specification defines a small set of messages that can be
> >> >> passed to the subsystem via platform-firmware-defined methods.  The
> >> >> command set (as of the current version of the NFIT-DSM spec) is:
> >> >>
> >> >> NFIT_CMD_SMART: media health and diagnostics
> >> >> NFIT_CMD_GET_CONFIG_SIZE: size of the label space
> >> >> NFIT_CMD_GET_CONFIG_DATA: read label
> >> >> NFIT_CMD_SET_CONFIG_DATA: write label
> >> >> NFIT_CMD_VENDOR: vendor-specific command passthrough
> >> >> NFIT_CMD_ARS_CAP: report address-range-scrubbing capabilities
> >> >> NFIT_CMD_START_ARS: initiate scrubbing
> >> >> NFIT_CMD_QUERY_ARS: report on scrubbing state
> >> >> NFIT_CMD_SMART_THRESHOLD: configure alarm thresholds for smart 
> >> >> events
> >> >
> >> > "nd/bus.c" provides two features, 1) the top level ND bus driver which
> >> > is the central part of the ND, and 2) the ioctl interface specific to
> >> > the example-DSM-interface.  I think the example-DSM-specific part should
> >> > be put into an example-DSM-support module, so that the ND can support
> >> > other _DSMs as necessary.  Also, _DSM needs to be handled as optional.
> >>
> >> I don't think it needs to be separated, they'll both end up using the
> >> same infrastructure just with different UUIDs on the ACPI device
> >> interface or different format-interface-codes.  A firmware
> >> implementation is also free to disable individual DSMs (see
> >> nd_acpi_add_dimm).
> >
> > Well, ioctl cmd# is essentially func# of the _DSM, and each cmd
> > structure needs to match with its _DSM output data structure.  So, I do
> > not think these cmds will work for other _DSMs.  That said, the ND is
> > complex enough already, and we should not make it more complicated for
> > the initial version...  So, how about changing the name of /dev/ndctl0
> > to indicate RFIC 0x0201, ex. /dev/nd0201ctl0?  That should allow
> > separate ioctl()s for other RFICs.  The code can be updated when other
> > _DSM actually needs to be supported by the ND.
> 
> No, all you need is unique command names (see libndctl
> ndctl_{bus|dimm}_is_cmd_supported()) and then translate the ND cmd
> number to the firmware function number in the "provider".  It just so
> happens that for these first set of commands the ND cmd number matches
> the ACPI device function number in the DSM-interface-example, but
> there is no reason that need always be the case.

I misread the code -- /dev/ndctlN is for a bus, and /dev/nmemN is for a
DIMM.  RFIC 0x0201 matches to DIMMs, not the bus.  Since the _DSM under
ACPI0013 is generic, we are probably OK with ndctl.

The DIMM driver is fully integrated with the example-DSM.  Separating
nd/acpi.c alone would not solve it...  In your fix that will make the
DIMM _DSM optional, do you plan to make the DIMM driver more independent
from the example-DIMM _DSM?

Thanks,
-Toshi

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

Re: [PATCH v2 2/2] soc: qcom: Add Shared Memory Manager driver

[Bjorn Andersson]

On Thu 23 Apr 14:18 PDT 2015, Jeffrey Hugo wrote:

> This is different, but I rather quite like its simplicity.  Some nits
> and requested clarifications below
> 

Thanks.

> On 4/11/2015 5:32 PM, Bjorn Andersson wrote:
> > The Shared Memory Manager driver implements an interface for allocating
> > and accessing items in the memory area shared among all of the
> > processors in a Qualcomm platform.
> >
> > Signed-off-by: Bjorn Andersson 
[..]
> > diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
[..]
> > +
> > +/*
> > + * The Qualcomm shared memory system is a allocate only heap structure that
> 
> "an allocate"
> 

Thanks

[..]
> > +/**
> > +  * struct smem_proc_comm - proc_comm communication struct (legacy)
> > +  * @command:current command to be executed
> > +  * @status: status of the currently requested command
> > +  * @params: parameters to the command
> > +  */
> 
> Comment block does not appear to be correctly lined up.  Lines after the
> "/**" should be lined up with the first *, not the second *.
> 

Thanks

[..]
> > +/**
> > + * struct smem_header - header found in beginning of primary smem region
> > + * @proc_comm:   proc_comm communication interface (legacy)
> > + * @version: array of versions for the various subsystems
> > + * @initialized: boolean to indicate that smem is initialized
> > + * @free_offset: index of the first unallocated byte in smem
> > + * @available:   number of bytes available for allocation
> > + * @reserved:reserved field, must be 0
> > + * toc:  array of references to items
> 
> @toc
> 

Thanks

[..]
> > +struct smem_header {
> > + struct smem_proc_comm proc_comm[4];
> > + u32 version[32];
> > + u32 initialized;
> > + u32 free_offset;
> > + u32 available;
> > + u32 reserved;
> > + struct smem_global_entry toc[];
> 
> Was it intentional to not have "toc[512]"?
> 

Not really, I can add it to make it clear that it's a fixed amount.

[..]
> > +/*
> > + * Item 3 of the global heap contains an array of versions for the various
> > + * software components in the SoC. We verify that the boot loader version 
> > is
> > + * what the expected version (SMEM_EXPECTED_VERSION) as a sanity check.
> > + */
> > +#define SMEM_ITEM_VERSION3
> > +#define  SMEM_MASTER_SBL_VERSION_INDEX   7
> > +#define  SMEM_EXPECTED_VERSION   11
> 
> Any particular reason why some of these defines lead with 2 spaces, and
> some with 1 space?
> 

It's intentional to indicate the index is a "child" of the item. Maybe I
should just revise the naming of these, I will give it some more though.

[..]
> > +/* Max number of processors/hosts in a system */
> > +#define SMEM_HOST_COUNT  7
> 
> Go ahead and make this 9.  Downstream just added 2 Hosts.
> 

Thanks, will do.

[..]
> > +/* Timeout (ms) for the trylock of remote spinlocks */
> > +#define HWSPINLOCK_TIMEOUT   1000
> 
> I'm curious what made you pick 1 second as a timeout value?
> 

Sorry, I don't have even a tiny bit of science behind this number. I
figured it's long enough to not have any false negatives and it's short
enough to not be intrusive if some remote processor actually dies with
the lock held.

[..]
> > +static int qcom_smem_alloc_private(struct qcom_smem *smem,
> > +unsigned host,
> > +unsigned item,
> > +size_t size)
> > +{
> > + struct smem_partition_header *phdr;
> > + struct smem_private_entry *hdr;
> > + size_t alloc_size;
> > + void *p;
> > +
> > + /* We're not going to find it if there's no matching partition */
> > + if (host >= SMEM_HOST_COUNT || !smem->partitions[host])
> > + return -ENOENT;
> > +
> > + phdr = smem->partitions[host];
> > +
> > + p = (void *)phdr + sizeof(*phdr);
> > + while (p < (void *)phdr + phdr->offset_free_uncached) {
> > + hdr = p;
> > +
> > + if (hdr->canary != SMEM_PRIVATE_CANARY) {
> > + dev_err(smem->dev,
> > + "Found invalid canary in host %d partition\n",
> > + host);
> > + return -EINVAL;
> > + }
> > +
> > + if (hdr->item == item)
> > + return -EEXIST;
> > +
> > + p += sizeof(*hdr) + hdr->padding_hdr + hdr->size;
> > + }
> 
> Why not just use qcom_smem_get_private() instead of duplicating the
> algorithm here?
> 

Excellent question, I'll do so :)

[..]
> > +/**
> > + * qcom_smem_alloc - allocate space for a smem item
> 
> qcom_smem_alloc()
> 

Thanks

[..]
> > +/**
> > + * qcom_smem_get - resolve ptr of size of a smem item
> 
> qcom_smem_get()
> 

Thanks

[..]
> > +/**
> > + * qcom_smem_get_free_space - retrieve amont of free space in a partition
> 
> "qcom_smem_get_free_space()"
> "ammount"
> 

Thanks

> > + * @host:the 

Re: [PATCH] ARM: rockchip: disable dapswjdp during suspend

[Heiko Stübner]

Am Mittwoch, 15. April 2015, 13:57:11 schrieb Chris Zhong:
> Reset dapswjdp is controlled by JTAG_TRSTN, if the iomux of this pin is
> not "jtag_trstn". the AP would think this pin is always high, so it can
> not reset before resume. When system resume, but the dapswjdp is not in
> a default state, it may Access some illegal address, it cause system
> crash during resume.
> Let's disable this jtag function by clear the dapdeviceen bit, it
> prohibit the dapswjdp to access memory and registers. This bit would
> be enable in MASKROM, so we need clear it in suspend everytime.
> 
> Signed-off-by: Chris Zhong 

applied to a fixes branch for 4.1


Thanks
Heiko
--
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] perf: top: fix a segfault when kernel map is restricted.

[Wang Nan]

Perf top raise a warning if a kernel sample is collected but kernel map
is restricted. The warning message needs to dereference al.map->dso...
However, previous perf_event__preprocess_sample() doesn't always
guarantee al.map != NULL, for example, when kernel map is restricted.

This patch validates al.map before dereferencing, avoid the segfault.

Before this patch:

 $ cat /proc/sys/kernel/kptr_restrict
 1
 $ perf top -p  120183
 perf: Segmentation fault
  backtrace 
 /path/to/perf[0x509868]
 /lib64/libc.so.6(+0x3545f)[0x7f9a1540045f]
 /path/to/perf[0x448820]
 /path/to/perf(cmd_top+0xe3c)[0x44a5dc]
 /path/to/perf[0x4766a2]
 /path/to/perf(main+0x5f5)[0x42e545]
 /lib64/libc.so.6(__libc_start_main+0xf4)[0x7f9a153ecbd4]
 /path/to/perf[0x42e674]

And gdb call trace:

 Program received signal SIGSEGV, Segmentation fault.
 perf_event__process_sample (machine=0xa44030, sample=0x7fffa4c0, 
evsel=0xa43b00, event=0x741c3000, tool=0x7fffa8a0)
at builtin-top.c:736
 736  
!RB_EMPTY_ROOT(>dso->symbols[MAP__FUNCTION]) ?
 (gdb) bt
 #0  perf_event__process_sample (machine=0xa44030, sample=0x7fffa4c0, 
evsel=0xa43b00, event=0x741c3000, tool=0x7fffa8a0)
 at builtin-top.c:736
 #1  perf_top__mmap_read_idx (top=top@entry=0x7fffa8a0, idx=idx@entry=0) at 
builtin-top.c:855
 #2  0x0044a5dd in perf_top__mmap_read (top=0x7fffa8a0) at 
builtin-top.c:872
 #3  __cmd_top (top=0x7fffa8a0) at builtin-top.c:997
 #4  cmd_top (argc=, argv=, prefix=) at builtin-top.c:1267
 #5  0x004766a3 in run_builtin (p=p@entry=0x8a6ce8 , 
argc=argc@entry=3, argv=argv@entry=0x7fffdf70)
  at perf.c:371
 #6  0x0042e546 in handle_internal_command (argv=0x7fffdf70, 
argc=3) at perf.c:430
 #7  run_argv (argv=0x7fffdcf0, argcp=0x7fffdcfc) at perf.c:474
 #8  main (argc=3, argv=0x7fffdf70) at perf.c:589
 (gdb)

Signed-off-by: Wang Nan 
---
 tools/perf/builtin-top.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 1cb3436..6a4d5d4 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -733,7 +733,7 @@ static void perf_event__process_sample(struct perf_tool 
*tool,
 "Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
 "Check /proc/sys/kernel/kptr_restrict.\n\n"
 "Kernel%s samples will not be resolved.\n",
- !RB_EMPTY_ROOT(>dso->symbols[MAP__FUNCTION]) ?
+ al.map && 
!RB_EMPTY_ROOT(>dso->symbols[MAP__FUNCTION]) ?
  " modules" : "");
if (use_browser <= 0)
sleep(5);
-- 
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/

Shouldn't mangle_path always mangle '\\'?

[Daniel Colascione (SEATTLE)]

mangle_path accepts a string listing the characters it's supposed to
escape. Some, but not all, callers put backslash in this set. Shouldn't
we be escaping '\' regardless, since it's the character used to signal
all other escapes?

diff --git a/fs/seq_file.c b/fs/seq_file.c
index 555f821..02dcd5c 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -443,7 +443,7 @@ char *mangle_path(char *s, const char *p, const char
*esc)
char c = *p++;
if (!c) {
return s;
-   } else if (!strchr(esc, c)) {
+   } else if (s != '\\' && !strchr(esc, c)) {
*s++ = c;
} else if (s + 4 > p) {
break;



signature.asc
Description: OpenPGP digital signature

Re: [RFC 00/12] On-demand device registration

[Alexander Holler]

Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso:
> Hi,
> 
> while reading the thread [0] that Alexander Holler started with his series to 
> make probing order deterministic, it occurred to me that it should be 
> possible to achieve the same by probing devices as they are referenced by 
> other devices.
> 
> This basically reuses the information that is already embedded in the probe() 
> implementations, saving us from refactoring existing drivers or adding 
> information to DTBs.
> 
> The main issue I see is that the registration code path in some subsystems 
> may not be reentrant, so some refactoring of the locking will be needed. In 
> my testing I have found this problem with regulators, as the supply of a 
> regulator might end up being registered during the registration of the first 
> one.
> 
> Something I'm not completely happy with is that I have had to move the 
> population of the device tree after all platform drivers have been 
> registered. Otherwise I don't see how I could register drivers on demand as 
> we don't have yet each driver's compatible strings.
> 
> I have done my testing on a Tegra124-based Chromebook, and these patches were 
> enough to eliminate all the deferred probes.

First you have to solve a problem which is totally unrelated to DT or
ACPI or x86 or ARM:

I think as long as drivers don't register themself whithout any side
effect, this problem isn't solvable. In order to make an ordered list of
drivers to start, you need to know which drivers are actually available.

And also drivers are registering themself with their initcall, they
might do an awfull lot of stuff besides just registering themself. That
means several drivers already have prerequisites and dependcies for
their initcall. That means you can't just call their initcall to get and
idea of which driver an initcall is even part of.

That ends up with the fact that you just don't have a list of drivers
you can sort, based on whatever algorithm you might have in mind.

I've tried to solve that problem with marking drivers which don't have
any prerequisits (and side effects) as "well done".

The patch which did that was 5/9 in my series, this one:

https://lkml.org/lkml/2014/5/12/414

Unfortunately nobody seemed really interested and without one of the few
"big guys" in your pocket, it's absolutely impossible to get such
changes into the kernel.

Not to speak about all the unavoidable discussions about absolutely
silly things.

But maybe I'm the problem here. No idea. I wish you more luck than I had
in the past two or three years.

Regards,

Alexander Holler
--
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] enforce function inlining for hot functions

[Hagen Paul Pfeifer]

* Paul E. McKenney | 2015-04-24 13:13:40 [-0700]:

>Hmmm...  allyesconfig would have PROVE_RCU=y, which would mean that the
>above two would contain lockdep calls that might in some cases defeat
>inlining.  With the more typical production choice of PROVE_RCU=n, I would
>expect these to just be a call instruction, which should get inlined.


Ok, here are the results:

with PROVE_RCU=y:
rcu_read_lock: 383 duplicates
with PROVE_RCU=n:
rcu_read_lock: 114 duplicates


If you look at the function anatomy of rcu_read_lock you often see the
following definitions:

:
 55push   %rbp
 48 89 e5  mov%rsp,%rbp
 48 c7 c7 50 64 e7 85  mov$0x85e76450,%rdi
 e8 ce ff ff ffcallq  816af206 
 5dpop%rbp
 c3retq

but sometimes rcu_read_lock looks:

:
 55push   %rbp
 48 89 e5  mov%rsp,%rbp
 50push   %rax
 68 83 1e 1c 81pushq  $0x811c1e83
 b9 02 00 00 00mov$0x2,%ecx
 31 d2 xor%edx,%edx
 45 31 c9  xor%r9d,%r9d
 45 31 c0  xor%r8d,%r8d
 31 f6 xor%esi,%esi
 48 c7 c7 50 64 e7 85  mov$0x85e76450,%rdi
 e8 86 4c f9 ffcallq  81156b2e 
 5apop%rdx
 59pop%rcx
 c9leaveq   
 c3retq


Means rcu_lock_acquire() is inlined here - but not in every compilation unit.
Don't know exactly what forces gcc to inline not everywhere. Maybe register
pressure in the function unit, or at least gcc is think that. I don't know.

At the end you may notice that gcc inlining decisions are not always perfect
and a little bit fuzzy (sure, they have their metric/scoring system). And
sometimes the inlining should be enforced - as this patch do for some important
functions. But as I said we should not enforce it everywhere, rather we should
pray for better heuristics and let the compiler choose the best strategy (and
incorporate -Os/-O2 decisions too). I think this is the best compromise here.

Cheers, Hagen
--
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 06/21] ARCNET: com20020: remove unneeded macros

[Joe Perches]

On Fri, 2015-04-24 at 19:20 +0200, Michael Grzeschik wrote:
> The macros SET_SUBADR, ARCRESET, ARCRESET0, ACOMMAND, ASTATUS, AINTMASK
> and ADIAGSTATUS are unnecessary indirections to the use of registers.
> This patch removes them and improves the readability of the code.

This breaks compilation.

Please compile test your patches before sending them.


--
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/1] scsi: storvsc: Set the SRB flags correctly when no data transfer is needed

[K. Y. Srinivasan]

Set the SRB flags correctly when there is no data transfer.

Cc: 
Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index d9dad90..3c6584f 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1600,8 +1600,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
break;
default:
vm_srb->data_in = UNKNOWN_TYPE;
-   vm_srb->win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN |
-SRB_FLAGS_DATA_OUT);
+   vm_srb->win8_extension.srb_flags |= SRB_FLAGS_NO_DATA_TRANSFER;
break;
}
 
-- 
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: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

[Dan Williams]

On Fri, Apr 24, 2015 at 2:59 PM, Linda Knippers  wrote:
> On 4/24/2015 5:50 PM, Dan Williams wrote:
>> On Fri, Apr 24, 2015 at 2:47 PM, Linda Knippers  
>> wrote:
>>> On 4/17/2015 9:35 PM, Dan Williams wrote:
>>> :
 diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
 index 5fa74f124b3e..0106b3807202 100644
 --- a/drivers/block/nd/Kconfig
 +++ b/drivers/block/nd/Kconfig
 @@ -41,4 +41,24 @@ config NFIT_ACPI
 register the platform-global NFIT blob with the core.  Also
 enables the core to craft ACPI._DSM messages for platform/dimm
 configuration.
 +
 +config NFIT_TEST
 + tristate "NFIT TEST: Manufactured NFIT for interface testing"
 + depends on DMA_CMA
 + depends on ND_CORE=m
 + depends on m
 + help
 +   For development purposes register a manufactured
 +   NFIT table to verify the resulting device model topology.
 +   Note, this module arranges for ioremap_cache() to be
 +   overridden locally to allow simulation of system-memory as an
 +   io-memory-resource.
 +
 +   Note, this test expects to be able to find at least
 +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to
>>>
>>> It seems to actually be wanting >= 584MB.
>>
>> Ah, true, this Kconfig text is stale.  Will fix.
>
> Thanks.  One more question...
>
>> +#ifdef CONFIG_CMA_SIZE_MBYTES
>> +#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
>> +#else
>> +#define CMA_SIZE_MBYTES 0
>> +#endif
>> +
>> +static __init int nfit_test_init(void)
>> +{
>> + int rc, i;
>> +
>> + if (CMA_SIZE_MBYTES < 584) {
>> + pr_err("need CONFIG_CMA_SIZE_MBYTES >= 584 to load\n");
>> + return -EINVAL;
>> + }
>> +
>
> Since the kernel takes a cma= boot parameter, it would be nice if
> this check is against what the kernel is using rather than the config
> option.  Is that possible?

Yeah, that would be more friendly.  I also think we can reduce the BLK
aperture sizes.  Since those don't need to be DAX capable they can
come from vmalloc memory rather than CMA.  I'll take a look.
--
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] x86, fpu: rename XCR0 access macro

[Dave Hansen]

From: Dave Hansen 

The SDM says that the xgetbv instruction:

Reads the contents of the extended control register (XCR)
specified in the ECX register into registers EDX:EAX.

In other words, xgetbv(0) gets the thing that the SDM calls XCR0.
We have a macro for that "0" and we call it
XCR_XFEATURE_ENABLED_MASK.  That's a bit unfortunate because it
is not a mask nor does the "0" have much to do with the features
we have enabled.  It's an index if anything.

Rename the macro to what it means: "XCR0".

Signed-off-by: Dave Hansen 
Cc: x...@kernel.org
Cc: Fenghua Yu 
Cc: Borislav Petkov 
Cc: Oleg Nesterov 
Cc: Andy Lutomirski 

---

 b/arch/x86/crypto/camellia_aesni_avx2_glue.c |2 +-
 b/arch/x86/crypto/camellia_aesni_avx_glue.c  |2 +-
 b/arch/x86/crypto/cast5_avx_glue.c   |2 +-
 b/arch/x86/crypto/cast6_avx_glue.c   |2 +-
 b/arch/x86/crypto/serpent_avx2_glue.c|2 +-
 b/arch/x86/crypto/serpent_avx_glue.c |2 +-
 b/arch/x86/crypto/sha1_ssse3_glue.c  |2 +-
 b/arch/x86/crypto/sha256_ssse3_glue.c|2 +-
 b/arch/x86/crypto/sha512_ssse3_glue.c|2 +-
 b/arch/x86/crypto/twofish_avx_glue.c |2 +-
 b/arch/x86/include/asm/xcr.h |6 +-
 b/arch/x86/kernel/xsave.c|2 +-
 b/arch/x86/kvm/x86.c |   16 
 b/arch/x86/power/cpu.c   |2 +-
 14 files changed, 25 insertions(+), 21 deletions(-)

diff -puN arch/x86/kvm/x86.c~x86-fpu-rename-xcr0-macro arch/x86/kvm/x86.c
--- a/arch/x86/kvm/x86.c~x86-fpu-rename-xcr0-macro  2015-04-24 
15:55:10.454089347 -0700
+++ b/arch/x86/kvm/x86.c2015-04-24 15:59:42.193345311 -0700
@@ -634,7 +634,7 @@ static void kvm_load_guest_xcr0(struct k
if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE) &&
!vcpu->guest_xcr0_loaded) {
/* kvm_set_xcr() also depends on this */
-   xsetbv(XCR_XFEATURE_ENABLED_MASK, vcpu->arch.xcr0);
+   xsetbv(XCR0, vcpu->arch.xcr0);
vcpu->guest_xcr0_loaded = 1;
}
 }
@@ -643,7 +643,7 @@ static void kvm_put_guest_xcr0(struct kv
 {
if (vcpu->guest_xcr0_loaded) {
if (vcpu->arch.xcr0 != host_xcr0)
-   xsetbv(XCR_XFEATURE_ENABLED_MASK, host_xcr0);
+   xsetbv(XCR0, host_xcr0);
vcpu->guest_xcr0_loaded = 0;
}
 }
@@ -654,8 +654,8 @@ static int __kvm_set_xcr(struct kvm_vcpu
u64 old_xcr0 = vcpu->arch.xcr0;
u64 valid_bits;
 
-   /* Only support XCR_XFEATURE_ENABLED_MASK(xcr0) now  */
-   if (index != XCR_XFEATURE_ENABLED_MASK)
+   /* Only support XCR0 now  */
+   if (index != XCR0)
return 1;
if (!(xcr0 & XSTATE_FP))
return 1;
@@ -3295,7 +3295,7 @@ static void kvm_vcpu_ioctl_x86_get_xcrs(
 
guest_xcrs->nr_xcrs = 1;
guest_xcrs->flags = 0;
-   guest_xcrs->xcrs[0].xcr = XCR_XFEATURE_ENABLED_MASK;
+   guest_xcrs->xcrs[0].xcr = XCR0;
guest_xcrs->xcrs[0].value = vcpu->arch.xcr0;
 }
 
@@ -3312,8 +3312,8 @@ static int kvm_vcpu_ioctl_x86_set_xcrs(s
 
for (i = 0; i < guest_xcrs->nr_xcrs; i++)
/* Only support XCR0 currently */
-   if (guest_xcrs->xcrs[i].xcr == XCR_XFEATURE_ENABLED_MASK) {
-   r = __kvm_set_xcr(vcpu, XCR_XFEATURE_ENABLED_MASK,
+   if (guest_xcrs->xcrs[i].xcr == XCR0) {
+   r = __kvm_set_xcr(vcpu, XCR0,
guest_xcrs->xcrs[i].value);
break;
}
@@ -5809,7 +5809,7 @@ int kvm_arch_init(void *opaque)
perf_register_guest_info_callbacks(_guest_cbs);
 
if (cpu_has_xsave)
-   host_xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK);
+   host_xcr0 = xgetbv(XCR0);
 
kvm_lapic_init();
 #ifdef CONFIG_X86_64
diff -puN arch/x86/include/asm/xcr.h~x86-fpu-rename-xcr0-macro 
arch/x86/include/asm/xcr.h
--- a/arch/x86/include/asm/xcr.h~x86-fpu-rename-xcr0-macro  2015-04-24 
15:55:10.456089437 -0700
+++ b/arch/x86/include/asm/xcr.h2015-04-24 15:55:10.483090655 -0700
@@ -17,13 +17,17 @@
 #ifndef _ASM_X86_XCR_H
 #define _ASM_X86_XCR_H
 
-#define XCR_XFEATURE_ENABLED_MASK  0x
+#define XCR0   0x
 
 #ifdef __KERNEL__
 # ifndef __ASSEMBLY__
 
 #include 
 
+/*
+ * Reads the contents of the extended control register (XCR)
+ * specified in the ECX register into registers EDX:EAX.
+ */
 static inline u64 xgetbv(u32 index)
 {
u32 eax, edx;
diff -puN arch/x86/crypto/camellia_aesni_avx2_glue.c~x86-fpu-rename-xcr0-macro 
arch/x86/crypto/camellia_aesni_avx2_glue.c
--- a/arch/x86/crypto/camellia_aesni_avx2_glue.c~x86-fpu-rename-xcr0-macro  
2015-04-24 15:55:10.458089527 -0700
+++ b/arch/x86/crypto/camellia_aesni_avx2_glue.c2015-04-24 
15:55:10.484090700 -0700
@@ -568,7 +568,7 @@ 

Re: [PATCH net-next,v2,1/1] hv_netvsc: introduce netif-msg into netvsc module

[Joe Perches]

On Fri, 2015-04-24 at 22:52 +, Simon Xiao wrote:
> > From: Joe Perches [mailto:j...@perches.com]
> > On Fri, 2015-04-24 at 11:34 -0700, six...@microsoft.com wrote:
> > > From: Simon Xiao 
> > >
> > > 1. Introduce netif-msg to netvsc to control debug logging output and
> > > keep msg_enable in netvsc_device_context so that it is kept
> > > persistently.
[]
> > > diff --git a/drivers/net/hyperv/netvsc_drv.c
[]
> > > + if (netif_msg_probe(net_device_ctx))
> > > + netdev_dbg(net, "netvsc msg_enable: %d",
> > > +net_device_ctx->msg_enable);
> > 
> > Please use newlines to terminate formats.
> > 
> > It helps prevent log content interleaving when multiple processes are
> > emitting output at the same time.
> > 
> > This could be shortened to use netif_ like:
> > 
> > netif_dbg(net_device_ctx, probe, net, "netvsc_msg_enable: %d\n",
> >   net_device_ctx->msg_enable);
> > 
> 
> Thanks Joe. I would like to leave this to my next patch as there are some 
> places else in netvsc (rndis_filter.c) 
> have the same usage. I would like to fix them in one patch to make them 
> consistent.

Oh sure no worries.

It is nicer though to not introduce new formats
with missing newline defects.

cheers, Joe


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

[git pull] Please pull mpe/linux.git powerpc-4.1-2 tag

[Michael Ellerman]

Hi Linus,

Please pull powerpc fixes for 4.1:

The following changes since commit d19d5efd8c8840aa4f38a6dfbfe500d8cc27de46:

  Merge tag 'powerpc-4.1-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux (2015-04-16 13:53:32 
-0500)

are available in the git repository at:

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

for you to fetch changes up to 2e826695d87c2d213def07bc344ae97d88384f62:

  powerpc/mm: Fix build error with CONFIG_PPC_TRANSACTIONAL_MEM disabled 
(2015-04-23 17:42:14 +1000)


powerpc fixes for 4.1

- Fix for mm_dec_nr_pmds() from Scott.
- Fixes for oopses seen with KVM + THP from Aneesh.
- Build fixes from Aneesh & Shreyas.


Aneesh Kumar K.V (5):
  KVM: PPC: Use READ_ONCE when dereferencing pte_t pointer
  KVM: PPC: Remove page table walk helpers
  powerpc/mm/thp: Make page table walk safe against thp split/collapse
  powerpc/mm/thp: Return pte address if we find trans_splitting.
  powerpc/mm: Fix build error with CONFIG_PPC_TRANSACTIONAL_MEM disabled

Michael Ellerman (1):
  Merge branch 'master' of git://git.kernel.org/.../scottwood/linux into 
fixes

Scott Wood (1):
  powerpc/hugetlb: Call mm_dec_nr_pmds() in hugetlb_free_pmd_range()

Shreyas B. Prabhu (1):
  powerpc/kvm: Fix ppc64_defconfig + PPC_POWERNV=n build error

 arch/powerpc/include/asm/kvm_book3s_64.h | 17 +++
 arch/powerpc/include/asm/pgtable.h   | 28 +++
 arch/powerpc/kernel/eeh.c|  6 ++-
 arch/powerpc/kernel/io-workarounds.c | 10 ++--
 arch/powerpc/kvm/Kconfig |  2 +-
 arch/powerpc/kvm/book3s_64_mmu_hv.c  | 14 +++---
 arch/powerpc/kvm/book3s_hv_rm_mmu.c  | 86 +---
 arch/powerpc/kvm/e500_mmu_host.c | 32 
 arch/powerpc/mm/hash_utils_64.c  |  3 +-
 arch/powerpc/mm/hugetlbpage.c| 32 
 arch/powerpc/perf/callchain.c| 24 +
 11 files changed, 137 insertions(+), 117 deletions(-)




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

Re: [RFC] capabilities: Ambient capabilities

[Andy Lutomirski]

On Apr 24, 2015 2:15 PM, "Serge E. Hallyn"  wrote:
>
> On Fri, Apr 24, 2015 at 01:18:44PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter  wrote:
> > > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> > >
> > >> That's sort of what my patch does -- you need CAP_SETPCAP to switch
> > >> the securebit.
> > >>
> > >> But Christoph's patch required it to add caps to the ambient set, right?
> > >
> > > Yes but you seem to be just adding one additional step without too much of
> > > a benefit because you still need CAP_SETPCAP.
> > >
> >
> > No, because I set the default to on :)
>
> Right - I definately prefer
>
> . default off
> . CAP_SETPCAP required to turn it on (for self and children)
> . once on, anyone can copy bits from (whatever we decided) to pA.
>

Why default off?  If there's some weird reason that switching it on
could cause a security problem, then I'd agree, but I haven't spotted
a reason yet.

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

RE: [PATCH net-next,v2,1/1] hv_netvsc: introduce netif-msg into netvsc module

[Simon Xiao]

> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Friday, April 24, 2015 1:29 PM
> To: Simon Xiao
> Cc: KY Srinivasan; Haiyang Zhang; de...@linuxdriverproject.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next,v2,1/1] hv_netvsc: introduce netif-msg into
> netvsc module
> 
> On Fri, 2015-04-24 at 11:34 -0700, six...@microsoft.com wrote:
> > From: Simon Xiao 
> >
> > 1. Introduce netif-msg to netvsc to control debug logging output and
> > keep msg_enable in netvsc_device_context so that it is kept
> > persistently.
> > 2. Only call dump_rndis_message() when NETIF_MSG_RX_ERR or above is
> > specified in netvsc module debug param.
> > In non-debug mode, in current code, dump_rndis_message() will not
> dump
> > anything but it still initialize some local variables and process the
> > switch logic which is unnecessary, especially in high network
> > throughput situation.
> 
> []
> 
> > diff --git a/drivers/net/hyperv/netvsc_drv.c
> > b/drivers/net/hyperv/netvsc_drv.c
> []
> > @@ -888,6 +891,11 @@ static int netvsc_probe(struct hv_device *dev,
> >
> > net_device_ctx = netdev_priv(net);
> > net_device_ctx->device_ctx = dev;
> > +   net_device_ctx->msg_enable = netif_msg_init(debug, default_msg);
> > +   if (netif_msg_probe(net_device_ctx))
> > +   netdev_dbg(net, "netvsc msg_enable: %d",
> > +  net_device_ctx->msg_enable);
> 
> Please use newlines to terminate formats.
> 
> It helps prevent log content interleaving when multiple processes are
> emitting output at the same time.
> 
> This could be shortened to use netif_ like:
> 
>   netif_dbg(net_device_ctx, probe, net, "netvsc_msg_enable: %d\n",
> net_device_ctx->msg_enable);
> 

Thanks Joe. I would like to leave this to my next patch as there are some 
places else in netvsc (rndis_filter.c) 
have the same usage. I would like to fix them in one patch to make them 
consistent.

Thanks,
Simon 


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

Re: [PATCH 2/2] Input - synaptics: pin 3 touches when the firmware reports 3 fingers

[Benjamin Tissoires]

Hi Dmitry,

[ adding more relevant people to the discussion ]

On Apr 23 2015 or thereabouts, Benjamin Tissoires wrote:
> On Apr 23 2015 or thereabouts, Dmitry Torokhov wrote:
> > On Wed, Apr 22, 2015 at 11:45:09AM -0400, Benjamin Tissoires wrote:
> > > Synaptics PS/2 touchpad can send only 2 touches in a report. They can
> > > detect 4 or 5 and this information is valuable.
> > > 
> > > In commit 63c4fda3c0bb ("Input: synaptics - allocate 3 slots to keep
> > > stability in image sensors"), we allocate 3 slots, but we still continue
> > > to report the 2 available fingers. That means that the client sees 2 used
> > > slots while there is a total of 3 fingers advertised by 
> > > BTN_TOOL_TRIPLETAP.
> > > 
> > > For old kernels this is not a problem because max_slots was 2 and 
> > > libinput/
> > > xorg-synaptics knew how to deal with that. Now that max_slot is 3, the
> > > clients ignore BTN_TOOL_TRIPLETAP and count the actual used slots (so 2).
> > > It then gets confused when receiving the BTN_TOOL_TRIPLETAP and DOUBLETAP
> > > information, and goes wild.
> > > 
> > > We can pin the 3 slots until we get a total number of fingers below 2.
> > > 
> > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1212230
> > 
> > Benjamin, I do not quite like it. It seems that original patch was not
> > quite right and we are adding more workarounds.
> 
> Agree. And I am starting to hate more and more the synaptics PS/2 and all
> the PS/2 drivers to be honest :) - trying to fit a heavy load data like
> multitouch in a simple and lightweight protocol like PS/2 is insane...
> 
> We are internally trying to figure out if we can finally take advantage
> of the SMBus/RMI4 protocol, but we tried for one year without much
> success.
> 
> > 
> > Synaptics can only track 2 contacts, correct? Why 2 slots to track them
> > is not enough?
> 
> IIRC, the problem was that upon a third finger down, with only 2 slots,
> the fingers were silently inverted in most cases. The thing is that the
> firmware forwards 2 fingers, but not necessarily the two first. So you
> generally get fingers 1+3 so the slot 2 needs to be removed. And that
> means the kernel tracking has to track 3 fingers upon transitions.
> 
> This may be completely bullshit and we might not need to use 3 slots at
> all. I'll need to do further experiments to validate which one is best
> then.
> 
> I am perfectly fine holding this one up for a little bit more testings
> and then we can decide which one needs to be done (revert or an other
> band-aid).
> 

So I carefully recorded each situation (initial with 2 slots, 2 slots
and then with the pinning in this patch*), and I am now convinced that
the pinning is the best sequence that we forward to the user space (best
among the 3).

With 2 slots declared, there are 2 problems:
- the first finger jumps to the position of the 3rd when it lands
- the transition between 2 to 3 fingers goes to a state where the kernel
  removes the second finger (while jumping the first to the position of
  the 3rd finger), send a sync and then reallocate the first finger
  position as the second slot in use

-> that means that user space sees a small transition where the slots
count is 1 while the BTN_TOOL advertise triple tap :/

With 3 slots, we have the problem reported in the rhbz bug  #1212230:
- during the transition, the fingers are stable, but we have at most 2
  active slots in one frame, which confuses libinput/xorg-synaptics.

With the pinning, the user space is no more confused because BTN_TOOL is
always greater or equal than the active slots.

So I think for now we have 3 possibilities:
1. Just carry this patch, and hope that we will be able to switch the
   synaptics device in the non-PS/2 mode
2. Revert to 2 patches and fix the kernel tracking to accept 3 fingers
   and return the 2 best matches
3. Revert the use of the kernel tracking at all and re-introduce the
   spaghetti code that was here before and hope that all cases where
   properly handled.

IMO that the solution 2. is the best, but I can not do it because I
don't understand what the code does. I can guess things but I can not
accurately change it because it is not readable IMO.

(yes, there is also the solution 4: "screw up and let the user space deal
with it", but I'd rather not do that given the history of the multitouch
protocol)


Cheers,
Benjamin


* I tried to put side by side the 3 test cases in the following logs:


(init slots 2, no pinning)| (init slots 3, no pinning)| (init slots 3, 
pinning)
- | - | 
---
--|-  one finger down  
---|
  |   |
ABS_MT_SLOT  0| ABS_MT_SLOT  0| ABS_MT_SLOT 
 0
ABS_MT_TRACKING_ID   53   | ABS_MT_TRACKING_ID   53   | 
ABS_MT_TRACKING_ID   53
ABS_MT_POSITION_X2000 | 

[PATCH] bio: switch to iov_iter_{npages,alignment}

[Ming Lin]

Signed-off-by: Ming Lin 
---
 block/bio.c | 45 +++--
 1 file changed, 7 insertions(+), 38 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 05c2864..c3a6468 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1158,29 +1158,14 @@ struct bio *bio_copy_user_iov(struct request_queue *q,
struct bio_map_data *bmd;
struct page *page;
struct bio *bio;
-   int i, ret;
+   int uninitialized_var(i), ret;
int nr_pages = 0;
unsigned int len = iter->count;
unsigned int offset = map_data ? map_data->offset & ~PAGE_MASK : 0;
 
-   for (i = 0; i < iter->nr_segs; i++) {
-   unsigned long uaddr;
-   unsigned long end;
-   unsigned long start;
-
-   uaddr = (unsigned long) iter->iov[i].iov_base;
-   end = (uaddr + iter->iov[i].iov_len + PAGE_SIZE - 1)
-   >> PAGE_SHIFT;
-   start = uaddr >> PAGE_SHIFT;
-
-   /*
-* Overflow, abort
-*/
-   if (end < start)
-   return ERR_PTR(-EINVAL);
-
-   nr_pages += end - start;
-   }
+   nr_pages = iov_iter_npages(iter, INT_MAX);
+   if (!nr_pages)
+   return ERR_PTR(-EINVAL);
 
if (offset)
nr_pages++;
@@ -1292,26 +1277,10 @@ struct bio *bio_map_user_iov(struct request_queue *q,
struct iov_iter i;
struct iovec iov;
 
-   iov_for_each(iov, i, *iter) {
-   unsigned long uaddr = (unsigned long) iov.iov_base;
-   unsigned long len = iov.iov_len;
-   unsigned long end = (uaddr + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
-   unsigned long start = uaddr >> PAGE_SHIFT;
-
-   /*
-* Overflow, abort
-*/
-   if (end < start)
-   return ERR_PTR(-EINVAL);
-
-   nr_pages += end - start;
-   /*
-* buffer must be aligned to at least hardsector size for now
-*/
-   if (uaddr & queue_dma_alignment(q))
-   return ERR_PTR(-EINVAL);
-   }
+   if (iov_iter_alignment(iter) & queue_dma_alignment(q))
+   return ERR_PTR(-EINVAL);
 
+   nr_pages = iov_iter_npages(iter, INT_MAX);
if (!nr_pages)
return ERR_PTR(-EINVAL);
 
-- 
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 V2 2/4] ASoC: tas571x: Add DT binding document

[Kevin Cernekee]

Document the bindings for the soon-to-be-added tas571x driver.

Signed-off-by: Kevin Cernekee 
---
 .../devicetree/bindings/sound/tas571x.txt  | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/tas571x.txt

diff --git a/Documentation/devicetree/bindings/sound/tas571x.txt 
b/Documentation/devicetree/bindings/sound/tas571x.txt
new file mode 100644
index ..0ac31d8d5ac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas571x.txt
@@ -0,0 +1,41 @@
+Texas Instruments TAS5711/TAS5717/TAS5719 stereo power amplifiers
+
+The codec is controlled through an I2C interface.  It also has two other
+signals that can be wired up to GPIOs: reset (strongly recommended), and
+powerdown (optional).
+
+Required properties:
+
+- compatible: "ti,tas5711", "ti,tas5717", or "ti,tas5719"
+- reg: The I2C address of the device
+- #sound-dai-cells: must be equal to 0
+
+Optional properties:
+
+- reset-gpios: GPIO specifier for the TAS571x's active low reset line
+- pdn-gpios: GPIO specifier for the TAS571x's active low powerdown line
+- clocks: clock phandle for the MCLK input
+- clock-names: should be "mclk"
+- AVDD-supply: regulator phandle for the AVDD supply (all chips)
+- DVDD-supply: regulator phandle for the DVDD supply (all chips)
+- HPVDD-supply: regulator phandle for the HPVDD supply (5717/5719)
+- PVDD_AB-supply: regulator phandle for the PVDD_AB supply (5717/5719)
+- PVDD_CD-supply: regulator phandle for the PVDD_CD supply (5717/5719)
+- PVDD_A-supply: regulator phandle for the PVDD_A supply (5711)
+- PVDD_B-supply: regulator phandle for the PVDD_B supply (5711)
+- PVDD_C-supply: regulator phandle for the PVDD_C supply (5711)
+- PVDD_D-supply: regulator phandle for the PVDD_D supply (5711)
+
+Example:
+
+   tas5717: audio-codec@2a {
+   compatible = "ti,tas5717";
+   reg = <0x2a>;
+   #sound-dai-cells = <0>;
+
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+   pdn-gpios = < 2 GPIO_ACTIVE_LOW>;
+
+   clocks = <_core CLK_I2S>;
+   clock-names = "mclk";
+   };
-- 
2.2.0.rc0.207.ga3a616c

--
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 4/4] MAINTAINERS: Add entry for tas571x ASoC codec driver

[Kevin Cernekee]

Add self as maintainer for the new driver.

Signed-off-by: Kevin Cernekee 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ea0001760035..15153fc37cc4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9878,6 +9878,12 @@ L:   net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/ti/netcp*
 
+TI TAS571X FAMILY ASoC CODEC DRIVER
+M: Kevin Cernekee 
+L: alsa-de...@alsa-project.org (moderated for non-subscribers)
+S: Odd Fixes
+F: sound/soc/codecs/tas571x*
+
 TI TWL4030 SERIES SOC CODEC DRIVER
 M: Peter Ujfalusi 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
-- 
2.2.0.rc0.207.ga3a616c

--
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] crypto: api: Do not access module name directly from module structure

[Herbert Xu]

On Fri, Apr 24, 2015 at 08:58:03AM -0700, Guenter Roeck wrote:
> 'struct module' is only fully declared if CONFIG_MODULES is configured.
> If not, the build fails with
> 
> crypto/algapi.c: In function 'crypto_check_module_sig':
> crypto/algapi.c:49:12: error: dereferencing pointer to incomplete type
> 
> Fixes: 59afdc7b3214 ("crypto: api - Move module sig ifdef into accessor
>   function")
> Cc: Herbert Xu 
> Cc: Rusty Russell 
> Signed-off-by: Guenter Roeck 
> ---
> Seen in next-20150424.

Thanks but a similar patch has already been queued.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync_region()

[Kevin Cernekee]

regcache_sync() and regcache_sync_region() currently assume that the
hardware has just emerged from a clean reset, and that all registers are
in their default states.  But that isn't the only possibility; the device
may have been in a different state in which the registers were
inaccessible but have retained their contents, e.g. clock gating.

So we will extend the more versatile of the two functions,
regcache_sync_region(), to let the caller decide what assumptions should
be made.

One driver that can benefit from this is adau1977, which has hacks to
overwrite the registers that regcache_sync() might have missed.  Also,
the powerdown pin on tas571x does not reset the register contents either,
so a similar feature will be required by that driver.

This commit just adds the new argument by changing the function
declarations and call sites, but doesn't wire it up yet.

Signed-off-by: Kevin Cernekee 
---
 drivers/base/regmap/internal.h|  5 ++-
 drivers/base/regmap/regcache-lzo.c|  2 +-
 drivers/base/regmap/regcache-rbtree.c |  5 ++-
 drivers/base/regmap/regcache.c| 75 ---
 drivers/media/radio/radio-si476x.c| 18 ++---
 drivers/mfd/wm8994-core.c |  5 ++-
 include/linux/regmap.h|  4 +-
 include/sound/hda_regmap.h|  3 +-
 sound/soc/codecs/wm8962.c |  3 +-
 9 files changed, 72 insertions(+), 48 deletions(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index a13587b5c2be..89dfefeb168e 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -155,7 +155,8 @@ struct regcache_ops {
 #endif
int (*read)(struct regmap *map, unsigned int reg, unsigned int *value);
int (*write)(struct regmap *map, unsigned int reg, unsigned int value);
-   int (*sync)(struct regmap *map, unsigned int min, unsigned int max);
+   int (*sync)(struct regmap *map, unsigned int min, unsigned int max,
+   bool was_reset);
int (*drop)(struct regmap *map, unsigned int min, unsigned int max);
 };
 
@@ -215,7 +216,7 @@ int regcache_sync(struct regmap *map);
 int regcache_sync_block(struct regmap *map, void *block,
unsigned long *cache_present,
unsigned int block_base, unsigned int start,
-   unsigned int end);
+   unsigned int end, bool was_reset);
 
 static inline const void *regcache_get_val_addr(struct regmap *map,
const void *base,
diff --git a/drivers/base/regmap/regcache-lzo.c 
b/drivers/base/regmap/regcache-lzo.c
index 2d53f6f138e1..52ed0d03ce69 100644
--- a/drivers/base/regmap/regcache-lzo.c
+++ b/drivers/base/regmap/regcache-lzo.c
@@ -332,7 +332,7 @@ out:
 }
 
 static int regcache_lzo_sync(struct regmap *map, unsigned int min,
-unsigned int max)
+unsigned int max, bool was_reset)
 {
struct regcache_lzo_ctx **lzo_blocks;
unsigned int val;
diff --git a/drivers/base/regmap/regcache-rbtree.c 
b/drivers/base/regmap/regcache-rbtree.c
index 81751a49d8bf..8fc1727e635c 100644
--- a/drivers/base/regmap/regcache-rbtree.c
+++ b/drivers/base/regmap/regcache-rbtree.c
@@ -445,7 +445,7 @@ static int regcache_rbtree_write(struct regmap *map, 
unsigned int reg,
 }
 
 static int regcache_rbtree_sync(struct regmap *map, unsigned int min,
-   unsigned int max)
+   unsigned int max, bool was_reset)
 {
struct regcache_rbtree_ctx *rbtree_ctx;
struct rb_node *node;
@@ -477,7 +477,8 @@ static int regcache_rbtree_sync(struct regmap *map, 
unsigned int min,
 
ret = regcache_sync_block(map, rbnode->block,
  rbnode->cache_present,
- rbnode->base_reg, start, end);
+ rbnode->base_reg, start, end,
+ was_reset);
if (ret != 0)
return ret;
}
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index 7eb7b3b98794..d27b45f50497 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -250,7 +250,7 @@ int regcache_write(struct regmap *map,
 }
 
 static int regcache_default_sync(struct regmap *map, unsigned int min,
-unsigned int max)
+unsigned int max, bool was_reset)
 {
unsigned int reg;
 
@@ -266,10 +266,12 @@ static int regcache_default_sync(struct regmap *map, 
unsigned int min,
if (ret)
return ret;
 
-   /* Is this the hardware default?  If so skip. */
-   ret = regcache_lookup_reg(map, reg);
-   if (ret >= 0 && val == map->reg_defaults[ret].def)
-  

[PATCH V2 3/4] ASoC: tas571x: New driver for TI TAS571x power amplifiers

[Kevin Cernekee]

Introduce a new codec driver for the Texas Instruments
TAS5711/TAS5717/TAS5719 power amplifier chips.  These chips are typically
used to take an I2S digital audio input and drive 10-20W into a pair of
speakers.

Signed-off-by: Kevin Cernekee 
---
 sound/soc/codecs/Kconfig   |   5 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/tas571x.c | 521 +
 sound/soc/codecs/tas571x.h |  33 +++
 4 files changed, 561 insertions(+)
 create mode 100644 sound/soc/codecs/tas571x.c
 create mode 100644 sound/soc/codecs/tas571x.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 061c46587628..befff910d71a 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -104,6 +104,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
select SND_SOC_TAS2552 if I2C
select SND_SOC_TAS5086 if I2C
+   select SND_SOC_TAS571X if I2C
select SND_SOC_TFA9879 if I2C
select SND_SOC_TLV320AIC23_I2C if I2C
select SND_SOC_TLV320AIC23_SPI if SPI_MASTER
@@ -611,6 +612,10 @@ config SND_SOC_TAS5086
tristate "Texas Instruments TAS5086 speaker amplifier"
depends on I2C
 
+config SND_SOC_TAS571X
+   tristate "Texas Instruments TAS5711/TAS5717/TAS5719 power amplifiers"
+   depends on I2C
+
 config SND_SOC_TFA9879
tristate "NXP Semiconductors TFA9879 amplifier"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index abe2d7edf65c..3dcf5ac85e89 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -106,6 +106,7 @@ snd-soc-sta350-objs := sta350.o
 snd-soc-sta529-objs := sta529.o
 snd-soc-stac9766-objs := stac9766.o
 snd-soc-tas5086-objs := tas5086.o
+snd-soc-tas571x-objs := tas571x.o
 snd-soc-tfa9879-objs := tfa9879.o
 snd-soc-tlv320aic23-objs := tlv320aic23.o
 snd-soc-tlv320aic23-i2c-objs := tlv320aic23-i2c.o
@@ -288,6 +289,7 @@ obj-$(CONFIG_SND_SOC_STA529)   += snd-soc-sta529.o
 obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o
 obj-$(CONFIG_SND_SOC_TAS2552)  += snd-soc-tas2552.o
 obj-$(CONFIG_SND_SOC_TAS5086)  += snd-soc-tas5086.o
+obj-$(CONFIG_SND_SOC_TAS571X)  += snd-soc-tas571x.o
 obj-$(CONFIG_SND_SOC_TFA9879)  += snd-soc-tfa9879.o
 obj-$(CONFIG_SND_SOC_TLV320AIC23)  += snd-soc-tlv320aic23.o
 obj-$(CONFIG_SND_SOC_TLV320AIC23_I2C)  += snd-soc-tlv320aic23-i2c.o
diff --git a/sound/soc/codecs/tas571x.c b/sound/soc/codecs/tas571x.c
new file mode 100644
index ..08e358638f2e
--- /dev/null
+++ b/sound/soc/codecs/tas571x.c
@@ -0,0 +1,521 @@
+/*
+ * TAS571x amplifier audio driver
+ *
+ * Copyright (C) 2015 Google, Inc.
+ * Copyright (c) 2013 Daniel Mack 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tas571x.h"
+
+#define TAS571X_MAX_SUPPLIES   6
+
+struct tas571x_chip {
+   const char  *const *supply_names;
+   int num_supply_names;
+   const struct snd_kcontrol_new   *controls;
+   int num_controls;
+   const struct regmap_config  *regmap_config;
+   int vol_reg_size;
+};
+
+struct tas571x_private {
+   const struct tas571x_chip   *chip;
+   struct regmap   *regmap;
+   struct regulator_bulk_data  supplies[TAS571X_MAX_SUPPLIES];
+   struct clk  *mclk;
+   unsigned intformat;
+   struct gpio_desc*reset_gpio;
+   struct gpio_desc*pdn_gpio;
+   struct snd_soc_codec_driver codec_driver;
+};
+
+static int tas571x_register_size(struct tas571x_private *priv, unsigned int 
reg)
+{
+   switch (reg) {
+   case TAS571X_MVOL_REG:
+   case TAS571X_CH1_VOL_REG:
+   case TAS571X_CH2_VOL_REG:
+   return priv->chip->vol_reg_size;
+   default:
+   return 1;
+   }
+}
+
+static int tas571x_reg_write(void *context, unsigned int reg,
+unsigned int value)
+{
+   struct i2c_client *client = context;
+   struct tas571x_private *priv = i2c_get_clientdata(client);
+   unsigned int i, size;
+   uint8_t buf[5];
+   int ret;
+
+   size = tas571x_register_size(priv, reg);
+   buf[0] = reg;
+
+   for (i = size; i >= 1; --i) {
+   buf[i] = value;
+   value >>= 8;
+   }
+
+   ret = i2c_master_send(client, buf, size + 1);
+   if (ret == size + 1)
+   return 0;
+   else if (ret < 0)
+   return ret;
+ 

[PATCH V2 0/4] tas571x amplifier driver

[Kevin Cernekee]

V1->V2:

 - Incorporate changes from review feedback

 - Change GPIOs to active low

 - Create a tas571x_chip struct to capture the growing list of differences
   between 5711 and 5717/5719

 - Add register defaults for each chip

 - Extend regcache_sync_region() to allow it to sync with hardware registers
   that don't contain their power-on-reset values


Kevin Cernekee (4):
  regmap: cache: Add "was_reset" argument to regcache_sync_region()
  ASoC: tas571x: Add DT binding document
  ASoC: tas571x: New driver for TI TAS571x power amplifiers
  MAINTAINERS: Add entry for tas571x ASoC codec driver

 .../devicetree/bindings/sound/tas571x.txt  |  41 ++
 MAINTAINERS|   6 +
 drivers/base/regmap/internal.h |   5 +-
 drivers/base/regmap/regcache-lzo.c |   2 +-
 drivers/base/regmap/regcache-rbtree.c  |   5 +-
 drivers/base/regmap/regcache.c |  75 +--
 drivers/media/radio/radio-si476x.c |  18 +-
 drivers/mfd/wm8994-core.c  |   5 +-
 include/linux/regmap.h |   4 +-
 include/sound/hda_regmap.h |   3 +-
 sound/soc/codecs/Kconfig   |   5 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/tas571x.c | 521 +
 sound/soc/codecs/tas571x.h |  33 ++
 sound/soc/codecs/wm8962.c  |   3 +-
 15 files changed, 680 insertions(+), 48 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/tas571x.txt
 create mode 100644 sound/soc/codecs/tas571x.c
 create mode 100644 sound/soc/codecs/tas571x.h

-- 
2.2.0.rc0.207.ga3a616c

--
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: [Update][PATCH] ACPI / scan: Add a scan handler for PRP0001

[Darren Hart]

On Fri, Apr 24, 2015 at 02:15:22AM +0200, Rafael Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> If the special PRP0001 device ID is present in the given device's list
> of ACPI/PNP IDs and the device has a valid "compatible" property in
> the _DSD, it should be enumerated using the default mechanism,
> unless some scan handlers match the IDs preceding PRP0001 in the
> device's list of ACPI/PNP IDs.  In addition to that, no scan handlers
> matching the IDs following PRP0001 in that list should be attached
> to the device.
> 
> To make that happen, define a scan handler that will match PRP0001
> and trigger the default enumeration for the matching devices if the
> "compatible" property is present for them.
> 
> Since that requires the check for platform_id and device->handler
> to be removed from acpi_default_enumeration(), move the fallback
> invocation of acpi_default_enumeration() to acpi_bus_attach()
> (after it's checked if there's a matching ACPI driver for the
> device), which is a better place to call it, and do the platform_id
> check in there too (device->handler is guaranteed to be unset at
> the point where the function is looking for a matching ACPI driver).
> 
> Signed-off-by: Rafael J. Wysocki 
> Acked-by: Darren Hart 
> ---
> 
> The change from the original patch is to change the scan handler
> behavior to make it return 1 also if the "compatible" property is
> not present, in which case the additional scan handlers should not
> trigger too *and* the default enumeration should not trigger either
> (as there's no ID to match to), which will allow things like
> auxiliary nodes (think GPIO buttons/LEDs etc) to be easily represented.


This should probably be spelled out in the commit message itself as it's a 
fairly
unique condition.


> Darren, I've tentatively added your Acked-by tag to this one, please
> let me know if that's not appropriate.

Spent a bit more time on it this time, so:

Reviewed-by: Darren Hart 

Thanks,

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

[PATCH RESEND V4 1/4] i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform

[Feng Kan]

Add SLIMpro I2C device driver on APM X-Gene platform. This I2C
device driver use the SLIMpro Mailbox driver to tunnel message to
the SLIMpro coprocessor to do the work of accessing I2C components.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 459 +
 3 files changed, 469 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..1ac07d0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1082,6 +1082,15 @@ config I2C_CROS_EC_TUNNEL
  connected there. This will work whatever the interface used to
  talk to the EC (SPI, I2C or LPC).
 
+config I2C_XGENE_SLIMPRO
+   tristate "APM X-Gene SoC I2C SLIMpro devices support"
+   depends on ARCH_XGENE && MAILBOX
+   help
+ Enable I2C bus access using the APM X-Gene SoC SLIMpro
+ co-processor. The I2C device access the I2C bus via the X-Gene
+ to SLIMpro (On chip coprocessor) mailbox mechanism.
+ If unsure, say N.
+
 config SCx200_ACB
tristate "Geode ACCESS.bus support"
depends on X86_32 && PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3638feb..9cf9c4b 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_I2C_ELEKTOR)   += i2c-elektor.o
 obj-$(CONFIG_I2C_OPAL) += i2c-opal.o
 obj-$(CONFIG_I2C_PCA_ISA)  += i2c-pca-isa.o
 obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
+obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
 obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
new file mode 100644
index 000..f994b8a0
--- /dev/null
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -0,0 +1,459 @@
+/*
+ * X-Gene SLIMpro I2C Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ * Author: Hieu Le 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ * This driver provides support for X-Gene SLIMpro I2C device access
+ * using the APM X-Gene SLIMpro mailbox driver.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAILBOX_OP_TIMEOUT 1000/* Operation time out in ms */
+#define MAILBOX_I2C_INDEX  0
+#define SLIMPRO_IIC_BUS1   /* Use I2C bus 1 only */
+
+#define SMBUS_CMD_LEN  1
+#define BYTE_DATA  1
+#define WORD_DATA  2
+#define BLOCK_DATA 3
+
+#define SLIMPRO_IIC_I2C_PROTOCOL   0
+#define SLIMPRO_IIC_SMB_PROTOCOL   1
+
+#define SLIMPRO_IIC_READ   0
+#define SLIMPRO_IIC_WRITE  1
+
+#define IIC_SMB_WITHOUT_DATA_LEN   0
+#define IIC_SMB_WITH_DATA_LEN  1
+
+#define SLIMPRO_DEBUG_MSG  0
+#define SLIMPRO_MSG_TYPE_SHIFT 28
+#define SLIMPRO_DBG_SUBTYPE_I2C1READ   4
+#define SLIMPRO_DBGMSG_TYPE_SHIFT  24
+#define SLIMPRO_DBGMSG_TYPE_MASK   0x0F00U
+#define SLIMPRO_IIC_DEV_SHIFT  23
+#define SLIMPRO_IIC_DEV_MASK   0x0080U
+#define SLIMPRO_IIC_DEVID_SHIFT13
+#define SLIMPRO_IIC_DEVID_MASK 0x007FE000U
+#define SLIMPRO_IIC_RW_SHIFT   12
+#define SLIMPRO_IIC_RW_MASK0x1000U
+#define SLIMPRO_IIC_PROTO_SHIFT11
+#define SLIMPRO_IIC_PROTO_MASK 0x0800U
+#define SLIMPRO_IIC_ADDRLEN_SHIFT  8
+#define SLIMPRO_IIC_ADDRLEN_MASK   0x0700U
+#define SLIMPRO_IIC_DATALEN_SHIFT  0
+#define SLIMPRO_IIC_DATALEN_MASK   0x00FFU
+
+/*
+ * SLIMpro I2C message encode
+ *
+ * dev - Controller number (0-based)
+ * chip- I2C chip address
+ * op  - SLIMPRO_IIC_READ or SLIMPRO_IIC_WRITE
+ * proto   - SLIMPRO_IIC_SMB_PROTOCOL or SLIMPRO_IIC_I2C_PROTOCOL
+ * addrlen - Length of the address field
+ * datalen - Length of the data field
+ */
+#define SLIMPRO_IIC_ENCODE_MSG(dev, chip, op, proto, addrlen, datalen) \
+   ((SLIMPRO_DEBUG_MSG << 

[PATCH RESEND V4 3/4] Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver documentation

[Feng Kan]

Add APM X-Gene platform SLIMpro I2C driver documentation.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt 
b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
new file mode 100644
index 000..f6b2c20
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
@@ -0,0 +1,15 @@
+APM X-Gene SLIMpro Mailbox I2C Driver
+
+An I2C controller accessed over the "SLIMpro" mailbox.
+
+Required properties :
+
+ - compatible : should be "apm,xgene-slimpro-i2c"
+ - mboxes : use the label reference for the mailbox as the first parameter.
+   The second parameter is the channel number.
+
+Example :
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = < 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/

[PATCH RESEND V4 0/4] i2c: busses: xgene: I2C proxy driver for X-Gene

[Feng Kan]

This is a proxy I2C driver for APM X-Gene SoC. It uses the mailbox driver
to tunnel i2c transactions via the SLIMpro processor.

V4 Change:
- Remove PRP0001 and use a real ACPI id
V3 Change:
- Add ACPI support
- Fix previous comments.

Feng Kan (4):
  i2c: busses: add SLIMpro I2C device driver on APM X-Gene platform
  i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver
  Documentation: i2c: Add APM X-Gene platform SLIMpro I2C driver
documentation
  arm64: dts: add proxy I2C device driver on APM X-Gene platform

 .../devicetree/bindings/i2c/i2c-xgene-slimpro.txt  |  15 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   5 +
 drivers/i2c/busses/Kconfig |   9 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-xgene-slimpro.c | 469 +
 5 files changed, 499 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
 create mode 100644 drivers/i2c/busses/i2c-xgene-slimpro.c

-- 
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 RESEND V4 2/4] i2c: busses: xgene: add acpi support for i2c xgene SLIMpro driver

[Feng Kan]

This adds support for ACPI for the APM X-Gene I2C SLIMpro proxy
driver.

Signed-off-by: Feng Kan 
---
 drivers/i2c/busses/i2c-xgene-slimpro.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c 
b/drivers/i2c/busses/i2c-xgene-slimpro.c
index f994b8a0..0b33aa2e 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -22,6 +22,7 @@
  * using the APM X-Gene SLIMpro mailbox driver.
  *
  */
+#include 
 #include 
 #include 
 #include 
@@ -442,12 +443,21 @@ static const struct of_device_id 
xgene_slimpro_i2c_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, xgene_slimpro_i2c_dt_ids);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_slimpro_i2c_acpi_ids[] = {
+   {"APMC0D40", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, xgene_slimpro_i2c_acpi_ids);
+#endif
+
 static struct platform_driver xgene_slimpro_i2c_driver = {
.probe  = xgene_slimpro_i2c_probe,
.remove = xgene_slimpro_i2c_remove,
.driver = {
.name   = "xgene-slimpro-i2c",
.of_match_table = of_match_ptr(xgene_slimpro_i2c_dt_ids),
+   .acpi_match_table = ACPI_PTR(xgene_slimpro_i2c_acpi_ids)
},
 };
 
-- 
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 RESEND V4 4/4] arm64: dts: add proxy I2C device driver on APM X-Gene platform

[Feng Kan]

Add proxy I2C device driver on APM X-Gene platform.

Signed-off-by: Feng Kan 
Signed-off-by: Hieu Le 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 70c14fa..00ae4d8 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -483,6 +483,11 @@
<0x0 0x7 0x4>;
};
 
+   i2cslimpro {
+   compatible = "apm,xgene-slimpro-i2c";
+   mboxes = < 0>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
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 1/1] scsi: storvsc: Set the SRB flags correctly when no data transfer is needed

[K. Y. Srinivasan]

Set the SRB flags correctly when there is no data transfer.

Cc: 
Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Long Li 
---
 drivers/scsi/storvsc_drv.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index d9dad90..3c6584f 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1600,8 +1600,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *scmnd)
break;
default:
vm_srb->data_in = UNKNOWN_TYPE;
-   vm_srb->win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN |
-SRB_FLAGS_DATA_OUT);
+   vm_srb->win8_extension.srb_flags |= SRB_FLAGS_NO_DATA_TRANSFER;
break;
}
 
-- 
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: net: non contiguous allocations passed to build_skb

[Eric Dumazet]

On Fri, 2015-04-24 at 15:02 -0700, Eric Dumazet wrote:
> On Fri, 2015-04-24 at 17:28 -0400, Sasha Levin wrote:
> > Hey Eric,
> > 
> > Your commit 79930f5892e ("net: do not deplete pfmemalloc reserve") assumes 
> > that
> > build_skb() will only handle contiguous allocations because of the
> > virt_to_head_page().
> > 
> > However, netlink_sendmsg() calls build_skb() with vmalloc()ed memory, 
> > causing:
> 
> gosh. netlink & vmalloc() striked again.

I'll send a fix, thanks for the report.


--
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] x86, selftests: Add a test for the "sysret_ss_attrs" bug

[Andy Lutomirski]

On AMD CPUs, SYSRET can return with a valid SS descriptor with with
the hidden attributes set to an unusable state.  Make sure the kernel
doesn't let this happen.  This detects an as-yet-unfixed regression.

Note that the 64-bit version of this test fails on AMD CPUs on all
kernel versions, although the issue in the 64-bit case is much less
severe than in the 32-bit case.

Tests: e7d6eefaaa44 x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
Reported-by: Brian Gerst 
Signed-off-by: Andy Lutomirski 
---

[resend -- it seems like only some recipients got it last time]

We're still mulling over the fix, but we have a good test case now.

tools/testing/selftests/x86/Makefile  |   5 +-
 tools/testing/selftests/x86/run_x86_tests.sh  |   2 +
 tools/testing/selftests/x86/sysret_ss_attrs.c | 112 ++
 tools/testing/selftests/x86/thunks.S  |  67 +++
 4 files changed, 185 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 tools/testing/selftests/x86/run_x86_tests.sh
 create mode 100644 tools/testing/selftests/x86/sysret_ss_attrs.c
 create mode 100644 tools/testing/selftests/x86/thunks.S

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index ddf63569df5a..9309097f58e8 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -1,6 +1,6 @@
 .PHONY: all all_32 all_64 check_build32 clean run_tests
 
-TARGETS_C_BOTHBITS := sigreturn single_step_syscall
+TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
 
 BINARIES_32 := $(TARGETS_C_BOTHBITS:%=%_32)
 BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64)
@@ -46,3 +46,6 @@ check_build32:
  echo "  yum install glibc-devel.*i686";   \
  exit 1;   \
fi
+
+# Some tests have additional dependencies.
+sysret_ss_attrs_64: thunks.S
diff --git a/tools/testing/selftests/x86/run_x86_tests.sh 
b/tools/testing/selftests/x86/run_x86_tests.sh
old mode 100644
new mode 100755
index 3fc19b376812..d25034280dd5
--- a/tools/testing/selftests/x86/run_x86_tests.sh
+++ b/tools/testing/selftests/x86/run_x86_tests.sh
@@ -4,10 +4,12 @@
 # script here.
 ./sigreturn_32 || exit 1
 ./single_step_syscall_32 || exit 1
+./sysret_ss_attrs_32 || exit 1
 
 if [[ "$uname -p" -eq "x86_64" ]]; then
 ./sigreturn_64 || exit 1
 ./single_step_syscall_64 || exit 1
+./sysret_ss_attrs_64 || exit 1
 fi
 
 exit 0
diff --git a/tools/testing/selftests/x86/sysret_ss_attrs.c 
b/tools/testing/selftests/x86/sysret_ss_attrs.c
new file mode 100644
index ..ce42d5a64009
--- /dev/null
+++ b/tools/testing/selftests/x86/sysret_ss_attrs.c
@@ -0,0 +1,112 @@
+/*
+ * sysret_ss_attrs.c - test that syscalls return valid hidden SS attributes
+ * Copyright (c) 2015 Andrew Lutomirski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * On AMD CPUs, SYSRET can return with a valid SS descriptor with with
+ * the hidden attributes set to an unusable state.  Make sure the kernel
+ * doesn't let this happen.
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void *threadproc(void *ctx)
+{
+   /*
+* Do our best to cause sleeps on this CPU to exit the kernel and
+* re-enter with SS = 0.
+*/
+   while (true)
+   ;
+
+   return NULL;
+}
+
+#ifdef __x86_64__
+extern unsigned long call32_from_64(void *stack, void (*function)(void));
+
+asm (".pushsection .text\n\t"
+ ".code32\n\t"
+ "test_ss:\n\t"
+ "pushl $0\n\t"
+ "popl %eax\n\t"
+ "ret\n\t"
+ ".code64");
+extern void test_ss(void);
+#endif
+
+int main()
+{
+   /*
+* Start a busy-looping thread on the same CPU we're on.
+* For simplicity, just stick everything to CPU 0.  This will
+* fail in some containers, but that's probably okay.
+*/
+   cpu_set_t cpuset;
+   CPU_ZERO();
+   CPU_SET(0, );
+   if (sched_setaffinity(0, sizeof(cpuset), ) != 0)
+   printf("[WARN]\tsched_setaffinity failed\n");
+
+   pthread_t thread;
+   if (pthread_create(, 0, threadproc, 0) != 0)
+   err(1, "pthread_create");
+
+#ifdef __x86_64__
+   unsigned char *stack32 = mmap(NULL, 4096, PROT_READ | PROT_WRITE,
+ MAP_32BIT | MAP_ANONYMOUS | MAP_PRIVATE,
+ -1, 0);
+   if (stack32 == MAP_FAILED)
+   err(1, "mmap");
+#endif
+
+   

Re: [PATCH v2 01/11] stm class: Introduce an abstraction for System Trace Module devices

[Mathieu Poirier]

[...]

> +
> +static int __init stm_core_init(void)
> +{
> +   int err;
> +
> +   err = class_register(_class);
> +   if (err)
> +   return err;
> +
> +   err = class_register(_source_class);
> +   if (err)
> +   goto err_stm;
> +
> +   err = stp_configfs_init();

You can't move "stp_configfs_init()" here and leave "stm_core_init()"
as a "postcore_initcall()".  Function "stp_configfs_init()" calls
"configfs_register_subsystem()" which, after some time, will end up
calling "configfs_new_dirent()".  In there an access to the cache
allocator is done on "configfs_dir_cachep", but it is only initialised
in "configfs_init()" at "module_init()" time, resulting in a -ENOMEM
error.

I don't see how it can be different on x86 but on ARM it is definitely
a problem.

Mathieu

> +   if (err)
> +   goto err_src;
> +
> +   init_srcu_struct(_source_srcu);
> +
> +   stm_core_up++;
> +
> +   return 0;
> +
> +err_src:
> +   class_unregister(_source_class);
> +err_stm:
> +   class_unregister(_class);
> +
> +   return err;
> +}
> +
> +postcore_initcall(stm_core_init);
> +
> +static void __exit stm_core_exit(void)
> +{
> +   class_unregister(_source_class);
> +   class_unregister(_class);
> +   stp_configfs_exit();
> +}
> +
> +module_exit(stm_core_exit);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("System Trace Module device class");
> +MODULE_AUTHOR("Alexander Shishkin ");
> diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
> new file mode 100644
> index 00..b5c59a0e0c
> --- /dev/null
> +++ b/drivers/hwtracing/stm/policy.c
> @@ -0,0 +1,467 @@
> +/*
> + * System Trace Module (STM) master/channel allocation policy management
> + * Copyright (c) 2014, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * A master/channel allocation policy allows mapping string identifiers to
> + * master and channel ranges, where allocation can be done.
> + */
> +
> +#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "stm.h"
> +
> +/*
> + * STP Master/Channel allocation policy configfs layout.
> + */
> +
> +struct stp_policy {
> +   struct config_group group;
> +   struct stm_device   *stm;
> +};
> +
> +struct stp_policy_node {
> +   struct config_group group;
> +   struct stm_device   *stm;
> +   struct stp_policy   *policy;
> +   unsigned intfirst_master;
> +   unsigned intlast_master;
> +   unsigned intfirst_channel;
> +   unsigned intlast_channel;
> +};
> +
> +void stp_policy_node_get_ranges(struct stp_policy_node *policy_node,
> +   unsigned int *mstart, unsigned int *mend,
> +   unsigned int *cstart, unsigned int *cend)
> +{
> +   *mstart = policy_node->first_master;
> +   *mend   = policy_node->last_master;
> +   *cstart = policy_node->first_channel;
> +   *cend   = policy_node->last_channel;
> +}
> +
> +static inline char *stp_policy_node_name(struct stp_policy_node *policy_node)
> +{
> +   return policy_node->group.cg_item.ci_name ? : "";
> +}
> +
> +static inline struct stp_policy *to_stp_policy(struct config_item *item)
> +{
> +   return item ?
> +   container_of(to_config_group(item), struct stp_policy, group) 
> :
> +   NULL;
> +}
> +
> +static inline struct stp_policy_node *
> +to_stp_policy_node(struct config_item *item)
> +{
> +   return item ?
> +   container_of(to_config_group(item), struct stp_policy_node,
> +group) :
> +   NULL;
> +}
> +
> +static ssize_t stp_policy_node_masters_show(struct stp_policy_node 
> *policy_node,
> +   char *page)
> +{
> +   ssize_t count;
> +
> +   count = sprintf(page, "%u %u\n", policy_node->first_master,
> +   policy_node->last_master);
> +
> +   return count;
> +}
> +
> +static ssize_t
> +stp_policy_node_masters_store(struct stp_policy_node *policy_node,
> + const char *page, size_t count)
> +{
> +   struct stm_device *stm = policy_node->stm;
> +   unsigned int first, last;
> +   char *p = (char *) page;
> +
> +   if (sscanf(p, "%u %u", , ) != 2)
> +   return -EINVAL;
> +
> +   /* must be within [sw_start..sw_end], which is an 

Re: net: non contiguous allocations passed to build_skb

[Eric Dumazet]

On Fri, 2015-04-24 at 17:28 -0400, Sasha Levin wrote:
> Hey Eric,
> 
> Your commit 79930f5892e ("net: do not deplete pfmemalloc reserve") assumes 
> that
> build_skb() will only handle contiguous allocations because of the
> virt_to_head_page().
> 
> However, netlink_sendmsg() calls build_skb() with vmalloc()ed memory, causing:

gosh. netlink & vmalloc() striked again.


--
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-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

[Linda Knippers]

On 4/24/2015 5:50 PM, Dan Williams wrote:
> On Fri, Apr 24, 2015 at 2:47 PM, Linda Knippers  wrote:
>> On 4/17/2015 9:35 PM, Dan Williams wrote:
>> :
>>> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
>>> index 5fa74f124b3e..0106b3807202 100644
>>> --- a/drivers/block/nd/Kconfig
>>> +++ b/drivers/block/nd/Kconfig
>>> @@ -41,4 +41,24 @@ config NFIT_ACPI
>>> register the platform-global NFIT blob with the core.  Also
>>> enables the core to craft ACPI._DSM messages for platform/dimm
>>> configuration.
>>> +
>>> +config NFIT_TEST
>>> + tristate "NFIT TEST: Manufactured NFIT for interface testing"
>>> + depends on DMA_CMA
>>> + depends on ND_CORE=m
>>> + depends on m
>>> + help
>>> +   For development purposes register a manufactured
>>> +   NFIT table to verify the resulting device model topology.
>>> +   Note, this module arranges for ioremap_cache() to be
>>> +   overridden locally to allow simulation of system-memory as an
>>> +   io-memory-resource.
>>> +
>>> +   Note, this test expects to be able to find at least
>>> +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to
>>
>> It seems to actually be wanting >= 584MB.
> 
> Ah, true, this Kconfig text is stale.  Will fix.

Thanks.  One more question...

> +#ifdef CONFIG_CMA_SIZE_MBYTES
> +#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
> +#else
> +#define CMA_SIZE_MBYTES 0
> +#endif
> +
> +static __init int nfit_test_init(void)
> +{
> + int rc, i;
> +
> + if (CMA_SIZE_MBYTES < 584) {
> + pr_err("need CONFIG_CMA_SIZE_MBYTES >= 584 to load\n");
> + return -EINVAL;
> + }
> +

Since the kernel takes a cma= boot parameter, it would be nice if
this check is against what the kernel is using rather than the config
option.  Is that possible?

-- ljk
--
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] intel powerclamp: support Knights Landing

[Jacob Pan]

On Fri, 24 Apr 2015 10:33:34 -0700
Dasaratharaman Chandramouli 
wrote:

> Adding Jacob Pan
> 
> On Fri, 2015-04-17 at 15:31 -0700, Dasaratharaman Chandramouli wrote:
> > This patch enables intel_powerclamp driver to run on the
> > next-generation Intel(R) Xeon Phi Microarchitecture
> > code named "Knights Landing"
> > 
looks good.

Acked-by: Jacob Pan 

> > Signed-off-by: Dasaratharaman Chandramouli
> >  ---
> >  drivers/thermal/intel_powerclamp.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/thermal/intel_powerclamp.c
> > b/drivers/thermal/intel_powerclamp.c index 12623bc..e34ccd5 100644
> > --- a/drivers/thermal/intel_powerclamp.c
> > +++ b/drivers/thermal/intel_powerclamp.c
> > @@ -690,6 +690,7 @@ static const struct x86_cpu_id
> > intel_powerclamp_ids[] = { { X86_VENDOR_INTEL, 6, 0x4c},
> > { X86_VENDOR_INTEL, 6, 0x4d},
> > { X86_VENDOR_INTEL, 6, 0x56},
> > +   { X86_VENDOR_INTEL, 6, 0x57},
> > {}
> >  };
> >  MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids);
> 
> 




-- 
Jacob Pan
--
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] livepatch: x86: make kASLR logic more accurate

[Josh Poimboeuf]

On Fri, Apr 24, 2015 at 09:59:03PM +0200, Jiri Kosina wrote:
> We give up old_addr hint from the coming patch module in cases when kernel 
> load
> base has been randomized (as in such case, the coming module has no idea about
> the exact randomization offset).
> 
> We are currently too pessimistic, and give up immediately as soon as 
> CONFIG_RANDOMIZE_BASE is set; this doesn't however directly imply that the 
> load base has actually been randomized. There are config options that 
> disable kASLR (such as hibernation), user could have disabled kaslr on 
> kernel command-line, etc.
> 
> The loader propagates the information whether kernel has been randomized 
> through bootparams. This allows us to have the condition more accurate.
> 
> On top of that, it seems unnecessary to give up old_addr hints even if 
> randomization is active. The relocation offset can be computed as 
> difference between _text start and __START_KERNEL, and therefore old_addr 
> can be adjusted accordingly.
> 
> Signed-off-by: Jiri Kosina 
> ---
> 
> v1 -> v2: I accidentally used kgr_ suffix (which we use in kGraft) instead 
> of klp_ in v1.
> 
>  arch/x86/include/asm/livepatch.h | 4 
>  arch/x86/kernel/livepatch.c  | 5 +
>  kernel/livepatch/core.c  | 5 +++--
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/livepatch.h 
> b/arch/x86/include/asm/livepatch.h
> index 2d29197..84a3247 100644
> --- a/arch/x86/include/asm/livepatch.h
> +++ b/arch/x86/include/asm/livepatch.h
> @@ -23,8 +23,12 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_LIVEPATCH
> +
> +extern unsigned long klp_vmlinux_relocation_offset(void);
> +
>  static inline int klp_check_compiler_support(void)
>  {
>  #ifndef CC_USING_FENTRY
> diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
> index ff3c3101d..6df7902 100644
> --- a/arch/x86/kernel/livepatch.c
> +++ b/arch/x86/kernel/livepatch.c
> @@ -88,3 +88,8 @@ int klp_write_module_reloc(struct module *mod, unsigned 
> long type,
>  
>   return ret;
>  }
> +
> +unsigned long klp_vmlinux_relocation_offset(void)
> +{
> + return (unsigned long)&_text - __START_KERNEL;
> +}
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 284e269..ff4c35c 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -234,8 +234,9 @@ static int klp_find_verify_func_addr(struct klp_object 
> *obj,
>   int ret;
>  
>  #if defined(CONFIG_RANDOMIZE_BASE)
> - /* KASLR is enabled, disregard old_addr from user */
> - func->old_addr = 0;
> + /* If KASLR has been enabled, adjust old_addr accordingly */
> + if (kaslr_enabled())
> + func->old_addr += klp_vmlinux_relocation_offset();
>  #endif

Can we remove the #ifdef now?  It would probably be better to have an
#ifdef in asm/setup.h for the kaslr_enabled() definition.

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

Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

[Dan Williams]

On Fri, Apr 24, 2015 at 2:47 PM, Linda Knippers  wrote:
> On 4/17/2015 9:35 PM, Dan Williams wrote:
> :
>> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
>> index 5fa74f124b3e..0106b3807202 100644
>> --- a/drivers/block/nd/Kconfig
>> +++ b/drivers/block/nd/Kconfig
>> @@ -41,4 +41,24 @@ config NFIT_ACPI
>> register the platform-global NFIT blob with the core.  Also
>> enables the core to craft ACPI._DSM messages for platform/dimm
>> configuration.
>> +
>> +config NFIT_TEST
>> + tristate "NFIT TEST: Manufactured NFIT for interface testing"
>> + depends on DMA_CMA
>> + depends on ND_CORE=m
>> + depends on m
>> + help
>> +   For development purposes register a manufactured
>> +   NFIT table to verify the resulting device model topology.
>> +   Note, this module arranges for ioremap_cache() to be
>> +   overridden locally to allow simulation of system-memory as an
>> +   io-memory-resource.
>> +
>> +   Note, this test expects to be able to find at least
>> +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to
>
> It seems to actually be wanting >= 584MB.

Ah, true, this Kconfig text is stale.  Will fix.
--
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] show isolated cpus in sysfs

[Greg KH]

On Fri, Apr 24, 2015 at 05:22:12PM -0400, Rik van Riel wrote:
> On 04/24/2015 05:11 PM, Frederic Weisbecker wrote:
> > On Fri, Apr 24, 2015 at 03:24:27PM -0400, r...@redhat.com wrote:
> >> From: Rik van Riel 
> >>
> >> After system bootup, there is no totally reliable way to see
> >> which CPUs are isolated, because the kernel may modify the
> >> CPUs specified on the isolcpus= kernel command line option.
> >>
> >> Export the CPU list that actually got isolated in sysfs,
> >> specifically in the file /sys/devices/system/cpu/isolated
> >>
> >> This can be used by system management tools like libvirt,
> >> openstack, and others to ensure proper placement of tasks.
> >>
> >> Suggested-by: Li Zefan 
> >> Signed-off-by: Rik van Riel 
> > 
> > This patch should go through Peterz.
> 
> Oh, fun. That's what I get for getting the get_maintainer.pl
> script, which told me to go through Greg KH instead :)
> 
> $ ./scripts/get_maintainer.pl -f drivers/base/cpu.c
> Greg Kroah-Hartman  (supporter:DRIVER CORE,
> KOBJ...)
> linux-kernel@vger.kernel.org (open list)

That's right, I can take this, I missed this the last time Rik sent
these, that's my fault.

thanks,

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

Re: [Linux-nvdimm] [PATCH 05/21] nfit-test: manufactured NFITs for interface development

[Linda Knippers]

On 4/17/2015 9:35 PM, Dan Williams wrote:
:
> diff --git a/drivers/block/nd/Kconfig b/drivers/block/nd/Kconfig
> index 5fa74f124b3e..0106b3807202 100644
> --- a/drivers/block/nd/Kconfig
> +++ b/drivers/block/nd/Kconfig
> @@ -41,4 +41,24 @@ config NFIT_ACPI
> register the platform-global NFIT blob with the core.  Also
> enables the core to craft ACPI._DSM messages for platform/dimm
> configuration.
> +
> +config NFIT_TEST
> + tristate "NFIT TEST: Manufactured NFIT for interface testing"
> + depends on DMA_CMA
> + depends on ND_CORE=m
> + depends on m
> + help
> +   For development purposes register a manufactured
> +   NFIT table to verify the resulting device model topology.
> +   Note, this module arranges for ioremap_cache() to be
> +   overridden locally to allow simulation of system-memory as an
> +   io-memory-resource.
> +
> +   Note, this test expects to be able to find at least
> +   256MB of CMA space (CONFIG_CMA_SIZE_MBYTES) or it will fail to

It seems to actually be wanting >= 584MB.

-- ljk

> +   load.  Kconfig does not allow for numerical value
> +   dependencies, so we can only warn at runtime.
> +
> +   Say N unless you are doing development of the 'nd' subsystem.
> +
>  endif
--
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_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[H. Peter Anvin]

On 04/24/2015 01:50 PM, Andy Lutomirski wrote:
>>
>> Exactly my feeling. What are you trying to save? About four CPU
>> cycles of checking %ss != __KERNEL_DS on each switch_to?
>> That's not worth bothering about. Your last patch seems to be perfect.
> 
> We'll have to do the write to ss almost every time an AMD CPU sleeps
> in a syscall.  Maybe that's still not a big deal.
> 

Once you're sleeping anyway, I don't think so.

-hpa


--
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_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[H. Peter Anvin]

On 04/24/2015 01:50 PM, Andy Lutomirski wrote:
>>
>> Exactly my feeling. What are you trying to save? About four CPU
>> cycles of checking %ss != __KERNEL_DS on each switch_to?
>> That's not worth bothering about. Your last patch seems to be perfect.
> 
> We'll have to do the write to ss almost every time an AMD CPU sleeps
> in a syscall.  Maybe that's still not a big deal.
> 

Once you're sleeping anyway, I don't think so.

-hpa


--
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_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[H. Peter Anvin]

On 04/24/2015 01:50 PM, Andy Lutomirski wrote:
>>
>> Exactly my feeling. What are you trying to save? About four CPU
>> cycles of checking %ss != __KERNEL_DS on each switch_to?
>> That's not worth bothering about. Your last patch seems to be perfect.
> 
> We'll have to do the write to ss almost every time an AMD CPU sleeps
> in a syscall.  Maybe that's still not a big deal.
> 

Once you're sleeping anyway, I don't think so.

-hpa


--
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_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[H. Peter Anvin]

On 04/24/2015 01:50 PM, Andy Lutomirski wrote:
>>
>> Exactly my feeling. What are you trying to save? About four CPU
>> cycles of checking %ss != __KERNEL_DS on each switch_to?
>> That's not worth bothering about. Your last patch seems to be perfect.
> 
> We'll have to do the write to ss almost every time an AMD CPU sleeps
> in a syscall.  Maybe that's still not a big deal.
> 

Once you're sleeping anyway, I don't think so.

-hpa


--
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: loop block-mq conversion scalability issues

[Justin M. Forbes]

On Fri, 2015-04-24 at 10:59 +0800, Ming Lei wrote:
> Hi Justin,
> 
> Thanks for the report.
> 
> On Thu, 23 Apr 2015 16:04:10 -0500
> "Justin M. Forbes"  wrote:
> 
> > The block-mq conversion for loop in 4.0 kernels is showing us an
> > interesting scalability problem with live CDs (ro, squashfs).  It was
> > noticed when testing the Fedora beta that the more CPUs a liveCD image
> > was given, the slower it would boot. A 4 core qemu instance or bare
> > metal instance took more than twice as long to boot compared to a single
> > CPU instance.  After investigating, this came directly to the block-mq
> > conversion, reverting these 4 patches will return performance. More
> > details are available at
> > https://bugzilla.redhat.com/show_bug.cgi?id=1210857
> > I don't think that reverting the patches is the ideal solution so I am
> > looking for other options.  Since you know this code a bit better than I
> > do I thought I would run it by you while I am looking as well.
> 
> I can understand the issue because the default @max_active for
> alloc_workqueue() is quite big(512), which may cause too much
> context switchs, then loop I/O performance gets decreased.
> 
> Actually I have written the kernel dio/aio based patch for decreasing
> both CPU and memory utilization without sacrificing I/O performance,
> and I will try to improve and push the patch during this cycle and hope
> it can be merged(kernel/aio.c change is dropped, and only fs change is
> needed on fs/direct-io.c).
> 
> But the following change should help for your case, could you test it?
> 
> ---
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index c6b3726..b1cb41d 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1831,7 +1831,7 @@ static int __init loop_init(void)
>   }
>  
>   loop_wq = alloc_workqueue("kloopd",
> - WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0);
> + WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 32);
>   if (!loop_wq) {
>   err = -ENOMEM;
>   goto misc_out;
> 
Patch tested, it made things work (I gave up after 5 minutes and boot
still seemed hung). I also tried values of 1, 16, 64, and 128).
Everything below 128 was much worse than the current situation. Setting
it at 128 seemed about the same as booting without the patch. I can do
some more testing over the weekend, but I don't think this is the
correct solution.
I would be interested in testing your dio/aio patches as well though.

Thanks,
Justin

--
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_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[H. Peter Anvin]

On 04/24/2015 01:50 PM, Andy Lutomirski wrote:
>>
>> Exactly my feeling. What are you trying to save? About four CPU
>> cycles of checking %ss != __KERNEL_DS on each switch_to?
>> That's not worth bothering about. Your last patch seems to be perfect.
> 
> We'll have to do the write to ss almost every time an AMD CPU sleeps
> in a syscall.  Maybe that's still not a big deal.
> 

Once you're sleeping anyway, I don't think so.

-hpa


--
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_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[H. Peter Anvin]

On 04/24/2015 01:50 PM, Andy Lutomirski wrote:
>>
>> Exactly my feeling. What are you trying to save? About four CPU
>> cycles of checking %ss != __KERNEL_DS on each switch_to?
>> That's not worth bothering about. Your last patch seems to be perfect.
> 
> We'll have to do the write to ss almost every time an AMD CPU sleeps
> in a syscall.  Maybe that's still not a big deal.
> 

Once you're sleeping anyway, I don't think so.

-hpa


--
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: SATA link power management issues

[Tejun Heo]

Hello, Gabriele.

On Tue, Apr 21, 2015 at 11:44:28PM +0200, Gabriele Mazzotta wrote:
> I haven't considered that possibility. Something like the following then?

Yeah, looks great.  Some minor comments below.

> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -1700,6 +1700,8 @@ static void ahci_handle_port_interrupt(struct ata_port 
> *ap,
>   struct ahci_port_priv *pp = ap->private_data;
>   struct ahci_host_priv *hpriv = ap->host->private_data;
>   int resetting = !!(ap->pflags & ATA_PFLAG_RESETTING);
> + unsigned long lpm_timeout = ap->link.last_lpm_change + 10 * HZ;

We prolly want to define the timeout as a constant symbol in libata.h
and explain what this is about.

> + int ignore_event = 0;

Use bool?

> @@ -1707,8 +1709,13 @@ static void ahci_handle_port_interrupt(struct ata_port 
> *ap,
>   if (unlikely(resetting))
>   status &= ~PORT_IRQ_BAD_PMP;
>  
> + if (time_before(jiffies, lpm_timeout) &&
> + (ap->link.flags & ATA_LFLAG_CHANGED))
> + ignore_event = 1;

Nothing major but testing LFLAG first would prolly be a better style
given that timeout value is relevant only while the flag is asserted
and some comment would be nice too.

> @@ -788,6 +789,8 @@ struct ata_link {
>   struct ata_eh_context   eh_context;
>  
>   struct ata_device   device[ATA_MAX_DEVICES];
> +
> + unsigned long   last_lpm_change;

A brief explanation would be nice.

Thanks.

-- 
tejun
--
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] x86: punit_atom: punit device state debug driver

[Srinivas Pandruvada]

The patch adds a debug driver, which dumps the power states
of all the North complex (NC) devices. This debug interface is
useful to figure out the NC IPs which blocks the S0ix
transitions on the platform. This is extremely useful during
enabling PM on customer platforms and derivatives.

This submission not a complete rewrite from the original
submission from Kumar P, Mahesh .
https://lkml.org/lkml/2014/11/5/367
The changes are:
- Dropped changes to config for PMC_ATOM, as PMC_ATOM
is not just a debug driver as suggested by the change. It has
additional power off interface also.
- Instead of just using nc ("North complex") use punit_..
similar to south complex PMC. All the interfaces exposed
by this driver are provided by PUNIT.
- Removed pmc_config structure,  as we don't need to predefine
number of register, we want to dump. This way new register
can be added without changing NC_NUM_DEVICES.
- prefixed function with punit_
- The debugfs directory will be punit_atom, which is NC equivalent
of pmc_atom, which we already exposed by pmc_atom driver.

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Kumar P Mahesh 
Reviewed-by: Li, Aubrey 
---
 arch/x86/Kconfig |  10 +++
 arch/x86/kernel/Makefile |   1 +
 arch/x86/kernel/punit_atom.c | 167 +++
 3 files changed, 178 insertions(+)
 create mode 100644 arch/x86/kernel/punit_atom.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b7d31ca..b8e6de6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2578,6 +2578,16 @@ config PMC_ATOM
def_bool y
 depends on PCI
 
+config PUNIT_ATOM
+   bool "ATOM Punit debug driver"
+   def_bool n
+   depends on DEBUG_FS
+   select IOSF_MBI
+   ---help---
+ This is a debug driver, which gets the power states
+ of all Punit North Complex devices.The power states of
+ each IP is exposed as part of the debugfs interface.
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index cdb1b70..8ee5fb3 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_PERF_EVENTS)   += perf_regs.o
 obj-$(CONFIG_TRACING)  += tracepoint.o
 obj-$(CONFIG_IOSF_MBI) += iosf_mbi.o
 obj-$(CONFIG_PMC_ATOM) += pmc_atom.o
+obj-$(CONFIG_PUNIT_ATOM)   += punit_atom.o
 
 ###
 # 64 bit specific files
diff --git a/arch/x86/kernel/punit_atom.c b/arch/x86/kernel/punit_atom.c
new file mode 100644
index 000..f05d603
--- /dev/null
+++ b/arch/x86/kernel/punit_atom.c
@@ -0,0 +1,167 @@
+/*
+ * Intel SOC Punit device state debug driver
+ * Copyright (c) 2015, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PUNIT_PORT 0x04
+#define PWRGT_STATUS   0x61 /* Power gate status reg */
+#define VED_SS_PM0 0x32 /* Subsystem config/status Video */
+#define ISP_SS_PM0 0x39 /* Subsystem config/status ISP */
+#define MIO_SS_PM  0x3B /* Subsystem config/status MIO */
+#define SSS_SHIFT  24
+#define RENDER_POS 0
+#define MEDIA_POS  2
+#define VLV_DISPLAY_POS6
+#define CHT_DSP_SSS0x36 /* Subsystem config/status DSP */
+#define CHT_DSP_SSS_POS16
+
+struct punit_device {
+   char *name;
+   int reg;
+   int sss_pos;
+};
+
+static struct punit_device *punit_device;
+
+static const struct punit_device punit_device_byt[] = {
+   { "GFX RENDER", PWRGT_STATUS, RENDER_POS },
+   { "GFX MEDIA", PWRGT_STATUS, MEDIA_POS },
+   { "DISPLAY", PWRGT_STATUS, VLV_DISPLAY_POS },
+   { "VED", VED_SS_PM0, SSS_SHIFT},
+   { "ISP", ISP_SS_PM0, SSS_SHIFT},
+   { "MIO", MIO_SS_PM, SSS_SHIFT},
+   { NULL}
+};
+
+static const struct punit_device punit_device_cht[] = {
+   { "GFX RENDER", PWRGT_STATUS, RENDER_POS },
+   { "GFX MEDIA", PWRGT_STATUS, MEDIA_POS },
+   { "DSP", CHT_DSP_SSS,  CHT_DSP_SSS_POS },
+   { "VED", VED_SS_PM0, SSS_SHIFT},
+   { "ISP", ISP_SS_PM0, SSS_SHIFT},
+   { "MIO", MIO_SS_PM, SSS_SHIFT},
+   { NULL}
+};
+
+static const char * const dstates[] = {"D0", "D0i1", "D0i2", "D0i3"};
+
+static int punit_dev_state_show(struct seq_file *seq_file, void *unused)
+{
+   u32 punit_pwr_status;
+   int index;
+   int status;
+
+   seq_puts(seq_file, 

[PATCH 1/2] clocksource: arm_arch_timer: add arch_timer_okay_for_vdso

[Nathan Lynch]

The 32-bit ARM VDSO needs to know whether a generic timer is present
and whether it is suitable for use by user space.  The VDSO
initialization code currently duplicates some of the logic from the
driver to make this determination, but unfortunately it is incomplete;
it will incorrectly enable the VDSO if HYP mode is available or if no
interrupt is provided for the virtual timer (see arch_timer_init).  In
these cases the driver will switch to memory-backed access while the
VDSO will attempt to access the counter using cp15 reads.

Add an arch_timer_okay_for_vdso API which can reliably inform the VDSO
init code whether the arch timer is present and usable.

Signed-off-by: Nathan Lynch 
---
 drivers/clocksource/arm_arch_timer.c | 12 
 include/clocksource/arm_arch_timer.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 0aa135ddbf80..b75215523d2f 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -462,6 +462,18 @@ struct timecounter *arch_timer_get_timecounter(void)
return 
 }
 
+/* The ARM VDSO init code needs to know:
+ * - whether a cp15-based arch timer is present; and if so
+ * - whether the physical or virtual counter is being used.
+ */
+bool arch_timer_okay_for_vdso(void)
+{
+   if (!(arch_timers_present & ARCH_CP15_TIMER))
+   return false;
+
+   return arch_timer_use_virtual;
+}
+
 static void __init arch_counter_register(unsigned type)
 {
u64 start_count;
diff --git a/include/clocksource/arm_arch_timer.h 
b/include/clocksource/arm_arch_timer.h
index 9916d0e4eff5..bfc1e95280c4 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -48,6 +48,7 @@ enum arch_timer_reg {
 extern u32 arch_timer_get_rate(void);
 extern u64 (*arch_timer_read_counter)(void);
 extern struct timecounter *arch_timer_get_timecounter(void);
+extern bool arch_timer_okay_for_vdso(void);
 
 #else
 
@@ -66,6 +67,11 @@ static inline struct timecounter 
*arch_timer_get_timecounter(void)
return NULL;
 }
 
+static inline bool arch_timer_okay_for_vdso(void)
+{
+   return false;
+}
+
 #endif
 
 #endif
-- 
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 2/2] ARM: VDSO: use arch_timer_okay_for_vdso

[Nathan Lynch]

Use the facility now provided by the arm_arch_timer driver to
determine whether there's a usable virtual counter for the VDSO.

Signed-off-by: Nathan Lynch 
---
 arch/arm/kernel/vdso.c | 30 +-
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index efe17dd9b921..f06fd6f3f65f 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -69,33 +68,6 @@ struct elfinfo {
  */
 static bool cntvct_ok __read_mostly;
 
-static bool __init cntvct_functional(void)
-{
-   struct device_node *np;
-   bool ret = false;
-
-   if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
-   goto out;
-
-   /* The arm_arch_timer core should export
-* arch_timer_use_virtual or similar so we don't have to do
-* this.
-*/
-   np = of_find_compatible_node(NULL, NULL, "arm,armv7-timer");
-   if (!np)
-   goto out_put;
-
-   if (of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
-   goto out_put;
-
-   ret = true;
-
-out_put:
-   of_node_put(np);
-out:
-   return ret;
-}
-
 static void * __init find_section(Elf32_Ehdr *ehdr, const char *name,
  unsigned long *size)
 {
@@ -208,7 +180,7 @@ static int __init vdso_init(void)
vdso_total_pages = 1; /* for the data/vvar page */
vdso_total_pages += text_pages;
 
-   cntvct_ok = cntvct_functional();
+   cntvct_ok = arch_timer_okay_for_vdso();
 
patch_vdso(_start);
 
-- 
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/

Re: [PATCH v2] livepatch: x86: make kASLR logic more accurate

[Josh Poimboeuf]

On Fri, Apr 24, 2015 at 09:59:03PM +0200, Jiri Kosina wrote:
> We give up old_addr hint from the coming patch module in cases when kernel 
> load
> base has been randomized (as in such case, the coming module has no idea about
> the exact randomization offset).
> 
> We are currently too pessimistic, and give up immediately as soon as 
> CONFIG_RANDOMIZE_BASE is set; this doesn't however directly imply that the 
> load base has actually been randomized. There are config options that 
> disable kASLR (such as hibernation), user could have disabled kaslr on 
> kernel command-line, etc.
> 
> The loader propagates the information whether kernel has been randomized 
> through bootparams. This allows us to have the condition more accurate.
> 
> On top of that, it seems unnecessary to give up old_addr hints even if 
> randomization is active. The relocation offset can be computed as 
> difference between _text start and __START_KERNEL, and therefore old_addr 
> can be adjusted accordingly.
> 
> Signed-off-by: Jiri Kosina 
> ---
> 
> v1 -> v2: I accidentally used kgr_ suffix (which we use in kGraft) instead 
> of klp_ in v1.
> 
>  arch/x86/include/asm/livepatch.h | 4 
>  arch/x86/kernel/livepatch.c  | 5 +
>  kernel/livepatch/core.c  | 5 +++--
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/livepatch.h 
> b/arch/x86/include/asm/livepatch.h
> index 2d29197..84a3247 100644
> --- a/arch/x86/include/asm/livepatch.h
> +++ b/arch/x86/include/asm/livepatch.h
> @@ -23,8 +23,12 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_LIVEPATCH
> +
> +extern unsigned long klp_vmlinux_relocation_offset(void);
> +
>  static inline int klp_check_compiler_support(void)
>  {
>  #ifndef CC_USING_FENTRY
> diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
> index ff3c3101d..6df7902 100644
> --- a/arch/x86/kernel/livepatch.c
> +++ b/arch/x86/kernel/livepatch.c
> @@ -88,3 +88,8 @@ int klp_write_module_reloc(struct module *mod, unsigned 
> long type,
>  
>   return ret;
>  }
> +
> +unsigned long klp_vmlinux_relocation_offset(void)
> +{
> + return (unsigned long)&_text - __START_KERNEL;
> +}
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 284e269..ff4c35c 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -234,8 +234,9 @@ static int klp_find_verify_func_addr(struct klp_object 
> *obj,
>   int ret;
>  
>  #if defined(CONFIG_RANDOMIZE_BASE)
> - /* KASLR is enabled, disregard old_addr from user */
> - func->old_addr = 0;
> + /* If KASLR has been enabled, adjust old_addr accordingly */
> + if (kaslr_enabled())
> + func->old_addr += klp_vmlinux_relocation_offset();

The old_addr field is optional, where a value of 0 means "lookup the
address in kallsyms".  So its value should only be adjusted if old_addr
is already non-zero.  Otherwise the zero value will be replaced with a
bad address and it will mistakenly call klp_verify_vmlinux_symbol() with
the bad address instead of klp_find_object_symbol().

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

Re: [PATCH] tracing: Export key trace event symbols

[Mathieu Desnoyers]

- Original Message -
> On Mon, 20 Apr 2015 16:38:11 -0500
> Ron Rechenmacher  wrote:
> 
> > If symbols are not exported, modules can no longer register additional
> > (module specified) tracepoints like they use to be able to (i.e
> > linux-3.15.x).
> > Somewhere on or about commit de7b2973903c6cc50b31ee5682a69b2219b9919d
> > (Author: Mathieu Desnoyers 
> > Date:   Tue Apr 8 17:26:21 2014 -0400
> > tracepoint: Use struct pointer instead of name hash for reg/unreg
> > tracepoints)
> > modules which attempted to register additional tracing functions would
> > get "Unknown symbol" errors. For example: "... Unknown symbol
> > __tracepoint_sched_switch (err 0)"
> > Symbols can be exported using the kernel's EXPORT_TRACEPOINT_SYMBOL_GPL
> > macro
> > to allow modules to once again register their own tracing functions (for at
> > least some key points in the kernel as provided by this patch).
> > 
> > Signed-off-by: Ron Rechenmacher 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96051
> 
> Hi Ron,
> 
> I was talking with Mathieu on IRC and asked him how LTTng gets its
> kernel tracepoints, and he told me he uses
> for_each_kernel_tracepoint(). That will iterate over all tracepoints
> that have been added in the kernel (and is exported GPL).
> 
> You can still use that to get the handle onto any tracepoint you need.
> It's pretty straight forward (I just wrote a simple module to test it
> out), and just compare against the tp->name, to find what you want.
> 
> I still would like to get more usage out of the internal code, but this
> is your work around you wanted. No need to export new symbols. Just a
> little more setup time on module load.

Hi Ron,

Quoting a snippet of your earlier emails:

"ftrace (if one considers ltt-ng) is probably capable of doing what my trace 
does
except that the timestamp is not TOD (Time Of Day) -- but probably/maybe could
be made to do so???"

FYI, LTTng and Ftrace are two different projects. LTTng features
am out-of-tree kernel and a user-space tracer, whereas Ftrace features
a kernel tracer, readily available from the Linux kernel sources.

The timestamps can now be the monotonic clock for each of perf, ftrace,
and lttng, thanks to the work on nmi-safe clock source done by Thomas
Gleixner (merged in 3.17).

With the nmi-safe clocks, you'll be able to correlate samples
and traces taken by perf, ftrace, and lttng-modules with LTTng
userspace traces (LTTng-UST). This has been one of the goals of the
Common Trace Format (CTF) since its creation. You might want to look
at the perf-to-ctf conversion feature merged in Linux 4.0.

Best regards,

Mathieu



> 
> -- Steve
> 
> Here's my mod
> 
> 
> #include 
> #include 
> #include 
> 
> static func(struct tracepoint *tp, void *ignore)
> {
>   printk("tracepoint: %s\n", tp->name);
> }
> 
> static int __init my_tp_init(void)
> {
>   for_each_kernel_tracepoint(func, NULL);
>   return 0;
> }
> 
> static void __exit my_tp_exit(void)
> {
> }
> 
> module_init(my_tp_init);
> module_exit(my_tp_exit);
> 
> MODULE_AUTHOR("My name here");
> MODULE_DESCRIPTION("Me!");
> MODULE_LICENSE("GPL");
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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: [PATCH 2/2] mm/page_alloc.c: add config option to sanitize freed pages

[David Rientjes]

On Fri, 24 Apr 2015, Anisse Astier wrote:

> diff --git a/mm/Kconfig b/mm/Kconfig
> index 390214d..cb2df5f 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -635,3 +635,15 @@ config MAX_STACK_SIZE_MB
> changed to a smaller value in which case that is used.
>  
> A sane initial value is 80 MB.
> +
> +config SANITIZE_FREED_PAGES
> + bool "Sanitize memory pages after free"
> + default n
> + help
> +   This option is used to make sure all pages freed are zeroed. This is
> +   quite low-level and doesn't handle your slab buffers.
> +   It has various applications, from preventing some info leaks to
> +   helping kernel same-page merging in virtualised environments.
> +   Depending on your workload, it will reduce performance of about 3%.
> +
> +   If unsure, say N.

Objection to allowing this without first enabling some other DEBUG config 
option, it should never be a standalone option, but also to pretending to 
have any insight into what the performance degredation of it will be.  On 
my systems, this would be _massive_.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] mm/page_alloc.c: cleanup obsolete KM_USER*

[David Rientjes]

On Fri, 24 Apr 2015, Anisse Astier wrote:

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ebffa0e..05fcec9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -380,16 +380,10 @@ void prep_compound_page(struct page *page, unsigned 
> long order)
>   }
>  }
>  
> -static inline void prep_zero_page(struct page *page, unsigned int order,
> - gfp_t gfp_flags)
> +static inline void zero_pages(struct page *page, unsigned int order)
>  {
>   int i;
>  
> - /*
> -  * clear_highpage() will use KM_USER0, so it's a bug to use __GFP_ZERO
> -  * and __GFP_HIGHMEM from hard or soft interrupt context.
> -  */
> - VM_BUG_ON((gfp_flags & __GFP_HIGHMEM) && in_interrupt());
>   for (i = 0; i < (1 << order); i++)
>   clear_highpage(page + i);
>  }
> @@ -975,7 +969,7 @@ static int prep_new_page(struct page *page, unsigned int 
> order, gfp_t gfp_flags,
>   kasan_alloc_pages(page, order);
>  
>   if (gfp_flags & __GFP_ZERO)
> - prep_zero_page(page, order, gfp_flags);
> + zero_pages(page, order);
>  
>   if (order && (gfp_flags & __GFP_COMP))
>   prep_compound_page(page, order);

No objection to removing the VM_BUG_ON() here, but I'm not sure that we 
need an inline function to do this and to add additional callers in your 
next patch.  Why can't we just remove the helper entirely and do the 
iteration in prep_new_page()?  We iterate pages all the time.
--
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] block: remove unused BIO_RW_BLOCK and BIO_EOF flags

[Tejun Heo]

On Fri, Apr 24, 2015 at 09:41:02PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
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] block: remove BIO_EOPNOTSUPP

[Tejun Heo]

On Fri, Apr 24, 2015 at 09:41:01PM +0200, Christoph Hellwig wrote:
> Since the big barrier rewrite/removal in 2007 we never fail FLUSH or
> FUA requests, which means we can remove the magic BIO_EOPNOTSUPP flag
> to help propagating those to the buffer_head layer.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: Tejun Heo 

Thanks.

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

RE: [PATCH 00/20] mpt3sas: driver update

[Sathya Prakash]

Christoph,
We had internal discussion with our engineering and management on this
topic.  We are committed to provide bug fixes ( Only bug fixes and no new
features) across both the SAS2 and SAS3 source trees.  We prefer the SAS2
and SAS3 drivers to stay separate and the reason is;  merging of the
drivers is a time consuming and error prone task and with SAS2 products at
the maintenance mode we are thinking it will be risky to do the merge for
now.

Going forward for our future products we will be providing a  merged
driver (with common source separated out and having multiple kernel
modules compiled out of single source directory for each of our products)
to avoid maintenance overhead.

So please let us know whether the current patches can be ACKED if we
provide the applicable bug fixes to SAS2 or you see any other issues?.

Thanks
Sathya

-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Tuesday, April 21, 2015 6:14 AM
To: Sreekanth Reddy
Cc: Christoph Hellwig; j...@kernel.org; Martin K. Petersen;
linux-s...@vger.kernel.org; James E.J. Bottomley; Sathya Prakash; Kashyap
Desai; linux-kernel@vger.kernel.org; Tomas Henzl
Subject: Re: [PATCH 00/20] mpt3sas: driver update

On Wed, Apr 08, 2015 at 11:13:04AM +0530, Sreekanth Reddy wrote:
> Hi Chris,
>
> There are no corresponding mpt2sas driver's patches, The last phase
> for mpt2sas drivers is Phase20 and this phase driver is already exits
> in the upstream kernel. Also mpt2sas driver is completely in maintains
> mode and there won't be any new features.

But we'll still need all the bugfixes for existing users.

So a big NAK from me for any mpt3 patches that aren't urgen bug fixes
before we finally got the two drivers merged.
--
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/

net: non contiguous allocations passed to build_skb

[Sasha Levin]

Hey Eric,

Your commit 79930f5892e ("net: do not deplete pfmemalloc reserve") assumes that
build_skb() will only handle contiguous allocations because of the
virt_to_head_page().

However, netlink_sendmsg() calls build_skb() with vmalloc()ed memory, causing:

[ 1567.700067] kernel BUG at arch/x86/mm/physaddr.c:26!
[ 1567.700067] invalid opcode:  [#1] PREEMPT SMP KASAN
[ 1567.700067] Dumping ftrace buffer:
[ 1567.700067](ftrace buffer empty)
[ 1567.700067] Modules linked in:
[ 1567.700067] CPU: 9 PID: 16186 Comm: trinity-c182 Not tainted 
4.0.0-next-20150424-sasha-00037-g4796e21 #2167
[ 1567.700067] task: 880127efb000 ti: 88024677 task.ti: 
88024677
[ 1567.700067] RIP: __phys_addr (arch/x86/mm/physaddr.c:26 (discriminator 3))
[ 1567.700067] RSP: 0018:8802467779d8  EFLAGS: 00010202
[ 1567.700067] RAX: 41000ed8e000 RBX: c9008ed8e000 RCX: 002c
[ 1567.700067] RDX: 0004 RSI:  RDI: b3fd6049
[ 1567.700067] RBP: 8802467779f8 R08: 0019 R09: 8801d0168000
[ 1567.700067] R10: 8801d01680c7 R11: ed003a02d019 R12: c9000ed8e000
[ 1567.700067] R13: 0f40 R14: 1180 R15: c9000ed8e000
[ 1567.700067] FS:  7f2a7da3f700() GS:8801d100() 
knlGS:
[ 1567.700067] CS:  0010 DS:  ES:  CR0: 80050033
[ 1567.700067] CR2: 00738308 CR3: 00022e329000 CR4: 07e0
[ 1567.700067] Stack:
[ 1567.700067]  c9000ed8e000 8801d0168000 c9000ed8e000 
8801d0168000
[ 1567.700067]  880246777a28 ad7c0a21 1080 
880246777c08
[ 1567.700067]  88060d302e68 880246777b58 880246777b88 
ad9a6821
[ 1567.700067] Call Trace:
[ 1567.700067] build_skb (include/linux/mm.h:508 net/core/skbuff.c:316)
[ 1567.700067] netlink_sendmsg (net/netlink/af_netlink.c:1633 
net/netlink/af_netlink.c:2329)
[ 1567.774369] ? sched_clock_cpu (kernel/sched/clock.c:311)
[ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273)
[ 1567.774369] ? netlink_unicast (net/netlink/af_netlink.c:2273)
[ 1567.774369] sock_sendmsg (net/socket.c:614 net/socket.c:623)
[ 1567.774369] sock_write_iter (net/socket.c:823)
[ 1567.774369] ? sock_sendmsg (net/socket.c:806)
[ 1567.774369] __vfs_write (fs/read_write.c:479 fs/read_write.c:491)
[ 1567.774369] ? get_lock_stats (kernel/locking/lockdep.c:249)
[ 1567.774369] ? default_llseek (fs/read_write.c:487)
[ 1567.774369] ? vtime_account_user (kernel/sched/cputime.c:701)
[ 1567.774369] ? rw_verify_area (fs/read_write.c:406 (discriminator 4))
[ 1567.774369] vfs_write (fs/read_write.c:539)
[ 1567.774369] SyS_write (fs/read_write.c:586 fs/read_write.c:577)
[ 1567.774369] ? SyS_read (fs/read_write.c:577)
[ 1567.774369] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 1567.774369] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2594 
kernel/locking/lockdep.c:2636)
[ 1567.774369] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:42)
[ 1567.774369] system_call_fastpath (arch/x86/kernel/entry_64.S:261)
[ 1567.774369] Code: 0f b6 14 11 48 89 f9 83 e1 07 38 ca 7f 04 84 d2 75 54 0f 
b6 0d 8b 0b ec 0f 48 89 c2 48 d3 ea 48 85 d2 75 07 48 83 c4 18 5b 5d c3 <0f> 0b 
66 0f 1f 44 00 00 48 c7 c7 10 20 63 b1 48 b8 00 00 00 00
All code

   0:   0f b6 14 11 movzbl (%rcx,%rdx,1),%edx
   4:   48 89 f9mov%rdi,%rcx
   7:   83 e1 07and$0x7,%ecx
   a:   38 ca   cmp%cl,%dl
   c:   7f 04   jg 0x12
   e:   84 d2   test   %dl,%dl
  10:   75 54   jne0x66
  12:   0f b6 0d 8b 0b ec 0fmovzbl 0xfec0b8b(%rip),%ecx# 0xfec0ba4
  19:   48 89 c2mov%rax,%rdx
  1c:   48 d3 eashr%cl,%rdx
  1f:   48 85 d2test   %rdx,%rdx
  22:   75 07   jne0x2b
  24:   48 83 c4 18 add$0x18,%rsp
  28:   5b  pop%rbx
  29:   5d  pop%rbp
  2a:   c3  retq
  2b:*  0f 0b   ud2 <-- trapping instruction
  2d:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  33:   48 c7 c7 10 20 63 b1mov$0xb1632010,%rdi
  3a:   48  rex.W
  3b:   b8 00 00 00 00  mov$0x0,%eax
...

Code starting with the faulting instruction
===
   0:   0f 0b   ud2
   2:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
   8:   48 c7 c7 10 20 63 b1mov$0xb1632010,%rdi
   f:   48  rex.W
  10:   b8 00 00 00 00  mov$0x0,%eax
...
[ 1567.774369] RIP __phys_addr (arch/x86/mm/physaddr.c:26 (discriminator 3))
[ 1567.774369]  RSP 


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m

Re: [PATCH] tracing: Export key trace event symbols

[Steven Rostedt]

On Mon, 20 Apr 2015 16:38:11 -0500
Ron Rechenmacher  wrote:

> If symbols are not exported, modules can no longer register additional
> (module specified) tracepoints like they use to be able to (i.e linux-3.15.x).
> Somewhere on or about commit de7b2973903c6cc50b31ee5682a69b2219b9919d
> (Author: Mathieu Desnoyers 
> Date:   Tue Apr 8 17:26:21 2014 -0400
> tracepoint: Use struct pointer instead of name hash for reg/unreg tracepoints)
> modules which attempted to register additional tracing functions would
> get "Unknown symbol" errors. For example: "... Unknown symbol
> __tracepoint_sched_switch (err 0)"
> Symbols can be exported using the kernel's EXPORT_TRACEPOINT_SYMBOL_GPL macro
> to allow modules to once again register their own tracing functions (for at
> least some key points in the kernel as provided by this patch).
> 
> Signed-off-by: Ron Rechenmacher 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96051

Hi Ron,

I was talking with Mathieu on IRC and asked him how LTTng gets its
kernel tracepoints, and he told me he uses
for_each_kernel_tracepoint(). That will iterate over all tracepoints
that have been added in the kernel (and is exported GPL).

You can still use that to get the handle onto any tracepoint you need.
It's pretty straight forward (I just wrote a simple module to test it
out), and just compare against the tp->name, to find what you want.

I still would like to get more usage out of the internal code, but this
is your work around you wanted. No need to export new symbols. Just a
little more setup time on module load.

-- Steve

Here's my mod


#include 
#include 
#include 

static func(struct tracepoint *tp, void *ignore)
{
printk("tracepoint: %s\n", tp->name);
}

static int __init my_tp_init(void)
{
for_each_kernel_tracepoint(func, NULL);
return 0;
}

static void __exit my_tp_exit(void)
{
}

module_init(my_tp_init);
module_exit(my_tp_exit);

MODULE_AUTHOR("My name here");
MODULE_DESCRIPTION("Me!");
MODULE_LICENSE("GPL");
--
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] show isolated cpus in sysfs

[Rik van Riel]

On 04/24/2015 05:11 PM, Frederic Weisbecker wrote:
> On Fri, Apr 24, 2015 at 03:24:27PM -0400, r...@redhat.com wrote:
>> From: Rik van Riel 
>>
>> After system bootup, there is no totally reliable way to see
>> which CPUs are isolated, because the kernel may modify the
>> CPUs specified on the isolcpus= kernel command line option.
>>
>> Export the CPU list that actually got isolated in sysfs,
>> specifically in the file /sys/devices/system/cpu/isolated
>>
>> This can be used by system management tools like libvirt,
>> openstack, and others to ensure proper placement of tasks.
>>
>> Suggested-by: Li Zefan 
>> Signed-off-by: Rik van Riel 
> 
> This patch should go through Peterz.

Oh, fun. That's what I get for getting the get_maintainer.pl
script, which told me to go through Greg KH instead :)

$ ./scripts/get_maintainer.pl -f drivers/base/cpu.c
Greg Kroah-Hartman  (supporter:DRIVER CORE,
KOBJ...)
linux-kernel@vger.kernel.org (open list)

-- 
All rights reversed
--
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] show isolated cpus in sysfs

[Tejun Heo]

On Fri, Apr 24, 2015 at 11:11:29PM +0200, Frederic Weisbecker wrote:
> > Suggested-by: Li Zefan 
> > Signed-off-by: Rik van Riel 
> 
> This patch should go through Peterz.

Right, that's why the two patches kinda got lost.  Rik, sorry about
that and yes these two should go through Peterz.

Thanks.

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

Re: [PATCH 00/21] ARCNET: Defibrillation

[Marc Kleine-Budde]

On 04/24/2015 08:47 PM, Joe Perches wrote:
> On Fri, 2015-04-24 at 19:20 +0200, Michael Grzeschik wrote:
>> Hi!
> 
> Hello.
> 
>> This patch series tries to reanimate the ARCNET hardware layer to be
>> somehow readable and maintainable again. It includes a lot of cleanup
>> patches. It also adds some fixes which leads the layer to become usable
>> again. And as a special treatment it adds more features like correct
>> loading and unloading of the com20020 card.
> 
> Wow.  Good for you, but why?  Does anyone still use these?

Yes, there are parts of the industry where "old" machines are
retrofitted with new hardware...and a lot of these machines still talk
ARCNET :)

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [RFC] capabilities: Ambient capabilities

[Serge E. Hallyn]

On Fri, Apr 24, 2015 at 01:18:44PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 24, 2015 at 1:13 PM, Christoph Lameter  wrote:
> > On Fri, 24 Apr 2015, Andy Lutomirski wrote:
> >
> >> That's sort of what my patch does -- you need CAP_SETPCAP to switch
> >> the securebit.
> >>
> >> But Christoph's patch required it to add caps to the ambient set, right?
> >
> > Yes but you seem to be just adding one additional step without too much of
> > a benefit because you still need CAP_SETPCAP.
> >
> 
> No, because I set the default to on :)

Right - I definately prefer

. default off
. CAP_SETPCAP required to turn it on (for self and children)
. once on, anyone can copy bits from (whatever we decided) to pA.

> Also, in my model you can do:
> 
> $ sudo capset cap_whatever=eip something
> $ ./something
> 
> and the program can make its cap be ambient and run a helper.  In the
> CAP_SETPCAP model, that doesn't work.
> 
> --Andy
> 
> -- 
> 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/
--
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 v6 0/6] arm64: Add kernel probes (kprobes) support

[William Cohen]

On 04/21/2015 07:42 AM, Masami Hiramatsu wrote:
> (2015/04/21 5:19), David Long wrote:
>> From: "David A. Long" 
>>
>> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
>> first seen in October 2013. This version attempts to address concerns raised 
>> by
>> reviewers and also fixes problems discovered during testing.
>>
>> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
>> and return probes(kretprobes) support for ARM64.
>>
>> The kprobes mechanism makes use of software breakpoint and single stepping
>> support available in the ARM v8 kernel.
>>
> [...]
>> Changes since v5 include:
>>
>> 1) Replaced installation of breakpoint hook with direct call from the
>> handlers in debug-monitors.c, as requested.
>> 2) Reject probing of instructions that read the interrupt mask, in
>> addition to instructions that set it.
>> 3) Cleaned up comments describing usage of Debug Mask.
>> 4) Added KPROBE_REENTER case in reenter_kprobe.
>> 5) Corrected the ifdef'd definitions for notify_page_fault() to be
>> consistent when KPROBES is not configed.
>> 6) Changed "cpsr" to "pstate" for HAVE_REGS_AND_STACK_ACCESS_API feature.
>> 7) Added back in missing new files in previous patch.
>> 8) Changed two instances of pr_warning() to pr_warn().
> 
> Looks OK to me:)
> BTW, have you tried to build and test this with CONFIG_KPROBE_EVENT?
> If so, you can also test it by tools/testing/selftests/ftrace/ftracetest.
> 
>> Note that there seems to be at least a potential issue with kprobes
>> on multiple (possibly all) platforms having to do with use of kfree
>> inside of the kretprobes trampoline handler.  This has manifested
>> occasionally in systemtap testing on arm64.  There does not appear to
>> be an simple solution to the problem.
> 
> No, trampoline handler must call recycle_rp_inst() instead of kfree
> to return kretprobe instance to the pool. Hmm, I should look into it.
> 
> Thank you,
> 

Hi All,

At time the kernel with arm64 kprobe patches gets stuck printing out:

Unexpected kernel single-step exception at EL1

I put some instrumentation in debug-monitor.c to print out the kcb and register 
state when this happens.  Below is an example output:

[14613.263536] Unexpected kernel single-step exception at EL1
[14613.269001] kcb->ss_ctx.ss_status = 1
[14613.272643] kcb->ss_ctx.match_addr = fdfffc001250 0xfdfffc001250
[14613.279324] instruction_pointer(regs) = fe093358 el1_da+0x8/0x70
[14613.286003] 
[14613.287487] CPU: 3 PID: 621 Comm: irqbalance Tainted: G   OE   
4.0.0u4+ #6
[14613.295019] Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0-rh-0.15 
Mar 13 2015
[14613.302982] task: fe01d6806780 ti: fe01d68ac000 task.ti: 
fe01d68ac000
[14613.310430] PC is at el1_da+0x8/0x70
[14613.313990] LR is at trampoline_probe_handler+0x188/0x1ec
[14613.319363] pc : [] lr : [] pstate: 
61c5
[14613.326724] sp : fe01d68af640
[14613.330021] x29: fe01d68afbf0 x28: fe01d68ac000 
[14613.335328] x27: fe0939cc x26: febb09d0 
[14613.340634] x25: fe01d68afdb0 x24: 0025 
[14613.345939] x23: 83c5 x22: fdfffc001284 
[14613.351245] x21: fe01d68af760 x20: fe01d7c79a00 
[14613.356552] x19:  x18: 03ffa4b8e600 
[14613.361858] x17: 03ffa5480698 x16: fe1f2afc 
[14613.367164] x15: 0007 x14: 03ffeffa8690 
[14613.372471] x13: 0001 x12: 03ffa4baf200 
[14613.38] x11: fe6bb328 x10: fe6bb32c 
[14613.383084] x9 : fe01d68afd10 x8 : fe01d6806d10 
[14613.388390] x7 : fe01ffd01298 x6 : fe09192c 
[14613.393696] x5 : fec1b398 x4 :  
[14613.399001] x3 : 00200200 x2 : 00100100 
[14613.404306] x1 : 9606 x0 : 0015 
[14613.409610] 
[14613.411094] BUG: failure at 
arch/arm64/kernel/debug-monitors.c:276/single_step_handler()!

One thing to note is the pstate value 0x61c5; it has the SS bit set.  I 
think that sometime during handling the kprobe the SS is being set incorrectly 
or not cleared in the saved state.  When the register state gets reload a 
single step is attempted and the debug-monitors code flags it because it 
doesn't match up to the currently running kprobe.

Is single_step_handler functions setting the flag again with 
set_regs_spsr_ss(regs) the correct way to handle this if it wasn't previously 
handled?  If the single step isn't handled the first time, why are the 
following instructions going to be handled? It is going to spew many warning 
messages.

-Will Cohen
--
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] show isolated cpus in sysfs

[Frederic Weisbecker]

On Fri, Apr 24, 2015 at 03:24:27PM -0400, r...@redhat.com wrote:
> From: Rik van Riel 
> 
> After system bootup, there is no totally reliable way to see
> which CPUs are isolated, because the kernel may modify the
> CPUs specified on the isolcpus= kernel command line option.
> 
> Export the CPU list that actually got isolated in sysfs,
> specifically in the file /sys/devices/system/cpu/isolated
> 
> This can be used by system management tools like libvirt,
> openstack, and others to ensure proper placement of tasks.
> 
> Suggested-by: Li Zefan 
> Signed-off-by: Rik van Riel 

This patch should go through Peterz.

> ---
>  drivers/base/cpu.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index f160ea44a86d..ea23ee7b545b 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -265,6 +265,17 @@ static ssize_t print_cpus_offline(struct device *dev,
>  }
>  static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
>  
> +static ssize_t print_cpus_isolated(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + int n = 0, len = PAGE_SIZE-2;
> +
> + n = scnprintf(buf, len, "%*pbl\n", cpumask_pr_args(cpu_isolated_map));
> +
> + return n;
> +}
> +static DEVICE_ATTR(isolated, 0444, print_cpus_isolated, NULL);
> +
>  static void cpu_device_release(struct device *dev)
>  {
>   /*
> @@ -431,6 +442,7 @@ static struct attribute *cpu_root_attrs[] = {
>   _attrs[2].attr.attr,
>   _attr_kernel_max.attr,
>   _attr_offline.attr,
> + _attr_isolated.attr,
>  #ifdef CONFIG_GENERIC_CPU_AUTOPROBE
>   _attr_modalias.attr,
>  #endif
> -- 
> 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: [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing

[Suravee Suthikulpanit]

On 4/16/15 20:45, Zheng, Lv wrote:

Before back porting this to ACPICA, let me ask one simple question.
According to the spec, the _CLS is optional and PCI specific.
So why should we implement it in ACPICA core not OSPM specific modules?
If this need to be implemented in ACPICA, then what about the following device 
identification objects?
_DDN, _HRV, _MLS, _PLD, _STR, _SUN

Thanks and best regards
-Lv


Hi,

Sorry for late reply. As for the justification for introducing the _CLS 
support in the ACPICA, this is mainly because ACPI does not currently 
define _CID for certain device classes, which used to mostly be PCI 
devices. Instead, ACPI spec mentioned that _CLS can be used for loading 
generic drivers on hardware that is compatible with PCI-defined device 
classes, but that is not implemented on the PCI bus (and is therefore 
enumerated by ACPI.)


The code introduced for supporting _CLS is also similar in the way 
ACPICA is currently parsing the _CID or _SUB (which are also optional), 
and using it for the same purpose of identifying devices for loading 
drivers.


Also, since this method for identifying devices is OS-independent, I 
believe this should not be done in the OSPM specific modules.


Thanks,

Suravee
--
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] mm/page_alloc.c: add config option to sanitize freed pages

[Anisse Astier]

This new config option will sanitize all freed pages. This is a pretty
low-level change useful to track some cases of use-after-free, help
kernel same-page merging in VM environments, and counter a few info
leaks.

Signed-off-by: Anisse Astier 
---
 mm/Kconfig  | 12 
 mm/page_alloc.c |  5 +
 2 files changed, 17 insertions(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 390214d..cb2df5f 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -635,3 +635,15 @@ config MAX_STACK_SIZE_MB
  changed to a smaller value in which case that is used.
 
  A sane initial value is 80 MB.
+
+config SANITIZE_FREED_PAGES
+   bool "Sanitize memory pages after free"
+   default n
+   help
+ This option is used to make sure all pages freed are zeroed. This is
+ quite low-level and doesn't handle your slab buffers.
+ It has various applications, from preventing some info leaks to
+ helping kernel same-page merging in virtualised environments.
+ Depending on your workload, it will reduce performance of about 3%.
+
+ If unsure, say N.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 05fcec9..c71440a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -803,6 +803,11 @@ static bool free_pages_prepare(struct page *page, unsigned 
int order)
debug_check_no_obj_freed(page_address(page),
   PAGE_SIZE << order);
}
+
+#ifdef CONFIG_SANITIZE_FREED_PAGES
+   zero_pages(page, order);
+#endif
+
arch_free_page(page, order);
kernel_map_pages(page, 1 << order, 0);
 
-- 
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 1/2] mm/page_alloc.c: cleanup obsolete KM_USER*

[Anisse Astier]

It's been five years now that KM_* kmap flags have been removed and
that we can call clear_highpage from any context. So we simplify
prep_zero_pages accordingly and rename it in the process.

Signed-off-by: Anisse Astier 
---
 mm/page_alloc.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ebffa0e..05fcec9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -380,16 +380,10 @@ void prep_compound_page(struct page *page, unsigned long 
order)
}
 }
 
-static inline void prep_zero_page(struct page *page, unsigned int order,
-   gfp_t gfp_flags)
+static inline void zero_pages(struct page *page, unsigned int order)
 {
int i;
 
-   /*
-* clear_highpage() will use KM_USER0, so it's a bug to use __GFP_ZERO
-* and __GFP_HIGHMEM from hard or soft interrupt context.
-*/
-   VM_BUG_ON((gfp_flags & __GFP_HIGHMEM) && in_interrupt());
for (i = 0; i < (1 << order); i++)
clear_highpage(page + i);
 }
@@ -975,7 +969,7 @@ static int prep_new_page(struct page *page, unsigned int 
order, gfp_t gfp_flags,
kasan_alloc_pages(page, order);
 
if (gfp_flags & __GFP_ZERO)
-   prep_zero_page(page, order, gfp_flags);
+   zero_pages(page, order);
 
if (order && (gfp_flags & __GFP_COMP))
prep_compound_page(page, order);
-- 
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 0/2] Sanitizing freed pages

[Anisse Astier]

Hi,

I'm trying revive an old debate here[1], though with a simpler approach than
was previously tried. This patch series implements a new option to sanitize
freed pages, a (very) small subset of what is done in PaX/grsecurity[3],
inspired by a previous submission [4].

The first patch is fairly independent, and could be taken as-is. The second is
the meat and should be straight-forward to review.

There are a few different uses that this can cover:
 - some cases of use-after-free could be detected (crashes), although this not
   as efficient as KAsan/kmemcheck
 - it can help with long-term memory consumption in an environment with
   multiple VMs and Kernel Same-page Merging on the host. [2]
 - finally, it can reduce infoleaks, although this is hard to measure.

The approach is voluntarily kept as simple as possible. A single configuration
option, no command line option, no sysctl nob. It can of course be changed,
although I'd be wary of runtime-configuration options that could be used for
races.

I haven't been able to measure a meaningful performance difference when
compiling a (in-cache) kernel; I'd be interested to see what difference it
makes with your particular workload/hardware (I suspect mine is CPU-bound on
this small laptop).


[1] https://lwn.net/Articles/334747/
[2] https://staff.aist.go.jp/k.suzaki/EuroSec12-SUZAKI-revised2.pdf
[3] 
http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory
[4] http://article.gmane.org/gmane.linux.kernel.mm/34398

Anisse Astier (2):
  mm/page_alloc.c: cleanup obsolete KM_USER*
  mm/page_alloc.c: add config option to sanitize freed pages

 mm/Kconfig  | 12 
 mm/page_alloc.c | 15 +++
 2 files changed, 19 insertions(+), 8 deletions(-)

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

Re: [PATCH] usb: dwc3: gadget: call gadget driver's ->suspend/->resume

[David Cohen]

On Fri, Apr 24, 2015 at 02:48:27PM -0500, Felipe Balbi wrote:
> Hi,

Hi Felipe,

> 
> On Thu, Apr 23, 2015 at 03:37:48PM -0700, David Cohen wrote:
> > On Fri, Apr 17, 2015 at 02:43:27PM -0500, Felipe Balbi wrote:
> > > On Fri, Apr 17, 2015 at 11:41:56AM -0700, David Cohen wrote:
> > > > From: Felipe Balbi 
> > > 
> > > missing the required:
> > > 
> > > [ Upstream commit bc5ba2e0b829c9397f96df1191c7d2319ebc36d9 ]
> > > 
> > > > 
> > > > When going into bus suspend/resume we _must_
> > > > call gadget driver's ->suspend/->resume callbacks
> > > > accordingly. This patch implements that very feature
> > > > which has been missing forever.
> > > > 
> > > > Cc:  # 3.14
> > > > Signed-off-by: Felipe Balbi 
> > > > Signed-off-by: David Cohen 
> > > > ---
> > > > 
> > > > Hi,
> > > > 
> > > > This patch was introduced on v3.15.
> > > > But the issue it fixes already existed on v3.14 and v3.14 is a long term
> > > > support version.
> > > 
> > > Can you show me a log of this breaking anywhere ? Why do you consider
> > > this a bug fix ? What sort of drawbacks did you notice ?
> > 
> > We're seeing BC1.2 compliance test failure. I borrowed this info from
> > the bug report :)
> > 
> > 1. BC1.2 compliance testing - SDP2.0
> > ---
> > 1. On Connect to active Host (Expected result: 100mA to 500mA):
> >Actual result 100mA to 500mA
> > 
> > 2. On Host Suspend (ER: Fall back to 0mA):
> >not falling back to 0mA, remains at 500mA
> > 
> > 3. On Connect to Suspended Host (ER: 100mA to 0mA):
> >cable-props shown as 100mA, which means drawing a current of 100mA from
> >Suspended Host
> > 
> > 4. On making Host active (ER: 500mA):
> >500mA
> 
> But we don't support Battery Charging with dwc3 as of now :-) In fact,
> just note that none of the BC registers are even defined in the current
> driver anywhere. Seems like you should cherry-pick these to your vendor
> tree, but v3.14 vanilla, because it doesn't support BC1.2, can't be
> claimed to be at fault, right ?

We could call it a missing feature that could lead to a potential bug :)
By your own comment, he "must" was stressed out:
'''
When going into bus suspend/resume we _must_
call gadget driver's ->suspend/->resume callbacks
accordingly. This patch implements that very feature
which has been missing forever.
'''

Since v3.14 is a LTS kernel and the changes are safe, it's worth to
consider.

> 
> I'll leave the final decision to Greg and I don't really oppose having
> both patches on v3.14-stable, but this is not a bug fix in my view.

Thanks. I appreciate your feedback.

BR, David

PS: FWIW implementing features or fixing bugs aren't much different tasks:
https://geekwhisperin.files.wordpress.com/2009/09/bug-vs-feature.jpg
--
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_64, asm: Work around AMD SYSRET SS descriptor attribute issue

[Linus Torvalds]

On Fri, Apr 24, 2015 at 1:21 PM, Andy Lutomirski  wrote:
>
> 2. SYSRETQ.  The only way that I know of to see the problem is SYSRETQ
> followed by a far jump or return.  This is presumably *extremely*
> rare.
>
> What if we fixed #2 up in do_stack_segment.  We should double-check
> the docs, but I think that this will only ever manifest as #SS(0) with
> regs->ss == __USER_DS and !user_mode_64bit(regs).

Hmm. It smells a bit "too clever" for me, and in particular, I think
you need a good test-case for this. But yeah, I guess that gets things
out of any possibly critical paths.

That said, I wouldn't even be sure about the SS(0). The rules about
when you get SS and when you get GP are odd.

Also, you need to check what happens when somebody does something like

movl $-1,%eax
ss ; movl (%eax),%eax

because I think that gets a #DB(0) too with the situation you expect
to be "unique", because the address wraps.. I dunno.

So care and testing needed. I think the scheduler approach is a *lot*
more obvious, quite frankly.

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

Re: [LKP] [fanotify] 66ba93c0d7f: i6300esb: Unexpected close, not stopping watchdog!

[Lino Sanfilippo]

On 24.04.2015 19:42, Andrew Morton wrote:
> On Thu, 23 Apr 2015 14:25:38 +0800 Huang Ying  wrote:
> 
>> FYI, we noticed the below changes on
>> 
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> commit 66ba93c0d7fe63def447ad0afe380307ff9ebcad ("fanotify: don't set 
>> FAN_ONDIR implicitly on a marks ignored mask")
>> 
>> When doing LTP test.  Test system hang after doing some fanotify test cases, 
>> while system
>> can run to reboot in the parent comments.
> 
> Thanks.  I've queued a reversion patch.  I'll hold off sending it to
> Linus for a while, to see if we can get this fixed up.
> 
> 
> What does "hang" mean?  Was the machine all locked up?  Or is it the
> case that the particular LTP test failed to complete?  I suspect the
> latter - that the new notify behaviour is differing from LTP's
> expectation in some fashion?
> 

Hi,

I think your suspicion is right, it looks like an issue that has been
reported a few weeks ago:
http://marc.info/?l=linux-kernel=142688498719023=2

The reason was not in kernel code though (as assumed by the reporter)
but a missing FAN_ONDIR in the code of the fanotify02 test case (that
flag was not needed before since it was set implicitly under certain
conditions - see the commit message of
66ba93c0d7fe63def447ad0afe380307ff9ebcad for details). The code has been
fixed in the latest version of LTP. I tested fanotify with this version
(20150420) and all tests passed.
Huang could it be that you did not use the latest LTP?

Regards,
Lino
--
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/