[PATCH v2] spi: dw: support 4-16 bits per word

[Simon Goldschmidt]

The spi-dw driver currently only supports 8 or 16 bits per word.

Since the hardware supports 4-16 bits per word, adapt the driver
to also support this.

Tested on socfpga cyclone5 with a 9-bit SPI display.

Signed-off-by: Simon Goldschmidt 
---

Changes in v2:
- use DIV_ROUND_UP to calculate number of bytes per word instead of
  if/else range checks

 drivers/spi/spi-dw.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index f693bfe95ab9..58a7caf31d59 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -307,15 +307,13 @@ static int dw_spi_transfer_one(struct spi_controller 
*master,
dws->current_freq = transfer->speed_hz;
spi_set_clk(dws, chip->clk_div);
}
-   if (transfer->bits_per_word == 8) {
-   dws->n_bytes = 1;
-   dws->dma_width = 1;
-   } else if (transfer->bits_per_word == 16) {
-   dws->n_bytes = 2;
-   dws->dma_width = 2;
-   } else {
+
+   if ((transfer->bits_per_word < 4) || (transfer->bits_per_word > 16))
return -EINVAL;
-   }
+
+   dws->n_bytes = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
+   dws->dma_width = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
+
/* Default SPI mode is SCPOL = 0, SCPH = 0 */
cr0 = (transfer->bits_per_word - 1)
| (chip->type << SPI_FRF_OFFSET)
@@ -493,7 +491,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
}
 
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
-   master->bits_per_word_mask = SPI_BPW_MASK(8) | SPI_BPW_MASK(16);
+   master->bits_per_word_mask =  SPI_BPW_RANGE_MASK(4, 16);
master->bus_num = dws->bus_num;
master->num_chipselect = dws->num_cs;
master->setup = dw_spi_setup;
-- 
2.17.1

Re: [PATCH v2] Bugfix for handling of shadow doorbell buffer.

[Christoph Hellwig]

I've applied this with some major updates to the subject, changelog
and the comment in the code.  Please double check it all still makes
sense.

Re: [PATCH] Bugfix for handling of shadow doorbell buffer.

[Christoph Hellwig]

On Tue, Aug 14, 2018 at 06:35:16PM -0700, Michal Wnukowski wrote:
> 
> The other side in this case is not actual controller hardware, but 
> virtual one (the regular hardware should rely on normal MMIO 
> doorbells).

There could very much be real hardware there.  We've made it clear
in the spec that while a typical use case is a virtualized controller
there is nothing peventing hardware implementations.  There have
been previous hardware prototypes to use very similar tricks, e.g.:

https://www.usenix.org/node/179878

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

[Sedat Dilek]

On Thu, Aug 16, 2018 at 7:14 PM, Linus Torvalds
 wrote:
> On Thu, Aug 16, 2018 at 12:37 AM Sedat Dilek  wrote:
>>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>
> Right. That branch - for obvious reasons - was never really available
> on a public site. I had it as a bundle over secure email, and just
> faked it all.
>
>> How can I get the history and subjects of all commits in your tree to
>> cherry-pick the single commits?
>
> Just do "git fetch" of my upstream.  Not merging it (so no pull), just
> fetching everything I have.
>
> You don't want just the l1tf branch anyway, since there's three or
> four subsequent fixes there too..
>
>  Linus

Thanks Linus.

I looked at the patchset of Linux 4.18.2-rc1 [1].
Some of those patches are not in your tree.

- Sedat -

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-4.18.y

Re: [PATCH v4 4/5] clk: imx: add imx composite clock

[Sascha Hauer]

Hi Abel,

On Thu, Aug 16, 2018 at 06:27:15PM +0300, Abel Vesa wrote:
> Since a lot of clocks on imx8 are formed by a mux, gate, predivider and
> divider, the idea here is to combine all of those into one more complex
> clock type, therefore moving the complexity inside the composite clock and
> outside of the SoC specific clock driver.
> 
> Signed-off-by: Abel Vesa 
> ---
>  drivers/clk/imx/Makefile|   1 +
>  drivers/clk/imx/clk-composite.c | 471 
> 
>  drivers/clk/imx/clk.h   |   9 +
>  3 files changed, 481 insertions(+)
>  create mode 100644 drivers/clk/imx/clk-composite.c
> 
> diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
> index b87513c..4fabb0a 100644
> --- a/drivers/clk/imx/Makefile
> +++ b/drivers/clk/imx/Makefile
> @@ -3,6 +3,7 @@
>  obj-y += \
>   clk.o \
>   clk-busy.o \
> + clk-composite.o \
>   clk-cpu.o \
>   clk-fixup-div.o \
>   clk-fixup-mux.o \
> diff --git a/drivers/clk/imx/clk-composite.c b/drivers/clk/imx/clk-composite.c

You nearly duplicate drivers/clk/clk-composite.c. This seems necessary
because in the hardware we have two dividers instead of a single one as
the generic composite clock type support.

Instead of duplicating the composite clk code you could create your own
clk_ops for the divider which handles both dividers in a single
callback. You could then use the generic composite clk.

When I made the suggestion that we should a create a composite clk I had
assumed you'd come up with a patch which has a single private struct clk_ops
filled in with the gate/mux/rate callbacks which are then open coded in
your driver. I am not convinced this splitting up in three different
(gate/mux/rate) struct clk_ops brings us anything. For example the open
coded gate code is really trivial compared to all this boilerplate code
we need for the generic composite clk. But maybe the maintainers have a
different opinion?

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] remoteproc/davinci: Use %zx for formating size_t

[Bartosz Golaszewski]

2018-08-17 2:49 GMT+02:00 Bjorn Andersson :
> da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
> print of it to avoid a compile warning.
>
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/remoteproc/da8xx_remoteproc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/da8xx_remoteproc.c 
> b/drivers/remoteproc/da8xx_remoteproc.c
> index e230bef71be1..d200334577f6 100644
> --- a/drivers/remoteproc/da8xx_remoteproc.c
> +++ b/drivers/remoteproc/da8xx_remoteproc.c
> @@ -226,7 +226,7 @@ static int da8xx_rproc_get_internal_memories(struct 
> platform_device *pdev,
> res->start & DA8XX_RPROC_LOCAL_ADDRESS_MASK;
> drproc->mem[i].size = resource_size(res);
>
> -   dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 
> 0x%x\n",
> +   dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %p da 
> 0x%x\n",
> mem_names[i], &drproc->mem[i].bus_addr,
> drproc->mem[i].size, drproc->mem[i].cpu_addr,
> drproc->mem[i].dev_addr);
> --
> 2.18.0
>

Reviewed-by: Bartosz Golaszewski 

Can you also pick up this patch[1] for v4.19? David Lechner already
has a patch queued for v4.20 that depends on this one.

Thanks,
Bartosz

[1] https://patchwork.kernel.org/patch/10479365/

Re: [PATCH] linux/bitmap.h: (buildbot-only) check if we have any compile-time zero-size bitmaps

[Rasmus Villemoes]

On 2018-08-17 01:21, Yury Norov wrote:
> Hi Rasmus,
> 
> On Wed, Aug 15, 2018 at 10:55:39AM +0200, Rasmus Villemoes wrote:
>> Most of the inline bitmap functions are buggy if passed a compile-time
>> constant nbits==0.
> 
> I think it's bad wording. Functions are OK. The problem is in users.

Why shouldn't we handle a zero-size bitmap gracefully? In any case, if
you believe nbits==0 is an implicit violation of the API, all the more
reason to detect if we have such users.

> Also, run-time nbits==0 is buggy as well.

No, not according to my reading of lib/bitmap.c. Can you point out any
function in there that doesn't behave correctly when passed nbits==0?

 On the other hand, we have a rule
> in include/linux/bitmap.h:
>   * Note that nbits should be always a compile time evaluable constant.
>   * Otherwise many inlines will generate horrible code.
> So runtime-defined nbits is bad thing by itself.

Yeah, that ship has sailed long ago. We have lots of users where for
whatever reason nbits is not constant and/or is bigger than
BITS_PER_LONG, and a function call isn't really that horrible. Probably
that piece of doc should be removed or relaxed. I have a small series
that removes another piece of wrong doc, I'll tweak this as well.

One thing that might be worth looking into is to see if we have some
places where nbits is not compile-time const, but is compile-time known
to be in 1 <= nbits <= BITS_PER_LONG, and use the inline branches in
those cases as well. Matthew already did something like that with
2c6deb01525, where we use the inline case when nbits are known to be a
multiple of 8.

>>
>> Not-really-signed-off-by: Rasmus Villemoes 
>> ---
>>
>> +int const_zero_size_bitmaps_are_buggy(void);
> 
> It introduces undefined symbol and uses it in pretty unusual way. I think
> it worth to add comment about it.

So I thought the subject and the not-really-signed-off made it clear
enough: I don't mean for this patch to get upstream, it was only for the
buildbot to chew on and send me a build error report if we did indeed
have any such users.

The real fix(es) I'm planning to send is in
https://github.com/Villemoes/linux/tree/4.18_bitmap-zero-fix , but I'm
still waiting for the buildbot to send a report for the fake patch.

>>  #define small_const_nbits(nbits) \
>> -   (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)
>> +   (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG && \
>> +((nbits) > 0 || const_zero_size_bitmaps_are_buggy()))
> 
> Some functions in bitmap API has signed type for nbits. (This is wrong
> by itself. I think I'll write patch for it.) 

I thought I fixed that years ago, but looking again, it seems
2fbad29917c98 failed to update bitmap_shift_right properly. There may be
other extern functions with signed nbits, but I think bitmap_shift_right
is the only inline that passes a signed nbits to small_const_nbits().
I'll include a fix in the above series.

So in fact you check here
> that nbits is not negative as well. Would it be better name like
> const_nonpositive_size_bitmaps_are_buggy?

The name of the undefined function is irrelevant per the above.

Rasmus

[PATCH] staging: rtl8188eu: Removed code valid for 5GHz

[Bhaskar Singh]

This patch removed code which are valid for IEEE 802.11a i.e. 5GHz.

This is also mention in the TODO file.

Signed-off-by: Bhaskar Singh 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 7d5cbaf50f1c..3ce20f381827 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -100,19 +100,13 @@ bool rtw_is_cckratesonly_included(u8 *rate)
 
 int rtw_check_network_type(unsigned char *rate, int ratelen, int channel)
 {
-   if (channel > 14) {
-   if (rtw_is_cckrates_included(rate))
-   return WIRELESS_INVALID;
-   else
-   return WIRELESS_11A;
-   } else {  /*  could be pure B, pure G, or B/G */
+ /*  could be pure B, pure G, or B/G */
if (rtw_is_cckratesonly_included(rate))
return WIRELESS_11B;
else if (rtw_is_cckrates_included(rate))
return  WIRELESS_11BG;
else
return WIRELESS_11G;
-   }
 }
 
 u8 *rtw_set_fixed_ie(void *pbuf, unsigned int len, void *source,
-- 
2.16.4

Re: [PATCH] Revert "kbuild: create deterministic initramfs directory listings"

[Andrzej Pietrasiewicz]

Hi Bjørn,

W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
>  wrote:
>>
>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>
>> The reverted commit introduces broken builds. Even though the cpio archive
>> does contain all the specified files, it seems that the kernel, while
>> populating rootfs, scans the cpio buffer linearly and fails to create
>> files whose parent directories are nonexistent at the moment of this failed
>> creation. As a result, such files are not accessible when kernel boots into
>> initramfs.
>>



> 
> I'm unable to reproduce it. On my system the listing is sorted so that
> it works (parent directories appear before files). I tried to run with
> LANG=C and it also sorts correctly. What is your LANG=? I think we
> better add a LANG=C somewhere in the kernel build system, because I
> think you have a LANG= that makes it sort differently. A quick fix
> would of course be to insert it right next to sort, but there may be
> other places that may break due to LANG= settings.
> 

Thanks for the tip. My LANG is pl_PL.UTF-8. Indeed, prefixing the "sort"
invocation in question with LANG=C does solve the problem. I don't feel
competent enough to say whether this is the correct place for the fix,
or if the fix should be made elsewhere. Another option is that it is the
"sort" itself that should be fixed (or the locale, or both).

Would you be able (as the author of the patch in question) to check if
there are other locales which cause the problem?

Thanks,

Andrzej

Re: [PATCH] PCI / ACPI / PM: Resume all bridges on suspend-to-RAM

[Rafael J. Wysocki]

On Fri, Aug 17, 2018 at 7:45 AM Teika Kazura  wrote:
>
> For the record, about the exactness of the patch description.
>
> The patch mentions the regression by the commit c62ec4610c40, but it is not 
> the cause of the bug (https://bugzilla.kernel.org/show_bug.cgi?id=20067)
> reported by me; I reverted c62ec4610c40 on linux-4.17.13, and the bug 
> remained.
>
> # Some details: my bug was introduced by the commit (i) 877b3729ca0 on Jan 3. 
> The commit (ii) c62ec4610c40 was on May 22. The commit (iii) 26112ddc254c
> on Jun 30 fixes one problem caused by c62ec4610c40. The present patch 
> modifies the code of the commit (iii), so it can be said as the completion of 
> the
> commit (iii). It at the same time fixes my bug, too.

You are right, commit 877b3729ca0 introduced the issue for you, but it
did that by exposing the same functional problem in the firmware that
was previously addressed by commit 26112ddc254c in a different case.

> This suggests the present patch possibly fixes other unknown PM problems; 
> former kernels had some loose end(s). Now this patch puts the kernel in a 
> better position.
>
> I'm a lay Linux user, and don't know if this post helps. If it does, it may 
> be worth mentioning it in the above bugzilla entry.

Yes, it does, thanks!

I have updated the tags and the commit log of this patch according to
the information above.

Cheers,
Rafael

[PATCH] staging: rtl8188eu: Removed unnecessary parentheses

[Bhaskar Singh]

Removed unnecessary parentheses and this resolve the check patch issue.

Structure dereference operator have higher precedence then Address of
operator So there is no need of parentheses.

This change is purely coding style in nature and should have not effect
on runtime code execution.

Signed-off-by: Bhaskar Singh 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 676d549ef786..e611eda11b5f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -36,7 +36,7 @@ void free_mlme_ap_info(struct adapter *padapter)
struct sta_priv *pstapriv = &padapter->stapriv;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
-   struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+   struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
 
pmlmepriv->update_bcn = false;
pmlmeext->bstart_bss = false;
-- 
2.16.4

Re: Built in PS2 keyboard in new ASUS/acer laptops can not wake up system after s2idle

[Rafael J. Wysocki]

On Fri, Aug 17, 2018 at 4:29 AM Daniel Drake  wrote:
>
> On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki  wrote:
> >> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get 
> >> the
> >> keyboard wake up the system as expected. We considered to work out a DMI
> >> based quirk for this. But based on the information that EC would not 
> >> signal SCI
> >> event for WiskyLake models, we'd like to know if there's any generic 
> >> solution?
> >> Maybe a 'udev' rule to identify WiskyLake NoteBook then enable the keyboard
> >> wake up?
> >
> > A udev rule sounds like a good idea to me.
>
> What would the udev rule look like though?
>
> Match for Intel CPU generation (WhiskyLake) and laptop chassis type
> and then enable i8042 wakeups? While that seems like the most accurate
> reflection of the situation which we are seeing across multiple
> vendors, it doesn't feel right and seems unlikely to be accepted by
> systemd upstream.
>
> In previous designs, pressing a key while the system was in S3 sleep
> would cause a SCI interrupt due to the firing of the EC GPE, which
> effectively meant that keyboard wakeups were on by default and could
> not be disabled. Also USB keyboards have wakeups on by default (see
> usbhid_start()). Just these new platforms have this
> unfortunate/accidental behaviour change...
>
> Would it make sense to turn i8042 wakeups on by default on the kernel
> side? I don't know if any particular conditions are applied, but that
> would appear to be the default Win10 behaviour here.

Yes, it would, but that might prevent some systems from suspending at
all in theory if there are keyboard interrupts on them occurring
during system-wide suspend, for example.

Otherwise, it would just be a matter of calling device_wakeup_enable()
at init time for the keyboard port (as long as you know which one of
them is the keyboard).

Re: [PATCH] remoteproc/davinci: Use %zx for formating size_t

[Sekhar Nori]

On Friday 17 August 2018 01:09 PM, Bartosz Golaszewski wrote:
> 2018-08-17 2:49 GMT+02:00 Bjorn Andersson :
>> da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
>> print of it to avoid a compile warning.
>>
>> Signed-off-by: Bjorn Andersson 
>> ---
>>  drivers/remoteproc/da8xx_remoteproc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/remoteproc/da8xx_remoteproc.c 
>> b/drivers/remoteproc/da8xx_remoteproc.c
>> index e230bef71be1..d200334577f6 100644
>> --- a/drivers/remoteproc/da8xx_remoteproc.c
>> +++ b/drivers/remoteproc/da8xx_remoteproc.c
>> @@ -226,7 +226,7 @@ static int da8xx_rproc_get_internal_memories(struct 
>> platform_device *pdev,
>> res->start & DA8XX_RPROC_LOCAL_ADDRESS_MASK;
>> drproc->mem[i].size = resource_size(res);
>>
>> -   dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 
>> 0x%x\n",
>> +   dev_dbg(dev, "memory %8s: bus addr %pa size 0x%zx va %p da 
>> 0x%x\n",
>> mem_names[i], &drproc->mem[i].bus_addr,
>> drproc->mem[i].size, drproc->mem[i].cpu_addr,
>> drproc->mem[i].dev_addr);
>> --
>> 2.18.0
>>
> 
> Reviewed-by: Bartosz Golaszewski 
> 
> Can you also pick up this patch[1] for v4.19? David Lechner already
> has a patch queued for v4.20 that depends on this one.

Looks like Bjorn added it to next yesterday.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b2201ee554a5811f569f31280b0079e7d6177606

Thanks,
Sekhar

Re: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver

[Jerome Brunet]

On Fri, 2018-08-17 at 14:12 +0800, Hanjie Lin wrote:
> 
> On 2018/8/16 16:33, Jerome Brunet wrote:
> > On Thu, 2018-08-16 at 11:05 +0800, Hanjie Lin wrote:
> > > 
> > > On 2018/8/14 18:41, Jerome Brunet wrote:
> > > > On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
> > > > > From: Yue Wang 
> > > > > 
> > > > > The Meson-PCIE-PHY controller supports the 5-Gbps data rate
> > > > > of the PCI Express Gen 2 specification and is backwardcompatible
> > > > > with the 2.5-Gbps Gen 1.1 specification with only
> > > > > inferred idle detection supported on AMLOGIC SoCs.
> > > > 
> > > > It looks like the sole purpose of this driver is to provide the reset 
> > > > lines to
> > > > pcie driver.
> > > > 
> > > > I wonder why we need this ? Can't the pcie driver claim the reset lines 
> > > > itself.
> > > > 
> > > > Also, an init of this phy will always reset both port. What will happen 
> > > > if the
> > > > first port is in use and the 2nd port comes up ?? 
> > > > 
> > > > Looks the the pcie driver should claim 'apb' and 'phy' reset lines as 
> > > > "shared"
> > > > reset and the required 'port' as 'exclusive'
> > > > 
> > > 
> > > Thank you for your response.
> > > 
> > > Yes, 'apb' and 'phy' reset lines are shared, and ‘port' reset line is 
> > > exclusive.
> > > If we handle all reset lines during the first port initial sequence, 
> > > and when the second port comes up, we will do nothing about the rest 
> > > lines, 
> > > and don't need a extra API to do ‘port' reset;
> > 
> > With which other driver are your control shared ?
> > 
> > Looks it is the answer is none since this phy driver will reset both port
> > already, even if one is used.
> > 
> > In this case the fact that you are using shared control is just abusing the
> > framework to reset once.
> > 
> > As far as I can tell, this driver makes no sense. The appropriate reset 
> > lines
> > should be given directly to your pcie driver. 
> > 
> > 
> > 
> > .
> > 
> 
> Amlogic AXG SOC includes two pcie controllers and pipes when only one pcie 
> phy: 
> 
> (port_a reset)
>   |PCIE_RC_A>PCIE_PIPE_A--| 
> (apb_reset)   |   |  (phy reset)
> APB BUS--->   |   |   PCIE_PHY
>   |   |
>   | (port_b_reset)|
>   |PCIE_RC_B>PCIE_PIPE_B--|
> 
> The phy_reset affect the PCIE_PHY.
> The port_a_reset affect the PCIE_PIPE_A, port_b_reset affect the PCIE_PIPE_B. 
> 
> As your suggestion we will move the 'port' reset to controller driver,
> and keeping the phy driver to process the 'apb' and 'phy' reset or any
> more changes of the phy in future.

As far as I can tell from this diagram, It would only make sense for the "phy"
reset line to be controlled by your phy driver.

The apb and port is obviously related to the pcie device/driver itself, not the
PHY. And whether you 1 or 2 reset lines in it, IMO it is overkill and
unnecessary to make a phy driver for this. 

> 

Re: [PATCH] Revert "kbuild: create deterministic initramfs directory listings"

[Masahiro Yamada]

2018-08-17 16:47 GMT+09:00 Andrzej Pietrasiewicz :
> Hi Bjørn,
>
> W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
>> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
>>  wrote:
>>>
>>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>>
>>> The reverted commit introduces broken builds. Even though the cpio archive
>>> does contain all the specified files, it seems that the kernel, while
>>> populating rootfs, scans the cpio buffer linearly and fails to create
>>> files whose parent directories are nonexistent at the moment of this failed
>>> creation. As a result, such files are not accessible when kernel boots into
>>> initramfs.
>>>
>
> 
>
>>
>> I'm unable to reproduce it. On my system the listing is sorted so that
>> it works (parent directories appear before files). I tried to run with
>> LANG=C and it also sorts correctly. What is your LANG=? I think we
>> better add a LANG=C somewhere in the kernel build system, because I
>> think you have a LANG= that makes it sort differently. A quick fix
>> would of course be to insert it right next to sort, but there may be
>> other places that may break due to LANG= settings.
>>
>
> Thanks for the tip. My LANG is pl_PL.UTF-8. Indeed, prefixing the "sort"
> invocation in question with LANG=C does solve the problem. I don't feel
> competent enough to say whether this is the correct place for the fix,
> or if the fix should be made elsewhere. Another option is that it is the
> "sort" itself that should be fixed (or the locale, or both).
>
> Would you be able (as the author of the patch in question) to check if
> there are other locales which cause the problem?
>
> Thanks,
>
> Andrzej


I cannot add LANG=C to the high-level of the build system at least
since it would break the localization.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v1 5/5] mm/memory_hotplug: print only with DEBUG_VM in online/offline_pages()

[Oscar Salvador]

>  failed_addition:
> +#ifdef CONFIG_DEBUG_VM
>   pr_debug("online_pages [mem %#010llx-%#010llx] failed\n",
>(unsigned long long) pfn << PAGE_SHIFT,
>(((unsigned long long) pfn + nr_pages) << PAGE_SHIFT) - 1);
> +#endif

I have never been sure about this.
IMO, if I fail to online pages, I want to know I failed.
I think that pr_err would be better than pr_debug and without CONFIG_DEBUG_VM.

But at least, if not, envolve it with a CONFIG_DEBUG_VM, but change pr_debug to 
pr_info.

> +#ifdef CONFIG_DEBUG_VM
>   pr_debug("memory offlining [mem %#010llx-%#010llx] failed\n",
>(unsigned long long) start_pfn << PAGE_SHIFT,
>((unsigned long long) end_pfn << PAGE_SHIFT) - 1);
> +#endif

Same goes here.

Thanks
-- 
Oscar Salvador
SUSE L3

Re: [RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

[Marta Rybczynska]

- On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt 
b...@kernel.crashing.org wrote:

> This protects enable/disable operations using the state mutex to
> avoid races with, for example, concurrent enables on a bridge.
> 
> The bus hierarchy is walked first before taking the lock to
> avoid lock nesting (though it would be ok if we ensured that
> we always nest them bottom-up, it is better to just avoid the
> issue alltogether, especially as we might find cases where
> we want to take it top-down later).
> 
> Signed-off-by: Benjamin Herrenschmidt 


> 
> static void pci_enable_bridge(struct pci_dev *dev)
> {
>   struct pci_dev *bridge;
> - int retval;
> + int retval, enabled;
> 
>   bridge = pci_upstream_bridge(dev);
>   if (bridge)
>   pci_enable_bridge(bridge);
> 
> - if (pci_is_enabled(dev)) {
> - if (!dev->is_busmaster)
> - pci_set_master(dev);
> + /* Already enabled ? */
> + pci_dev_state_lock(dev);
> + enabled = pci_is_enabled(dev);
> + if (enabled && !dev->is_busmaster)
> + pci_set_master(dev);
> + pci_dev_state_unlock(dev);
> + if (enabled)
>   return;
> - }
> 

This looks complicated too me especially with the double locking. What do you
think about a function doing that check that used an unlocked version of
pcie_set_master?

Like:

dev_state_lock(dev);
enabled = pci_is_enabled(dev);
if (enabled &&  !dev->is_busmaster)
pci_set_master_unlocked();
pci_dev_state_unlock(dev);

BTW If I remember correctly the code today can set bus mastering multiple
times without checking if already done.

Marta

Re: [PATCH v2] console: Add console=auto option

[Petr Mladek]

On Thu 2018-08-16 13:39:01, Prarit Bhargava wrote:
> ACPI may contain an SPCR table that defines a default system console.
> On ARM if the table is present then the SPCR console is enabled by default.
> On x86 the SPCR console is used if 'earlycon' (no parameters) is
> specified as a kernel parameter and is used only as the early console.
> To use the SPCR data as a console a user must boot with 'earlycon',
> grep logs & specify a console= kernel parameter, and then reboot again.
> 
> Add 'console=auto' that enables a firmware or hardware console, and on
> x86 enable the SPCR console if 'console=auto' is specified.

I basically like the idea. Just one or two nits below.


> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index a32f2a126791..dd057224f33b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -635,6 +635,7 @@
>  
>   hvc  Use the hypervisor console device . This is for
>   both Xen and PowerPC hypervisors.
> + auto[X86] Enable ACPI SPCR console

The "auto" option sounds reasonable. But earlycon does exactly this
when used without no extra options. I prefer to stay consistent
with the existing earlycon behavior.


>   If the device connected to the port is not a TTY but a braille
>   device, prepend "brl," before the device type, for instance
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 3b20607d581b..fb2616ba3b21 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -1771,3 +1771,8 @@ void __init arch_reserve_mem_area(acpi_physical_address 
> addr, size_t size)
>   e820__range_add(addr, size, E820_TYPE_ACPI);
>   e820__update_table_print();
>  }
> +
> +void __init arch_console_setup(void)
> +{
> + acpi_parse_spcr(false, true);

Just for record. I was curious that this might be called twice
(also from acpi_boot_init(). But it looks safe after all.

The trick is in the two bool parameters. One call allows to
register/enable earlycon and ignores normal console. This other
call does exactly the opposite. I do not see any unwanted side
effects.

Best Regards,
Petr

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

[David Howells]

James Bottomley  wrote:

> > > As a step by step process, I agree.  However, I think we can
> > > automate it to the point where you install a package and it says
> > > "insert your yubikey" every time you upgrade the kernel
> > 
> > That's a very bad idea.  You train people to unlock their private key
> > on request.  It can be abused like one of those emails that tells you
> > that your account has been suspended - just follow the link and put
> > in your password please.
> 
> It's exactly the same process those of us who use yubikeys for gpg or
> ssh keys follow.  You insert your key, you activate the process that
> needs the key, it asks for you to confirm your key, you press the
> button and the operation gets performed.  Since it's what we as kernel
> developers do, I don't see why it's a bad idea for others.

You've completely missed the point.

You need to think from the PoV of an ordinary user.  Imagine the system does
an automatic upgrade and wants to upgrade the kernel.  It pops up a dialogue
box saying "please put in your yubikey and enter your password here"[**].  It
might do this on a regular basis - and you can be sure that some users at
least will become accustomed to just doing this when their computer tells them
too.  *That* is the problem.

Now they follow a link to a dodgy website that causes some code to be
downloaded and run.  *It* now pops up a dialogue box that looks exactly like
the kernel installer's dialogue that says "please put in your yubikey and
enter your password here".  But now we've trained those users to do this on
demand...

PEBKAC[*].

[*] Note that I'm not trying to slight ordinary users here, it's more a fact
of psychology.  As a distribution, it's our responsibility to try and
protect them as best we can - and training them to unthinkingly bypass the
security mechanisms isn't in anyone's best interests.

[**] Note also that I've never actually used a yubikey[***], so I'm not sure
 whether it takes a password or has some other mechanism to unlock the
 key.

[***] We also don't want to require that someone buys and keeps track of a
  yubikey to be able to use, say, the NVidia driver with Fedora/RHEL.
  Using the TPM if installed would be preferable because it's harder to
  lose.

We also don't necessarily want to encourage ordinary users to fiddle with the
system key databases unless they really know what they are doing.  There've
been cases where doing this has bricked a machine because the BIOS is buggy.
Now I will grant, since you'll probably raise it if I don't;-), that this
might be a good reason *for* having our own third party signing key as we
could then build the key into our kernels.

But if they use a yubikey, they have to get the public key from there into the
system key list or possibly the yubikey has to be accessed by the bootloader.
The same for the TPM.

> > Further, you expose the unlocked key on a machine that might be
> > compromised.
> 
> No it doesn't; the point about using a yubikey (or any other HSM type
> thing) is that the key is shielded inside the module so you get a
> signature back and the key can't be compromised even if the machine is.

Yes, you do.  Note that I don't mean necessarily exposing the actual key
material, but you do have to make it available for use - which means someone
can then use it and there's a window in which it is available for that use.
If there wasn't, it would be useless.

> > No, you can't.  You might *think* that it is, but the signature
> > you're checking is after the image has being fiddled with by the key-
> > adder
> 
> Well, yes, you have to add a new signature to the combination. 
> However, you can always verify that the hash without the added key is
> the hash of the Red Hat supplied bzImage.

At what point would you do this?  You have to assume that your userspace tools
can be compromised unless they are also verified (signature/IMA).  No, this
needs to be done by the bootloader.

Sometimes I feel I've spent too much time talking to people about security and
their paranoia is rubbing off... ;-)

David

Re: [PATCH 1/1] tap: comment fix

[Wang Jian]

Thanks for the reminder.
Because this change is trivial, I change the subject.
On Fri, Aug 17, 2018 at 12:29 PM Jason Wang  wrote:
>
>
>
> On 2018年08月17日 03:30, David Miller wrote:
> > From: Wang Jian 
> > Date: Thu, 16 Aug 2018 21:01:27 +0800
> >
> >> The tap_queue and the "tap_dev" are loosely coupled, not "macvlan_dev".
> >>
> >> And I also change one rcu_read_lock's place, seems can reduce rcu
> >> critical section a little.
> >>
> >> Signed-off-by: Wang Jian 
> > This patch was corrupted by your email client, for example it turned
> > TAB characters into sequences of spaces.
> >
> > Please fix this, email a test patch to yourself, and do not resend the
> > patch to this mailing list until you can successfully extract and
> > cleanly apply the test patch you email to yourself.
> >
> > Thank you.
>
> Besides this, please split it into two patches. The RCU change does not
> belong to "comment fix" for sure.
>
> Thanks
>


-- 
Regards,
Wang Jian

Re: [RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

[Benjamin Herrenschmidt]

On Fri, 2018-08-17 at 10:09 +0200, Marta Rybczynska wrote:
> 
> - On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt 
> b...@kernel.crashing.org wrote:
> 
> > This protects enable/disable operations using the state mutex to
> > avoid races with, for example, concurrent enables on a bridge.
> > 
> > The bus hierarchy is walked first before taking the lock to
> > avoid lock nesting (though it would be ok if we ensured that
> > we always nest them bottom-up, it is better to just avoid the
> > issue alltogether, especially as we might find cases where
> > we want to take it top-down later).
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> 
> 
> > 
> > static void pci_enable_bridge(struct pci_dev *dev)
> > {
> > struct pci_dev *bridge;
> > -   int retval;
> > +   int retval, enabled;
> > 
> > bridge = pci_upstream_bridge(dev);
> > if (bridge)
> > pci_enable_bridge(bridge);
> > 
> > -   if (pci_is_enabled(dev)) {
> > -   if (!dev->is_busmaster)
> > -   pci_set_master(dev);
> > +   /* Already enabled ? */
> > +   pci_dev_state_lock(dev);
> > +   enabled = pci_is_enabled(dev);
> > +   if (enabled && !dev->is_busmaster)
> > +   pci_set_master(dev);
> > +   pci_dev_state_unlock(dev);
> > +   if (enabled)
> > return;
> > -   }
> > 
> 
> This looks complicated too me especially with the double locking. What do you
> think about a function doing that check that used an unlocked version of
> pcie_set_master?
> 
> Like:
> 
> dev_state_lock(dev);
> enabled = pci_is_enabled(dev);
> if (enabled &&  !dev->is_busmaster)
> pci_set_master_unlocked();
> pci_dev_state_unlock(dev);
> 
> BTW If I remember correctly the code today can set bus mastering multiple
> times without checking if already done.

I don't mind but I tend to dislike all those _unlocked() suffixes, I
suppose my generation is typing adverse enough that we call these
__something instead :)

As for setting multiple times, yes pci_set_master() doesn't check but
look at the "-" hunks of my patch, I'm not changing the existing test
here. Not that it matters much, it's an optimization.

In fact my original version just completely removed the whole lot
and just unconditionally did pci_enable_device() + pci_set_master(),
just ignoring the existing state :-)

But I decided to keep the patch functionally equivalent so I added it
back.

Cheers,
Ben.

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Paolo Bonzini]

On 16/08/2018 02:15, Stephen Rothwell wrote:
>>  -#define ARM64_HAS_STAGE2_FWB   31
>>  +#define ARM64_MISMATCHED_CACHE_TYPE31
>> ++#define ARM64_HAS_STAGE2_FWB   32
>>   
>> --#define ARM64_NCAPS32
>> ++#define ARM64_NCAPS33
>>   
>>   #endif /* __ASM_CPUCAPS_H */
> This is now a conflict between Linus' tree and the kvm-arm tree (and
> presumably soon the kvm tree).

This should have been sorted out using topic branches.  I'll handle it
myself by splitting the pull request in two, but please try to organize
better the changes in non-KVM-specific arch/arm and arch/arm64 files.

Thanks,

Paolo



signature.asc
Description: OpenPGP digital signature

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

[Vegard Nossum]

On 16 August 2018 at 17:42, Richard Weinberger
 wrote:
> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek  wrote:
>>
>> Hi Linus,
>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>>
>> Then I saw Linux v4.18.1 which includes all the above stuff.
>>
>> I tried to 'git cherry-pick -m 1 958f338e96f874a0d29442396d6adf9c1e17aa2d'.
>> I know the commit-id is the hash of a merge.
>> Luckily, I could get the "diff" and applied it.
>> But the history misses.
>>
>> How can I get the history and subjects of all commits in your tree to
>> cherry-pick the single commits?
>>
>> Do you happen to know another solution to get easily all L1TF commits
>> with any other tricks?
>
> That should help:
> git log --oneline
> 958f338e96f874a0d29442396d6adf9c1e17aa2d^..958f338e96f874a0d29442396d6adf9c1e17aa2d

Hey,

As a shorthand for this, you can also use just:

git log --oneline 958f338e96f87^-

The syntax was made especially so that you can see all the commits
that arrived via a merge commit without having to write the rev of the
merge twice but is otherwise exactly equivalent to "rev^..rev".

It should work from git v2.13. Just a tip :-)


Vegard

[PATCH] arm64: kasan: add interceptors for strcmp/strncmp functions

[Kyeongdon Kim]

This patch declares strcmp/strncmp as weak symbols.
(2 of them are the most used string operations)

Original functions declared as weak symbols and
strong ones in mm/kasan/kasan.c could replace them.

Assembly optimized strcmp/strncmp functions cannot detect KASan bug.
But, now we can detect them.

==
BUG: KASAN: use-after-free in platform_match+0x1c/0x5c at addr ffc0ad313500
Read of size 1 by task swapper/0/1
CPU: 3 PID: 1 Comm: swapper/0 Tainted: GB   4.9.77+ #1
Hardware name: Generic (DT) based system
Call trace:
 dump_backtrace+0x0/0x2e0
 show_stack+0x14/0x1c
 dump_stack+0x88/0xb0
 kasan_object_err+0x24/0x7c
 kasan_report+0x2f0/0x484
 check_memory_region+0x20/0x14c
 strcmp+0x1c/0x5c
 platform_match+0x40/0xe4
 __driver_attach+0x40/0x130
 bus_for_each_dev+0xc4/0xe0
 driver_attach+0x30/0x3c
 bus_add_driver+0x2dc/0x328
 driver_register+0x118/0x160
 __platform_driver_register+0x7c/0x88
 alarmtimer_init+0x154/0x1e4
 do_one_initcall+0x184/0x1a4
 kernel_init_freeable+0x2ec/0x2f0
 kernel_init+0x18/0x10c
 ret_from_fork+0x10/0x50

Signed-off-by: Kyeongdon Kim 
---
 arch/arm64/include/asm/string.h |  4 
 arch/arm64/kernel/arm64ksyms.c  |  2 ++
 arch/arm64/kernel/image.h   |  2 ++
 arch/arm64/lib/strcmp.S |  3 +++
 arch/arm64/lib/strncmp.S|  3 +++
 mm/kasan/kasan.c| 15 +++
 6 files changed, 29 insertions(+)

diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h
index dd95d33..d546605 100644
--- a/arch/arm64/include/asm/string.h
+++ b/arch/arm64/include/asm/string.h
@@ -24,9 +24,11 @@ extern char *strchr(const char *, int c);
 
 #define __HAVE_ARCH_STRCMP
 extern int strcmp(const char *, const char *);
+extern int __strcmp(const char *, const char *);
 
 #define __HAVE_ARCH_STRNCMP
 extern int strncmp(const char *, const char *, __kernel_size_t);
+extern int __strncmp(const char *, const char *, __kernel_size_t);
 
 #define __HAVE_ARCH_STRLEN
 extern __kernel_size_t strlen(const char *);
@@ -67,6 +69,8 @@ void memcpy_flushcache(void *dst, const void *src, size_t 
cnt);
 #define memcpy(dst, src, len) __memcpy(dst, src, len)
 #define memmove(dst, src, len) __memmove(dst, src, len)
 #define memset(s, c, n) __memset(s, c, n)
+#define strcmp(cs, ct) __strcmp(cs, ct)
+#define strncmp(cs, ct, n) __strncmp(cs, ct, n)
 
 #ifndef __NO_FORTIFY
 #define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index d894a20..10b1164 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -50,6 +50,8 @@ EXPORT_SYMBOL(strcmp);
 EXPORT_SYMBOL(strncmp);
 EXPORT_SYMBOL(strlen);
 EXPORT_SYMBOL(strnlen);
+EXPORT_SYMBOL(__strcmp);
+EXPORT_SYMBOL(__strncmp);
 EXPORT_SYMBOL(memset);
 EXPORT_SYMBOL(memcpy);
 EXPORT_SYMBOL(memmove);
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index a820ed0..5ef7a57 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -110,6 +110,8 @@ __efistub___flush_dcache_area   = 
KALLSYMS_HIDE(__pi___flush_dcache_area);
 __efistub___memcpy = KALLSYMS_HIDE(__pi_memcpy);
 __efistub___memmove= KALLSYMS_HIDE(__pi_memmove);
 __efistub___memset = KALLSYMS_HIDE(__pi_memset);
+__efistub___strcmp = KALLSYMS_HIDE(__pi_strcmp);
+__efistub___strncmp= KALLSYMS_HIDE(__pi_strncmp);
 #endif
 
 __efistub__text= KALLSYMS_HIDE(_text);
diff --git a/arch/arm64/lib/strcmp.S b/arch/arm64/lib/strcmp.S
index 471fe61..0dffef7 100644
--- a/arch/arm64/lib/strcmp.S
+++ b/arch/arm64/lib/strcmp.S
@@ -60,6 +60,8 @@ tmp3  .reqx9
 zeroones   .reqx10
 pos.reqx11
 
+.weak strcmp
+ENTRY(__strcmp)
 ENTRY(strcmp)
eor tmp1, src1, src2
mov zeroones, #REP8_01
@@ -232,3 +234,4 @@ CPU_BE( orr syndrome, diff, has_nul )
sub result, data1, data2, lsr #56
ret
 ENDPIPROC(strcmp)
+ENDPROC(__strcmp)
diff --git a/arch/arm64/lib/strncmp.S b/arch/arm64/lib/strncmp.S
index e267044..b2648c7 100644
--- a/arch/arm64/lib/strncmp.S
+++ b/arch/arm64/lib/strncmp.S
@@ -64,6 +64,8 @@ limit_wd  .reqx13
 mask   .reqx14
 endloop.reqx15
 
+.weak strncmp
+ENTRY(__strncmp)
 ENTRY(strncmp)
cbz limit, .Lret0
eor tmp1, src1, src2
@@ -308,3 +310,4 @@ CPU_BE( orr syndrome, diff, has_nul )
mov result, #0
ret
 ENDPIPROC(strncmp)
+ENDPROC(__strncmp)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index c3bd520..eae43e6 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -304,7 +304,22 @@ void *memcpy(void *dest, const void *src, size_t len)
 
return __memcpy(dest, src, len);
 }
+#undef strcmp
+int strcmp(const char *cs, const char *ct)
+{
+   check_memory_region((unsigned long)cs, 1, false, _RET_IP_);
+   check_me

Re: [PATCH v9 09/22] s390: vfio-ap: register matrix device with VFIO mdev framework

[Cornelia Huck]

On Thu, 16 Aug 2018 12:24:16 -0400
Tony Krowiak  wrote:

> On 08/14/2018 07:19 AM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:06 -0400
> > Tony Krowiak  wrote:

> >> +static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device 
> >> *mdev)
> >> +{
> >> +  struct ap_matrix_mdev *matrix_mdev;
> >> +
> >> +  matrix_mdev = kzalloc(sizeof(*matrix_mdev), GFP_KERNEL);
> >> +  if (!matrix_mdev)
> >> +  return -ENOMEM;
> >> +
> >> +  matrix_mdev->name = dev_name(mdev_dev(mdev));
> >> +  vfio_ap_matrix_init(&matrix_dev.info, &matrix_mdev->matrix);
> >> +  mdev_set_drvdata(mdev, matrix_mdev);
> >> +
> >> +  if (atomic_dec_if_positive(&matrix_dev.available_instances) < 0) {
> >> +  kfree(matrix_mdev);
> >> +  return -EPERM;
> >> +  }  
> > Maybe move this check to the top of the function?  
> 
> Please ignore my previous response to your comment. I can't move the call to
> atomic_dec_if_positive() to the top of the function because it 
> decrements the
> available_instances and if the kzalloc() of matrix_mdev fails, then the 
> value
> would have to then be incremented to remain valid. What I can do is this:
> 
> 1. Check the value of available_instances using atomic_read() at the top of
> the function and if it is zero, return an error.
> 
> 2. Replace the call to atomic_dec_if_positive() with a call to atomic_dec()
> to decrement the available_instances.
> 
> I agree that it makes sense to return before attempting to allocate the
> matrix_mdev if available_instances is zero.

Wouldn't that be racy, though?

I don't think re-incrementing the counter is too bad, and it's
certainly better than going through allocation/freeing of structures.

> 
> >  
> >> +
> >> +  mutex_lock(&matrix_dev.lock);
> >> +  list_add(&matrix_mdev->list, &matrix_dev.mdev_list);
> >> +  mutex_unlock(&matrix_dev.lock);
> >> +
> >> +  return 0;
> >> +}  
> 
> 

Re: [PATCH v2] kdb: kdb_main: refactor code in kdb_md_line

[Daniel Thompson]

On Thu, Aug 16, 2018 at 09:01:41AM -0500, Gustavo A. R. Silva wrote:
> Replace the whole switch statement with a for loop.
> This makes the code much clear and easy to read.
> 
> This also addresses the following Coverity warnings:
> 
> Addresses-Coverity-ID: 115090 ("Missing break in switch")
> Addresses-Coverity-ID: 115091 ("Missing break in switch")
> Addresses-Coverity-ID: 114700 ("Missing break in switch")
> 
> Suggested-by: Daniel Thompson 
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Daniel Thompson 

> ---
> Changes in v2:
>  - Add new variable j and use it for the for loop.
> 
>  kernel/debug/kdb/kdb_main.c | 21 +++--
>  1 file changed, 3 insertions(+), 18 deletions(-)
> 
> diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
> index 2ddfce8..a9ad288 100644
> --- a/kernel/debug/kdb/kdb_main.c
> +++ b/kernel/debug/kdb/kdb_main.c
> @@ -1493,6 +1493,7 @@ static void kdb_md_line(const char *fmtstr, unsigned 
> long addr,
>   char cbuf[32];
>   char *c = cbuf;
>   int i;
> + int j;
>   unsigned long word;
>  
>   memset(cbuf, '\0', sizeof(cbuf));
> @@ -1538,25 +1539,9 @@ static void kdb_md_line(const char *fmtstr, unsigned 
> long addr,
>   wc.word = word;
>  #define printable_char(c) \
>   ({unsigned char __c = c; isascii(__c) && isprint(__c) ? __c : '.'; })
> - switch (bytesperword) {
> - case 8:
> + for (j = 0; j < bytesperword; j++)
>   *c++ = printable_char(*cp++);
> - *c++ = printable_char(*cp++);
> - *c++ = printable_char(*cp++);
> - *c++ = printable_char(*cp++);
> - addr += 4;
> - case 4:
> - *c++ = printable_char(*cp++);
> - *c++ = printable_char(*cp++);
> - addr += 2;
> - case 2:
> - *c++ = printable_char(*cp++);
> - addr++;
> - case 1:
> - *c++ = printable_char(*cp++);
> - addr++;
> - break;
> - }
> + addr += bytesperword;
>  #undef printable_char
>   }
>   }
> -- 
> 2.7.4
> 

Re: [RFC PATCH v2 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller

[Boris Brezillon]

Hi Yixun,

I know I said I would finish reviewing the driver, but I didn't have
time to do it, so feel free to send a new version addressing the
comments I already made.

On Thu, 19 Jul 2018 17:46:12 +0800
Yixun Lan  wrote:


> +static void meson_nfc_select_chip(struct mtd_info *mtd, int chip)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> +
> + if (chip < 0 || chip > MAX_CE_NUM)

^ chip > meson_chip->nsels)

> + return;
> +
> + nfc->param.chip_select = meson_chip->sels[chip] ? NAND_CE1 : NAND_CE0;
> + nfc->param.rb_select = nfc->param.chip_select;
> +}
> +

Regards,

Boris

Re: how to fix acpi_pci_root_remap_iospace?

[Arnd Bergmann]

On Fri, Aug 17, 2018 at 1:27 AM Luck, Tony  wrote:
>
> On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:
> > Another way would be to add
> >
> >  #include 
> > +#undef PCI_IOBASE
> >
> > in your asm/io.h. This is about as ugly as the your version, but
> > it would be local to ia64 ;-)
>
> Third way ...
>
>
> Is "0" actually the right value for PCI_IOBASE for some platform?
>
> #ifndef PCI_IOBASE
> #define PCI_IOBASE ((void __iomem *)0)
> #endif
>
> Or is this just here to make sure that:
>
> static inline u8 inb(unsigned long addr)
> {
> u8 val;
>
> __io_pbr();
> val = __raw_readb(PCI_IOBASE + addr);
> __io_par();
> return val;
> }
>
> etc. Do not throw errors?

Defining it to zero is the traditional approach on some systems, and it's used
for at least two different reasons, both of which I don't particularly like:

- Some (particularly older) targets that have its I/O space mapped
into its linear
  virtual memory define inb() to be effectively an alias for readb() with the
  same numeric arguments. This kind of works in most cases but breaks in
  many corner cases such as
  * user space using /dev/ioport, which now grants access to all of
kernel memory
  * ISA device drivers using fixed 16-bit addresses on inb/outb, which
now points
into user space memory
  * drivers that get the correct address from a resource but then truncate it by
storing it in a 16-bit or 32-bit (on 64-bit machines) local variable.

- Some targets don't have any support for I/O space on their PCI bus and just
   want to get things to compile by setting PCI_IOBASE to zero, this still opens
up some of the same problems as above, but doesn't really help otherwise.

> Should we really just enclose all of inb, inw, inl, ...
> inside of:
>
> #ifdef PCI_IOBASE
>
> ... all those static functions that use PCI_IOBASE ...

This breaks compilation of a couple of important drivers such as serial-8250
which support either I/O or memory space, so it requires some cleanup
first, or the definition of an alternative nop inb/outb family that does not
try to access the bus.

   Arnd

Re: Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

[Sedat Dilek]

On Fri, Aug 17, 2018 at 10:33 AM, Vegard Nossum  wrote:
> On 16 August 2018 at 17:42, Richard Weinberger
>  wrote:
>> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek  wrote:
>>>
>>> Hi Linus,
>>>
>>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>>> Unfortunately, this is no more available in the tip Git-tree.
>>>
>>> Then I saw Linux v4.18.1 which includes all the above stuff.
>>>
>>> I tried to 'git cherry-pick -m 1 958f338e96f874a0d29442396d6adf9c1e17aa2d'.
>>> I know the commit-id is the hash of a merge.
>>> Luckily, I could get the "diff" and applied it.
>>> But the history misses.
>>>
>>> How can I get the history and subjects of all commits in your tree to
>>> cherry-pick the single commits?
>>>
>>> Do you happen to know another solution to get easily all L1TF commits
>>> with any other tricks?
>>
>> That should help:
>> git log --oneline
>> 958f338e96f874a0d29442396d6adf9c1e17aa2d^..958f338e96f874a0d29442396d6adf9c1e17aa2d
>
> Hey,
>
> As a shorthand for this, you can also use just:
>
> git log --oneline 958f338e96f87^-
>
> The syntax was made especially so that you can see all the commits
> that arrived via a merge commit without having to write the rev of the
> merge twice but is otherwise exactly equivalent to "rev^..rev".
>
> It should work from git v2.13. Just a tip :-)
>

Cool. I have here git v2.18.
Finally, I found --no-pager and the place to put in my git-line.

sdi@iniza:~/src/linux-kernel/linux$ git --no-pager log --oneline
--no-merges 958f338e96f87^-
07d981ad4cf1 x86/microcode: Allow late microcode loading with SMT disabled
e24f14b0ff98 tools headers: Synchronise x86 cpufeatures.h for L1TF additions
1063711b5739 x86/mm/kmmio: Make the tracer robust against L1TF
958f79b9ee55 x86/mm/pat: Make set_memory_np() L1TF safe
0768f91530ff x86/speculation/l1tf: Make pmd/pud_mknotpresent() invert
f22cc87f6c1f x86/speculation/l1tf: Invert all not present mappings
bc2d8d262cba cpu/hotplug: Fix SMT supported evaluation
5b76a3cff011 KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry
8e0b2b916662 x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on vmentry
ea156d192f52 x86/speculation: Simplify sysfs report of VMX L1TF vulnerability
583311361369 Documentation/l1tf: Remove Yonah processors from not
vulnerable list
18b57ce2eb8c x86/KVM/VMX: Don't set l1tf_flush_l1d from
vmx_handle_external_intr()
ffcba43ff66c x86/irq: Let interrupt handlers set kvm_cpu_l1tf_flush_l1d
447ae3166702 x86: Don't include linux/irq.h from asm/hardirq.h
45b575c00d8e x86/KVM/VMX: Introduce per-host-cpu analogue of l1tf_flush_l1d
9aee5f8a7e30 x86/irq: Demote irq_cpustat_t::__softirq_pending to u16
5b6ccc6c3b1a x86/KVM/VMX: Move the l1tf_flush_l1d test to vmx_l1d_flush()
427362a14244 x86/KVM/VMX: Replace 'vmx_l1d_flush_always' with
'vmx_l1d_flush_cond'
379fd0c7e6a3 x86/KVM/VMX: Don't set l1tf_flush_l1d to true from vmx_l1d_flush()
73d5e2b47264 cpu/hotplug: detect SMT disabled by BIOS
1949f9f49792 Documentation/l1tf: Fix typos
288d152c23dc x86/KVM/VMX: Initialize the vmx_l1d_flush_pages' content
6c26fcd2abfe x86/speculation/l1tf: Unbreak
!__HAVE_ARCH_PFN_MODIFY_ALLOWED architectures
3ec8ce5d866e Documentation: Add section about CPU vulnerabilities
d90a7a0ec83f x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
fee0aede6f47 cpu/hotplug: Set CPU_SMT_NOT_SUPPORTED early
8e1b706b6e81 cpu/hotplug: Expose SMT control init function
895ae47f9918 x86/kvm: Allow runtime control of L1D flush
dd4bfa739a72 x86/kvm: Serialize L1D flush parameter setter
4c6523ec59fe x86/kvm: Add static key for flush always
7db92e165ac8 x86/kvm: Move l1tf setup function
a7b9020b06ec x86/l1tf: Handle EPT disabled state proper
2f055947ae5e x86/kvm: Drop L1TF MSR list approach
72c6d2db64fa x86/litf: Introduce vmx status variable
215af5499d9e cpu/hotplug: Online siblings when SMT control is turned on
390d975e0c4e x86/KVM/VMX: Use MSR save list for IA32_FLUSH_CMD if required
989e3992d2ec x86/KVM/VMX: Extend add_atomic_switch_msr() to allow
VMENTER only MSRs
3190709335dd x86/KVM/VMX: Separate the VMX AUTOLOAD guest/host number accounting
ca83b4a7f2d0 x86/KVM/VMX: Add find_msr() helper function
33966dd6b2d2 x86/KVM/VMX: Split the VMX MSR LOAD structures to have an
host/guest numbers
c595ceee4570 x86/KVM/VMX: Add L1D flush logic
3fa045be4c72 x86/KVM/VMX: Add L1D MSR based flush
a47dd5f06714 x86/KVM/VMX: Add L1D flush algorithm
a399477e52c1 x86/KVM/VMX: Add module argument for L1TF mitigation
26acfb666a47 x86/KVM: Warn user if KVM is loaded SMT and L1TF CPU bug
being present
0cc3cd21657b cpu/hotplug: Boot HT siblings at least once
506a66f37489 Revert "x86/apic: Ignore secondary threads if nosmt=force"
e14d7dfb41f5 x86/speculation/l1tf: Fix up pte->pfn conversion for PAE
0d0f62490588 x86/speculation/l1tf: Protect PAE swap entries against L1TF
7ce2f0393ea2 x86/CPU/AMD: Move TOPOEXT reenablement before reading
smp_num_siblings
11e34e64e410 x86/cpufeatures: Add detection of L1D cache flush support.
1a7ed1ba4bba x86/spe

Re: how to fix acpi_pci_root_remap_iospace?

[Boris Brezillon]

On Fri, 17 Aug 2018 10:47:34 +0200
Arnd Bergmann  wrote:

> On Fri, Aug 17, 2018 at 1:27 AM Luck, Tony  wrote:
> >
> > On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:  
> > > Another way would be to add
> > >
> > >  #include 
> > > +#undef PCI_IOBASE
> > >
> > > in your asm/io.h. This is about as ugly as the your version, but
> > > it would be local to ia64 ;-)  
> >
> > Third way ...
> >
> >
> > Is "0" actually the right value for PCI_IOBASE for some platform?
> >
> > #ifndef PCI_IOBASE
> > #define PCI_IOBASE ((void __iomem *)0)
> > #endif
> >
> > Or is this just here to make sure that:
> >
> > static inline u8 inb(unsigned long addr)
> > {
> > u8 val;
> >
> > __io_pbr();
> > val = __raw_readb(PCI_IOBASE + addr);
> > __io_par();
> > return val;
> > }
> >
> > etc. Do not throw errors?  
> 
> Defining it to zero is the traditional approach on some systems, and it's used
> for at least two different reasons, both of which I don't particularly like:
> 
> - Some (particularly older) targets that have its I/O space mapped
> into its linear
>   virtual memory define inb() to be effectively an alias for readb() with the
>   same numeric arguments. This kind of works in most cases but breaks in
>   many corner cases such as
>   * user space using /dev/ioport, which now grants access to all of
> kernel memory
>   * ISA device drivers using fixed 16-bit addresses on inb/outb, which
> now points
> into user space memory
>   * drivers that get the correct address from a resource but then truncate it 
> by
> storing it in a 16-bit or 32-bit (on 64-bit machines) local variable.
> 
> - Some targets don't have any support for I/O space on their PCI bus and just
>want to get things to compile by setting PCI_IOBASE to zero, this still 
> opens
> up some of the same problems as above, but doesn't really help otherwise.
> 
> > Should we really just enclose all of inb, inw, inl, ...
> > inside of:
> >
> > #ifdef PCI_IOBASE
> >
> > ... all those static functions that use PCI_IOBASE ...  
> 
> This breaks compilation of a couple of important drivers such as serial-8250
> which support either I/O or memory space, so it requires some cleanup
> first, or the definition of an alternative nop inb/outb family that does not
> try to access the bus.

Hm, maybe it's just easier to revert the patch since we got rid of
patches adding COMPILE_TEST to drivers which were using read/writesl()
(it turned out ia64 and sparc were not the only archs to not implement
readsx/writesx() variants, and fixing them is not that easy).

Re: [RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

[Hari Vyas]

On Fri, Aug 17, 2018 at 2:00 PM, Benjamin Herrenschmidt
 wrote:
> On Fri, 2018-08-17 at 10:09 +0200, Marta Rybczynska wrote:
>>
>> - On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt 
>> b...@kernel.crashing.org wrote:
>>
>> > This protects enable/disable operations using the state mutex to
>> > avoid races with, for example, concurrent enables on a bridge.
>> >
>> > The bus hierarchy is walked first before taking the lock to
>> > avoid lock nesting (though it would be ok if we ensured that
>> > we always nest them bottom-up, it is better to just avoid the
>> > issue alltogether, especially as we might find cases where
>> > we want to take it top-down later).
>> >
>> > Signed-off-by: Benjamin Herrenschmidt 
>>
>>
>> >
>> > static void pci_enable_bridge(struct pci_dev *dev)
>> > {
>> > struct pci_dev *bridge;
>> > -   int retval;
>> > +   int retval, enabled;
>> >
>> > bridge = pci_upstream_bridge(dev);
>> > if (bridge)
>> > pci_enable_bridge(bridge);
>> >
>> > -   if (pci_is_enabled(dev)) {
>> > -   if (!dev->is_busmaster)
>> > -   pci_set_master(dev);
>> > +   /* Already enabled ? */
>> > +   pci_dev_state_lock(dev);
>> > +   enabled = pci_is_enabled(dev);
>> > +   if (enabled && !dev->is_busmaster)
>> > +   pci_set_master(dev);
>> > +   pci_dev_state_unlock(dev);
>> > +   if (enabled)
>> > return;
>> > -   }
>> >
>>
>> This looks complicated too me especially with the double locking. What do you
>> think about a function doing that check that used an unlocked version of
>> pcie_set_master?
>>
>> Like:
>>
>> dev_state_lock(dev);
>> enabled = pci_is_enabled(dev);
>> if (enabled &&  !dev->is_busmaster)
>> pci_set_master_unlocked();
>> pci_dev_state_unlock(dev);
>>
>> BTW If I remember correctly the code today can set bus mastering multiple
>> times without checking if already done.
>
> I don't mind but I tend to dislike all those _unlocked() suffixes, I
> suppose my generation is typing adverse enough that we call these
> __something instead :)
>
> As for setting multiple times, yes pci_set_master() doesn't check but
> look at the "-" hunks of my patch, I'm not changing the existing test
> here. Not that it matters much, it's an optimization.
>
> In fact my original version just completely removed the whole lot
> and just unconditionally did pci_enable_device() + pci_set_master(),
> just ignoring the existing state :-)
>
> But I decided to keep the patch functionally equivalent so I added it
> back.
>
> Cheers,
> Ben.
>
>
So many mail threads for common issues going so just trying to
summarize concern from my side.
1) HW level
PCI Config data overwritten (ex: PCI_COMMAND bits etc) was happening
at lower layer so from my
perspective, it is best to handle concern at lower level with locking
mechanism and that is what
I proposed in my upcoming patch. Without that, I guess, we may end up
in issues later with some weird scenario
which may not be known today  and we will again be fine tuning stuff
here and there.
2) SW level(internal data structure):
About is_added,is_busmaster: These all are bit fields so infact I too
suggested to remove those bit fields and
make separate variables in pci_dev structure. This will avoid all
data-overwritten,concurrency issues but ofcourse
at the level of space cost.
Other possibility will be either to use atomic or locking mechanism
for these. My point here is also same, better
avoid fine tuning later stage.
Moving is_added up and down doesn't look like good as we are just
shifting issue up and down.

Please check and decide accordingly. I will hold my to-be-submitted
modify() patch about handling hw level
over-written case with locking around read-write operation.

Regards,
hari

[PATCH v4 0/4] Refactoring for remove_memory_section/unregister_mem_sect_under_nodes

[Oscar Salvador]

From: Oscar Salvador 

v3 -> v4:
- Make nodemask_t a stack variable
- Added Reviewed-by from David and Pavel

v2 -> v3:
- NODEMASK_FREE can deal with NULL pointers, so do not
  make it conditional (by David).
- Split up node_online's check patch (David's suggestion)
- Added Reviewed-by from Andrew and David
- Fix checkpath.pl warnings

This patchset does some cleanups and refactoring in the memory-hotplug code.

The first and the second patch are pretty straightforward, as they
only remove unused arguments/checks.

The third patch refactors unregister_mem_sect_under_nodes a bit by re-defining
nodemask_t as a stack variable. (More details in Patch3's changelog)

The fourth patch removes a node_online check. (More details in Patch4's 
changelog)
Since this change has a patch for itself, we could quickly revert it
if we notice that something is wrong with it, or drop it if people
are concerned about it.

Oscar Salvador (4):
  mm/memory-hotplug: Drop unused args from remove_memory_section
  mm/memory_hotplug: Drop mem_blk check from
unregister_mem_sect_under_nodes
  mm/memory_hotplug: Define nodemask_t as a stack variable
  mm/memory_hotplug: Drop node_online check in
unregister_mem_sect_under_nodes

 drivers/base/memory.c |  5 ++---
 drivers/base/node.c   | 22 ++
 include/linux/node.h  |  5 ++---
 3 files changed, 10 insertions(+), 22 deletions(-)

-- 
2.13.6

[PATCH v4 1/4] mm/memory-hotplug: Drop unused args from remove_memory_section

[Oscar Salvador]

From: Oscar Salvador 

unregister_memory_section() calls remove_memory_section()
with three arguments:

* node_id
* section
* phys_device

Neither node_id nor phys_device are used.
Let us drop them from the function.

Signed-off-by: Oscar Salvador 
Reviewed-by: David Hildenbrand 
Reviewed-by: Andrew Morton 
Reviewed-by: Pavel Tatashin 
---
 drivers/base/memory.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index c8a1cb0b6136..2c622a9a7490 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -752,8 +752,7 @@ unregister_memory(struct memory_block *memory)
device_unregister(&memory->dev);
 }
 
-static int remove_memory_section(unsigned long node_id,
-  struct mem_section *section, int phys_device)
+static int remove_memory_section(struct mem_section *section)
 {
struct memory_block *mem;
 
@@ -785,7 +784,7 @@ int unregister_memory_section(struct mem_section *section)
if (!present_section(section))
return -EINVAL;
 
-   return remove_memory_section(0, section, 0);
+   return remove_memory_section(section);
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
 
-- 
2.13.6

[PATCH v4 3/4] mm/memory_hotplug: Define nodemask_t as a stack variable

[Oscar Salvador]

From: Oscar Salvador 

Currently, unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
in order to check whithin the loop which nodes have already been unlinked,
so we do not repeat the operation on them.

NODEMASK_ALLOC calls kmalloc() if NODES_SHIFT > 8, otherwise
it just declares a nodemask_t variable whithin the stack.

Since kmalloc() can fail, we actually check whether NODEMASK_ALLOC failed
or not, and we return -ENOMEM accordingly.
remove_memory_section() does not check for the return value though.
It is pretty rare that such a tiny allocation can fail, but if it does,
we will be left with dangled symlinks under /sys/devices/system/node/,
since the mem_blk's directories will be removed no matter what
unregister_mem_sect_under_nodes() returns.

One way to solve this is to check whether unlinked_nodes is NULL or not.
In the case it is not, we can just use it as before, but if it is NULL,
we can just skip the node_test_and_set check, and call sysfs_remove_link()
unconditionally.
This is harmless as sysfs_remove_link() backs off somewhere down the chain
in case the link has already been removed.
This method was presented in v3 of the path [1].

But since the maximum number of nodes we can have is 1024,
when NODES_SHIFT = 10, that gives us a nodemask_t of 128 bytes.
Although everything depends on how deep the stack is, I think we can afford
to define the nodemask_t variable whithin the stack.

That simplifies the code, and we do not need to worry about untested error
code paths.

If we see that this causes troubles with the stack, we can always return to [1].

[1] https://patchwork.kernel.org/patch/10566673/

Signed-off-by: Oscar Salvador 
---
 drivers/base/node.c  | 16 ++--
 include/linux/node.h |  5 ++---
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index dd3bdab230b2..6b8c9b4537c9 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -449,35 +449,31 @@ int register_mem_sect_under_node(struct memory_block 
*mem_blk, void *arg)
 }
 
 /* unregister memory section under all nodes that it spans */
-int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
+void unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
unsigned long phys_index)
 {
-   NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
+   nodemask_t unlinked_nodes;
unsigned long pfn, sect_start_pfn, sect_end_pfn;
 
-   if (!unlinked_nodes)
-   return -ENOMEM;
-   nodes_clear(*unlinked_nodes);
+   nodes_clear(unlinked_nodes);
 
sect_start_pfn = section_nr_to_pfn(phys_index);
sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
-   int nid;
+   int nid = get_nid_for_pfn(pfn);
 
-   nid = get_nid_for_pfn(pfn);
if (nid < 0)
continue;
if (!node_online(nid))
continue;
-   if (node_test_and_set(nid, *unlinked_nodes))
+   if (node_test_and_set(nid, unlinked_nodes))
continue;
+
sysfs_remove_link(&node_devices[nid]->dev.kobj,
 kobject_name(&mem_blk->dev.kobj));
sysfs_remove_link(&mem_blk->dev.kobj,
 kobject_name(&node_devices[nid]->dev.kobj));
}
-   NODEMASK_FREE(unlinked_nodes);
-   return 0;
 }
 
 int link_mem_sections(int nid, unsigned long start_pfn, unsigned long end_pfn)
diff --git a/include/linux/node.h b/include/linux/node.h
index 257bb3d6d014..1203378e596a 100644
--- a/include/linux/node.h
+++ b/include/linux/node.h
@@ -72,7 +72,7 @@ extern int register_cpu_under_node(unsigned int cpu, unsigned 
int nid);
 extern int unregister_cpu_under_node(unsigned int cpu, unsigned int nid);
 extern int register_mem_sect_under_node(struct memory_block *mem_blk,
void *arg);
-extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
+extern void unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
   unsigned long phys_index);
 
 #ifdef CONFIG_HUGETLBFS
@@ -105,10 +105,9 @@ static inline int register_mem_sect_under_node(struct 
memory_block *mem_blk,
 {
return 0;
 }
-static inline int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
+static inline void unregister_mem_sect_under_nodes(struct memory_block 
*mem_blk,
  unsigned long phys_index)
 {
-   return 0;
 }
 
 static inline void register_hugetlbfs_with_node(node_registration_func_t reg,
-- 
2.13.6

[PATCH v4 4/4] mm/memory_hotplug: Drop node_online check in unregister_mem_sect_under_nodes

[Oscar Salvador]

From: Oscar Salvador 

We are getting the nid from the pages that are not yet removed,
but a node can only be offline when its memory/cpu's have been removed.
Therefore, we know that the node is still online.

Signed-off-by: Oscar Salvador 
Reviewed-by: David Hildenbrand 
Reviewed-by: Pavel Tatashin 
---
 drivers/base/node.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 6b8c9b4537c9..01e9190be010 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -464,8 +464,6 @@ void unregister_mem_sect_under_nodes(struct memory_block 
*mem_blk,
 
if (nid < 0)
continue;
-   if (!node_online(nid))
-   continue;
if (node_test_and_set(nid, unlinked_nodes))
continue;
 
-- 
2.13.6

[PATCH v4 2/4] mm/memory_hotplug: Drop mem_blk check from unregister_mem_sect_under_nodes

[Oscar Salvador]

From: Oscar Salvador 

Before calling to unregister_mem_sect_under_nodes(),
remove_memory_section() already checks if we got a valid memory_block.

No need to check that again in unregister_mem_sect_under_nodes().

If more functions start using unregister_mem_sect_under_nodes() in the
future, we can always place a WARN_ON to catch null mem_blk's so we can
safely back off.

For now, let us keep the check in remove_memory_section() since it is the
only function that uses it.

Signed-off-by: Oscar Salvador 
Reviewed-by: Andrew Morton 
Reviewed-by: Pavel Tatashin 
Reviewed-by: David Hildenbrand 
---
 drivers/base/node.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 1ac4c36e13bb..dd3bdab230b2 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -455,10 +455,6 @@ int unregister_mem_sect_under_nodes(struct memory_block 
*mem_blk,
NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
unsigned long pfn, sect_start_pfn, sect_end_pfn;
 
-   if (!mem_blk) {
-   NODEMASK_FREE(unlinked_nodes);
-   return -EFAULT;
-   }
if (!unlinked_nodes)
return -ENOMEM;
nodes_clear(*unlinked_nodes);
-- 
2.13.6

Re: [PATCH v2] eeprom: at24: Fix unexpected timeout under high load

[Bartosz Golaszewski]

2018-08-16 19:45 GMT+02:00 Mark Jonas :
> From: Wang Xin 
>
> Within at24_loop_until_timeout the timestamp used for timeout checking
> is recorded after the I2C transfer and sleep_range(). Under high CPU
> load either the execution time for I2C transfer or sleep_range() could
> actually be larger than the timeout value. Worst case the I2C transfer
> is only tried once because the loop will exit due to the timeout
> although the EEPROM is now ready.
>
> To fix this issue the timestamp is recorded at the beginning of each
> iteration. That is, before I2C transfer and sleep. Then the timeout
> is actually checked against the timestamp of the previous iteration.
> This makes sure that even if the timeout is reached, there is still one
> more chance to try the I2C transfer in case the EEPROM is ready.
>
> Example:
>
> If you have a system which combines high CPU load with repeated EEPROM
> writes you will run into the following scenario.
>
>  - System makes a successful regmap_bulk_write() to EEPROM.
>  - System wants to perform another write to EEPROM but EEPROM is still
>busy with the last write.
>  - Because of high CPU load the usleep_range() will sleep more than
>25 ms (at24_write_timeout).
>  - Within the over-long sleeping the EEPROM finished the previous write
>operation and is ready again.
>  - at24_loop_until_timeout() will detect timeout and won't try to write.
>
> Signed-off-by: Wang Xin 
> Signed-off-by: Mark Jonas 
> ---
> Changes in v2:
>  - Remove loop macro
>  - Accept superfluous sleep in case of timeout
>  - Add concrete example to commit message
> ---
>  drivers/misc/eeprom/at24.c | 43 ++-
>  1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index f5cc517..37a5c8b 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -106,23 +106,6 @@ static unsigned int at24_write_timeout = 25;
>  module_param_named(write_timeout, at24_write_timeout, uint, 0);
>  MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 
> 25)");
>
> -/*
> - * Both reads and writes fail if the previous write didn't complete yet. This
> - * macro loops a few times waiting at least long enough for one entire page
> - * write to work while making sure that at least one iteration is run before
> - * checking the break condition.
> - *
> - * It takes two parameters: a variable in which the future timeout in jiffies
> - * will be stored and a temporary variable holding the time of the last
> - * iteration of processing the request. Both should be unsigned integers
> - * holding at least 32 bits.
> - */
> -#define at24_loop_until_timeout(tout, op_time) \
> -   for (tout = jiffies + msecs_to_jiffies(at24_write_timeout), \
> -op_time = 0;   \
> -op_time ? time_before(op_time, tout) : true;   \
> -usleep_range(1000, 1500), op_time = jiffies)
> -
>  struct at24_chip_data {
> /*
>  * these fields mirror their equivalents in
> @@ -308,13 +291,22 @@ static ssize_t at24_regmap_read(struct at24_data *at24, 
> char *buf,
> /* adjust offset for mac and serial read ops */
> offset += at24->offset_adj;
>
> -   at24_loop_until_timeout(timeout, read_time) {
> +   timeout = jiffies + msecs_to_jiffies(at24_write_timeout);
> +   do {
> +   /*
> +* The timestamp shall be taken before the actual operation
> +* to avoid a premature timeout in case of high CPU load.
> +*/
> +   read_time = jiffies;
> +
> ret = regmap_bulk_read(regmap, offset, buf, count);
> dev_dbg(&client->dev, "read %zu@%d --> %d (%ld)\n",
> count, offset, ret, jiffies);
> if (!ret)
> return count;
> -   }
> +
> +   usleep_range(1000, 1500);
> +   } while (time_before(read_time, timeout));
>
> return -ETIMEDOUT;
>  }
> @@ -358,14 +350,23 @@ static ssize_t at24_regmap_write(struct at24_data 
> *at24, const char *buf,
> regmap = at24_client->regmap;
> client = at24_client->client;
> count = at24_adjust_write_count(at24, offset, count);
> +   timeout = jiffies + msecs_to_jiffies(at24_write_timeout);
> +
> +   do {
> +   /*
> +* The timestamp shall be taken before the actual operation
> +* to avoid a premature timeout in case of high CPU load.
> +*/
> +   write_time = jiffies;
>
> -   at24_loop_until_timeout(timeout, write_time) {
> ret = regmap_bulk_write(regmap, offset, buf, count);
> dev_dbg(&client->dev, "write %zu@%d --> %d (%ld)\n",
> count, offset, ret, jiffies);
> if (!ret)
>   

Re: [PATCH] media: NULL check is meaningless before debugfs_remove_recursive

[Laurent Pinchart]

Hi Zhong,

Thank you for the patch.

On Friday, 17 August 2018 06:37:26 EEST zhong jiang wrote:
> debugfs_remove_recursive has taken null pointer into account. so
> remove the unneeded check.
> 
> Signed-off-by: zhong jiang 

I already have a similar patch in my tree (git://linuxtv.org/pinchartl/
media.git uvc/next) and will include it in my pull request for v4.20.

> ---
>  drivers/media/usb/uvc/uvc_debugfs.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_debugfs.c
> b/drivers/media/usb/uvc/uvc_debugfs.c index 368f8f8..6995aeb 100644
> --- a/drivers/media/usb/uvc/uvc_debugfs.c
> +++ b/drivers/media/usb/uvc/uvc_debugfs.c
> @@ -128,6 +128,5 @@ void uvc_debugfs_init(void)
> 
>  void uvc_debugfs_cleanup(void)
>  {
> - if (uvc_debugfs_root_dir != NULL)
> - debugfs_remove_recursive(uvc_debugfs_root_dir);
> + debugfs_remove_recursive(uvc_debugfs_root_dir);
>  }

-- 
Regards,

Laurent Pinchart

Naléhavá odpověd

[Xu Shiqing]

--
Pozdravy,

Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl 
dát soukromě a já bych ocenil vaši rychlou odpověď zde 
(xu.shiq...@aol.com) pro další komunikaci.


Vyčkejte na rychlou odpověď.

Pozdravy,

[PATCH] irqchip/gic-v3: Allow interrupt to be configured as wake-up sources

[Marc Zyngier]

Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.

Let's set the required flags on the irq_chip structures.

Reported-by: Lina Iyer 
Signed-off-by: Marc Zyngier 
---
Lina, please let me know how this goes. If that fixes your issues,
I'll queue it as a fix for the current cycle.

 drivers/irqchip/irq-gic-v3.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 76ea56d779a1..2d71c79bc698 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -861,7 +861,9 @@ static struct irq_chip gic_chip = {
.irq_set_affinity   = gic_set_affinity,
.irq_get_irqchip_state  = gic_irq_get_irqchip_state,
.irq_set_irqchip_state  = gic_irq_set_irqchip_state,
-   .flags  = IRQCHIP_SET_TYPE_MASKED,
+   .flags  = IRQCHIP_SET_TYPE_MASKED |
+ IRQCHIP_SKIP_SET_WAKE |
+ IRQCHIP_MASK_ON_SUSPEND,
 };
 
 static struct irq_chip gic_eoimode1_chip = {
@@ -874,7 +876,9 @@ static struct irq_chip gic_eoimode1_chip = {
.irq_get_irqchip_state  = gic_irq_get_irqchip_state,
.irq_set_irqchip_state  = gic_irq_set_irqchip_state,
.irq_set_vcpu_affinity  = gic_irq_set_vcpu_affinity,
-   .flags  = IRQCHIP_SET_TYPE_MASKED,
+   .flags  = IRQCHIP_SET_TYPE_MASKED |
+ IRQCHIP_SKIP_SET_WAKE |
+ IRQCHIP_MASK_ON_SUSPEND,
 };
 
 #define GIC_ID_NR  (1U << gic_data.rdists.id_bits)
-- 
2.18.0

Say what the -[ cut here ]- lines are called

[Dan Jacobson]

The kernel should really say what the
[ cut here ]
lines are called, else users will say things like:

"I discovered that the user needs to use xrandr in _two_ steps for
certain resolutions, else he will trigger a
kernel:  [ cut here ] line."

instead of
"...will trigger a kernel problem."
"...will trigger a kernel fault."
"...will trigger a kernel oops."
or whatever it is supposed to be called.

So say e.g.,
[ cut here ]
Kernel fault:

etc. there in the syslog. Thanks.

Re: [PATCHv5 19/19] x86: Introduce CONFIG_X86_INTEL_MKTME

[Kirill A. Shutemov]

On Wed, Aug 15, 2018 at 09:48:12AM +0200, Pavel Machek wrote:
> Hi!
> 
> > Add new config option to enabled/disable Multi-Key Total Memory
> > Encryption support.
> > 
> > MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID
> > direct mappings for memory hotplug.
> > 
> > Signed-off-by: Kirill A. Shutemov 
> > ---
> >  arch/x86/Kconfig | 19 ++-
> >  1 file changed, 18 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index b6f1785c2176..023a22568c06 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1523,6 +1523,23 @@ config ARCH_USE_MEMREMAP_PROT
> > def_bool y
> > depends on AMD_MEM_ENCRYPT
> >  
> > +config X86_INTEL_MKTME
> > +   bool "Intel Multi-Key Total Memory Encryption"
> > +   select DYNAMIC_PHYSICAL_MASK
> > +   select PAGE_EXTENSION
> > +   depends on X86_64 && CPU_SUP_INTEL
> > +   ---help---
> > + Say yes to enable support for Multi-Key Total Memory Encryption.
> > + This requires an Intel processor that has support of the feature.
> > +
> > + Multikey Total Memory Encryption (MKTME) is a technology that allows
> > + transparent memory encryption in upcoming Intel platforms.
> > +
> > + MKTME is built on top of TME. TME allows encryption of the entirety
> > + of system memory using a single key. MKTME allows having multiple
> > + encryption domains, each having own key -- different memory pages can
> > + be encrypted with different keys.
> > +
> >  # Common NUMA Features
> >  config NUMA
> > bool "Numa Memory Allocation and Scheduler Support"
> 
> Would it be good to provide documentation, or link to documentation, 
> explaining
> what security guarantees this is supposed to provide, and what disadvantages 
> (if any)
> it has?

The main goal is to add additional level of isolation between different
tenants of a machine. It mostly targeted to VMs and protect against
leaking information between guests.

In the design kernel (or hypervisor) is trusted and have a mean to access
encrypted memory as long as key is programmed into the CPU.

Worth noting that encryption happens in memory controller so all data in
caches of all levels are plain-text.

The spec can be found here:

https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf

> I guess  it costs a bit of performance...

The most overhead is paid on allocation and freeing of encrypted pages:
switching between keyids for a page requires cache flushing.

Access time to encrypted memory *shouldn't* be measurably slower.
Encryption overhead is hidden within other latencies in memory pipeline.

> I see that TME helps with cold boot attacks.

Right.

-- 
 Kirill A. Shutemov

Re: [PATCH] irqchip/gic-v3: Allow interrupt to be configured as wake-up sources

[Sudeep Holla]

On Fri, Aug 17, 2018 at 10:18:04AM +0100, Marc Zyngier wrote:
> Although GICv3 doesn't directly offers support for wake-up interrupts
> and relies on external HW for this, it shouldn't prevent the driver
> for such HW from doing it work.
>
> Let's set the required flags on the irq_chip structures.
>

FWIW,

Reviewed-by: Sudeep Holla 

--
Regards,
Sudeep

Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Marc Zyngier]

On Fri, 17 Aug 2018 09:32:55 +0100,
Paolo Bonzini  wrote:
> 
> On 16/08/2018 02:15, Stephen Rothwell wrote:
> >>  -#define ARM64_HAS_STAGE2_FWB 31
> >>  +#define ARM64_MISMATCHED_CACHE_TYPE  31
> >> ++#define ARM64_HAS_STAGE2_FWB 32
> >>   
> >> --#define ARM64_NCAPS  32
> >> ++#define ARM64_NCAPS  33
> >>   
> >>   #endif /* __ASM_CPUCAPS_H */
> > This is now a conflict between Linus' tree and the kvm-arm tree (and
> > presumably soon the kvm tree).
> 
> This should have been sorted out using topic branches.  I'll handle it
> myself by splitting the pull request in two, but please try to organize
> better the changes in non-KVM-specific arch/arm and arch/arm64 files.

We've dealt with that kind of trivial conflicts in the past without
requiring topic branches (cpucaps.h has always been a popular place),
and I always assumed that this was acceptable. I must have
misunderstood something here.

Next time, I'll direct the architecture-specific code via the arm64
tree directly.

Thanks,

M.

-- 
Jazz is not dead, it just smell funny.

Re: [PATCH V2 1/2] blk-mq: init hctx sched after update ctx and hctx mapping

[Ming Lei]

On Fri, Aug 17, 2018 at 11:54 AM, Jianchao Wang
 wrote:
> Currently, when update nr_hw_queues, io scheduler's init_hctx will
> be invoked before the mapping between ctx and hctx is adapted
> correctly by blk_mq_map_swqueue. The io scheduler init_hctx (kyber)
> may depend on this mapping and get wrong result and panic finally.
> A simply way to fix this is switch the io scheduler to none before
> update the nr_hw_queues, and then get it back after update nr_hw_queues.
> To achieve this, we add a new member elv_type in request_queue to
> save the original elevator and adapt and export elevator_switch_mq.
> And also blk_mq_sched_init_/exit_hctx are removed due to nobody use
> them any more.
>
> Signed-off-by: Jianchao Wang 
> ---
>  block/blk-mq-sched.c   | 44 
>  block/blk-mq-sched.h   |  5 -
>  block/blk-mq.c | 36 
>  block/blk.h|  2 ++
>  block/elevator.c   | 20 
>  include/linux/blkdev.h |  3 +++
>  6 files changed, 45 insertions(+), 65 deletions(-)
>
> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> index cf9c66c..29bfe80 100644
> --- a/block/blk-mq-sched.c
> +++ b/block/blk-mq-sched.c
> @@ -462,50 +462,6 @@ static void blk_mq_sched_tags_teardown(struct 
> request_queue *q)
> blk_mq_sched_free_tags(set, hctx, i);
>  }
>
> -int blk_mq_sched_init_hctx(struct request_queue *q, struct blk_mq_hw_ctx 
> *hctx,
> -  unsigned int hctx_idx)
> -{
> -   struct elevator_queue *e = q->elevator;
> -   int ret;
> -
> -   if (!e)
> -   return 0;
> -
> -   ret = blk_mq_sched_alloc_tags(q, hctx, hctx_idx);
> -   if (ret)
> -   return ret;
> -
> -   if (e->type->ops.mq.init_hctx) {
> -   ret = e->type->ops.mq.init_hctx(hctx, hctx_idx);
> -   if (ret) {
> -   blk_mq_sched_free_tags(q->tag_set, hctx, hctx_idx);
> -   return ret;
> -   }
> -   }
> -
> -   blk_mq_debugfs_register_sched_hctx(q, hctx);
> -
> -   return 0;
> -}
> -
> -void blk_mq_sched_exit_hctx(struct request_queue *q, struct blk_mq_hw_ctx 
> *hctx,
> -   unsigned int hctx_idx)
> -{
> -   struct elevator_queue *e = q->elevator;
> -
> -   if (!e)
> -   return;
> -
> -   blk_mq_debugfs_unregister_sched_hctx(hctx);
> -
> -   if (e->type->ops.mq.exit_hctx && hctx->sched_data) {
> -   e->type->ops.mq.exit_hctx(hctx, hctx_idx);
> -   hctx->sched_data = NULL;
> -   }
> -
> -   blk_mq_sched_free_tags(q->tag_set, hctx, hctx_idx);
> -}
> -
>  int blk_mq_init_sched(struct request_queue *q, struct elevator_type *e)
>  {
> struct blk_mq_hw_ctx *hctx;
> diff --git a/block/blk-mq-sched.h b/block/blk-mq-sched.h
> index 0cb8f93..4e028ee 100644
> --- a/block/blk-mq-sched.h
> +++ b/block/blk-mq-sched.h
> @@ -28,11 +28,6 @@ void blk_mq_sched_dispatch_requests(struct blk_mq_hw_ctx 
> *hctx);
>  int blk_mq_init_sched(struct request_queue *q, struct elevator_type *e);
>  void blk_mq_exit_sched(struct request_queue *q, struct elevator_queue *e);
>
> -int blk_mq_sched_init_hctx(struct request_queue *q, struct blk_mq_hw_ctx 
> *hctx,
> -  unsigned int hctx_idx);
> -void blk_mq_sched_exit_hctx(struct request_queue *q, struct blk_mq_hw_ctx 
> *hctx,
> -   unsigned int hctx_idx);
> -
>  static inline bool
>  blk_mq_sched_bio_merge(struct request_queue *q, struct bio *bio)
>  {
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 5efd789..de7027f 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -2147,8 +2147,6 @@ static void blk_mq_exit_hctx(struct request_queue *q,
> if (set->ops->exit_request)
> set->ops->exit_request(set, hctx->fq->flush_rq, hctx_idx);
>
> -   blk_mq_sched_exit_hctx(q, hctx, hctx_idx);
> -
> if (set->ops->exit_hctx)
> set->ops->exit_hctx(hctx, hctx_idx);
>
> @@ -2216,12 +2214,9 @@ static int blk_mq_init_hctx(struct request_queue *q,
> set->ops->init_hctx(hctx, set->driver_data, hctx_idx))
> goto free_bitmap;
>
> -   if (blk_mq_sched_init_hctx(q, hctx, hctx_idx))
> -   goto exit_hctx;
> -
> hctx->fq = blk_alloc_flush_queue(q, hctx->numa_node, set->cmd_size);
> if (!hctx->fq)
> -   goto sched_exit_hctx;
> +   goto exit_hctx;
>
> if (blk_mq_init_request(set, hctx->fq->flush_rq, hctx_idx, node))
> goto free_fq;
> @@ -2235,8 +2230,6 @@ static int blk_mq_init_hctx(struct request_queue *q,
>
>   free_fq:
> kfree(hctx->fq);
> - sched_exit_hctx:
> -   blk_mq_sched_exit_hctx(q, hctx, hctx_idx);
>   exit_hctx:
> if (set->ops->exit_hctx)
> set->ops->exit_hctx(hctx, hctx_idx);
> @@ -2913,6 +2906,25 @@ static void __blk_mq_update_nr_hw_

Re: [PATCH] arm64: kasan: add interceptors for strcmp/strncmp functions

[kbuild test robot]

Hi Kyeongdon,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.18 next-20180817]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kyeongdon-Kim/arm64-kasan-add-interceptors-for-strcmp-strncmp-functions/20180817-165304
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: x86_64-randconfig-x012-201832 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   mm/kasan/kasan.c: In function 'strcmp':
>> mm/kasan/kasan.c:313:9: error: implicit declaration of function '__strcmp'; 
>> did you mean 'strcmp'? [-Werror=implicit-function-declaration]
 return __strcmp(cs, ct);
^~~~
strcmp
   mm/kasan/kasan.c: In function 'strncmp':
>> mm/kasan/kasan.c:321:9: error: implicit declaration of function '__strncmp'; 
>> did you mean 'strncmp'? [-Werror=implicit-function-declaration]
 return __strncmp(cs, ct, len);
^
strncmp
   cc1: some warnings being treated as errors

vim +313 mm/kasan/kasan.c

   298  
   299  #undef memcpy
   300  void *memcpy(void *dest, const void *src, size_t len)
   301  {
   302  check_memory_region((unsigned long)src, len, false, _RET_IP_);
   303  check_memory_region((unsigned long)dest, len, true, _RET_IP_);
   304  
   305  return __memcpy(dest, src, len);
   306  }
   307  #undef strcmp
   308  int strcmp(const char *cs, const char *ct)
   309  {
   310  check_memory_region((unsigned long)cs, 1, false, _RET_IP_);
   311  check_memory_region((unsigned long)ct, 1, false, _RET_IP_);
   312  
 > 313  return __strcmp(cs, ct);
   314  }
   315  #undef strncmp
   316  int strncmp(const char *cs, const char *ct, size_t len)
   317  {
   318  check_memory_region((unsigned long)cs, len, false, _RET_IP_);
   319  check_memory_region((unsigned long)ct, len, false, _RET_IP_);
   320  
 > 321  return __strncmp(cs, ct, len);
   322  }
   323  void kasan_alloc_pages(struct page *page, unsigned int order)
   324  {
   325  if (likely(!PageHighMem(page)))
   326  kasan_unpoison_shadow(page_address(page), PAGE_SIZE << 
order);
   327  }
   328  

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


.config.gz
Description: application/gzip

Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped

[Rafael J. Wysocki]

On Thursday, August 16, 2018 3:27:24 PM CEST Frederic Weisbecker wrote:
> On Thu, Aug 09, 2018 at 07:08:34PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > If the tick has been stopped already, but the governor has not asked to
> > stop it (which it can do sometimes), the idle loop should invoke
> > tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> > of this case properly.
> > 
> > Fixes: 554c8aa8ecad (sched: idle: Select idle state before stopping the 
> > tick)
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >  kernel/sched/idle.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-pm/kernel/sched/idle.c
> > ===
> > --- linux-pm.orig/kernel/sched/idle.c
> > +++ linux-pm/kernel/sched/idle.c
> > @@ -190,7 +190,7 @@ static void cpuidle_idle_call(void)
> >  */
> > next_state = cpuidle_select(drv, dev, &stop_tick);
> >  
> > -   if (stop_tick)
> > +   if (stop_tick || tick_nohz_tick_stopped())
> > tick_nohz_idle_stop_tick();
> > else
> > tick_nohz_idle_retain_tick();
> 
> So what if tick_nohz_idle_stop_tick() sees no timer to schedule and
> cancels it, we may remain idle in a shallow state for a long while?

Yes, but the governor is expected to avoid using shallow states when the
tick is stopped already.

> Otherwise we can have something like this:
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index da9455a..408c985 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, 
> int cpu)
>  static void tick_nohz_retain_tick(struct tick_sched *ts)
>  {
>   ts->timer_expires_base = 0;
> +
> + if (ts->tick_stopped)
> + tick_nohz_restart(ts, ktime_get());
>  }
>  
>  #ifdef CONFIG_NO_HZ_FULL
> 

We could do that, but my concern with that approach is that we may end up
stopping and starting the tick back and forth without exiting the loop
in do_idle() just because somebody uses a periodic timer behind our
back and the governor gets confused.

Besides, that would be a change in behavior, while the $subject patch
simply fixes a mistake in the original design.

Cheers,
Rafael

Re: [PATCH v9 17/22] s390: vfio-ap: zeroize the AP queues.

[Cornelia Huck]

On Wed, 15 Aug 2018 16:36:32 -0400
Tony Krowiak  wrote:

> On 08/15/2018 12:24 PM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:14 -0400
> > Tony Krowiak  wrote:
> >
> > Nit: please drop the leading period in the subject.  
> 
> I assume you mean the ending period?

Err, of course.

> 
> >  
> >> From: Tony Krowiak 
> >>
> >> Let's call PAPQ(ZAPQ) to zeroize a queue:
> >>
> >> * For each queue configured for a mediated matrix device
> >>when it is released.
> >>
> >> Zeroizing a queue resets the queue, clears all pending
> >> messages for the queue entries and disables adapter interruptions
> >> associated with the queue.
> >>
> >> Signed-off-by: Tony Krowiak 
> >> Reviewed-by: Halil Pasic 
> >> Tested-by: Michael Mueller 
> >> Tested-by: Farhan Ali 
> >> Signed-off-by: Christian Borntraeger 
> >> ---
> >>   drivers/s390/crypto/vfio_ap_ops.c |   25 +
> >>   drivers/s390/crypto/vfio_ap_private.h |   25 +
> >>   2 files changed, 50 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/s390/crypto/vfio_ap_private.h 
> >> b/drivers/s390/crypto/vfio_ap_private.h
> >> index 3e8534b..34f982a 100644
> >> --- a/drivers/s390/crypto/vfio_ap_private.h
> >> +++ b/drivers/s390/crypto/vfio_ap_private.h
> >> @@ -74,4 +74,29 @@ struct ap_matrix_mdev {
> >>   extern int vfio_ap_mdev_register(void);
> >>   extern void vfio_ap_mdev_unregister(void);
> >>   
> >> +static inline int vfio_ap_reset_queue(unsigned int apid, unsigned int 
> >> apqi,
> >> +unsigned int retry)
> >> +{
> >> +  struct ap_queue_status status;
> >> +
> >> +  do {
> >> +  status = ap_zapq(AP_MKQID(apid, apqi));
> >> +  switch (status.response_code) {
> >> +  case AP_RESPONSE_NORMAL:
> >> +  return 0;
> >> +  case AP_RESPONSE_RESET_IN_PROGRESS:
> >> +  case AP_RESPONSE_BUSY:
> >> +  msleep(20);
> >> +  break;
> >> +  default:
> >> +  pr_warn("%s: error zeroizing %02x.%04x: response code 
> >> %d\n",
> >> +  VFIO_AP_MODULE_NAME, apid, apqi,
> >> +  status.response_code);  
> > How can we end up here? Does this mean that we just don't know what to
> > do with this response, or is this something that should never happen?
> > (How much sense does it make to print an error?)  
> 
> There are additional response codes that could be returned; for example,
> in the case of a catastrophic failure such as: The function can not be
> performed because the AP was somehow deconfigured or the functiona
> cannot be performed due to a machine check failure that caused the AP
> path to be removed. It shouldn't happen, but all are possibilities.
> I can get rid of the message and just return -EIO if you prefer.

These sound like "ugh, we're broken anyway". Not sure if an additional
message would help here much; I'd expect other code to just handle the
failure (especially things like machine checks). I would not oppose
removing the message :)

Maybe add a comment /* things are really broken, give up */ instead?

> 
> >  
> >> +  return -EIO;
> >> +  }
> >> +  } while (retry--);
> >> +
> >> +  return -EBUSY;
> >> +}
> >> +
> >>   #endif /* _VFIO_AP_PRIVATE_H_ */  
> 
> 

Re: [PATCH v2] console: Add console=auto option

[Sergey Senozhatsky]

On (08/16/18 13:39), Prarit Bhargava wrote:
>
> + auto[X86] Enable ACPI SPCR console

And arm64?


Any chance we can rename param to "spcr" or something more clear?
To explicitly state what exactly it's going to do. `auto' sounds
too general and doesn't tell me that much. I'm probably the only
here who can't see a connection between "auto" and "SPCR", but
still.

One more thing, as far as I can tell, acpi_parse_spcr() can fail
and return an error. arch_console_setup() hides all errors and
returns void. Should it return error code?

int arch_console_setup(void)
{
return acpi_parse_spcr(false, true);
}

Or maybe

void arch_console_setup(void)
{
if (acpi_parse_spcr(false, true))
pr_err(.);
}

There can be other consoles in the system, logging an error is not
such a useless thing.

-ss

Re: [PATCH v9 18/22] s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl

[Cornelia Huck]

On Wed, 15 Aug 2018 17:05:48 -0400
Tony Krowiak  wrote:

> On 08/15/2018 12:38 PM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:15 -0400
> > Tony Krowiak  wrote:

> >> +  case VFIO_DEVICE_RESET:
> >> +  ret = vfio_ap_mdev_reset_queues(mdev, true);  
> > If I see it correctly, you call this function only ever with force ==
> > true (here and in the previous patch). Is that what you intended?  
> 
> That does seem to be the case now; however, I think at one time there were
> additional calls to this function. For some reason of which I am not aware,
> those were removed, so there is probably no need for it now.

If you don't see a need for it anymore, I'd just remove the parameter.
Even makes vfio_ap_mdev_reset_queues() a bit nicer :)

Re: [RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

[Benjamin Herrenschmidt]

On Fri, 2018-08-17 at 14:30 +0530, Hari Vyas wrote:
> So many mail threads for common issues going so just trying to
> summarize concern from my side.
> 1) HW level
> PCI Config data overwritten (ex: PCI_COMMAND bits etc) was happening
> at lower layer so from my
> perspective, it is best to handle concern at lower level with locking
> mechanism and that is what
> I proposed in my upcoming patch. Without that, I guess, we may end up
> in issues later with some weird scenario
> which may not be known today  and we will again be fine tuning stuff
> here and there.

Maybe... at this point I'm not trying to address that specific issue.
That being said, the PCI_COMMAND register should be under control of
the driver at runtime and thus shouldn't be exposed to races like that
except in the usual case of races in configuring bridges. Those races
definitely need to be handled at the higher level.

So I'm rather dubious of adding a whole new layer of "modify" callbacks
to config space accessors for that, especially since they won't do any
good on architectures with lockless config accesses such as ... x86 

> 2) SW level(internal data structure):
> About is_added,is_busmaster: These all are bit fields so infact I too
> suggested to remove those bit fields and
> make separate variables in pci_dev structure. 
> This will avoid all data-overwritten,concurrency issues but ofcourse
> at the level of space cost.

It's unnecessary to do blanket changes without first understanding the
details of what's going on. A lot of these things are never touched
outside of the overall single threaded environment of
discovery/assignment or under driver control, in which case it's
expectd that the driver doesn't call them in racy ways

That said, I'm happy to move some of them under my proposed
dev_state_lock.

For is_added specifically, the field is simply set at the wrong time as
you can see in my previous patch.

> Other possibility will be either to use atomic

Atomic is almost always wrong. It doesn't synchronize anything other
than the field, so either it's a big waste of it gives a false sense of
security for something that's almost always still racy.

I'd rather keep the indication that a bunch of those fields *are*
unprotected and rely on the outer layers being single threaded.

>  or locking mechanism
> for these. My point here is also same, better
> avoid fine tuning later stage.
> Moving is_added up and down doesn't look like good as we are just
> shifting issue up and down.

No, you are wrong. I also originally covered is_added with my new mutex
but in hindsight it's the wrong thing to do, and went back to the
correct fix at this point which is precisely to move it up.

is_added is essentially owned by the part of the PCI probe code that
runs single threaded before the device gets exposed to the device
model.

Pretty much all of the code, including all the corresponding fields
(struct resources etc...) in pci_dev are unprotected and rely on being
accessed in a single threaded manner. is_added is no exception.

It was simply a mistake to set it after device_attach().

Thus moving it back up fixes it *correctly* by making it follow the
same rules as all the related fields.

That said, if we want to start adding protection to all those other
fields, then this is a different matter alltogether. But at this point,
this is the best fix for the problem at hand.

> Please check and decide accordingly. I will hold my to-be-submitted
> modify() patch about handling hw level
> over-written case with locking around read-write operation.

Can you remind us in this thread which specific cases of RMW races of
config space you were trying to address ?

Cheers,
Ben.

[PATCH 02/13] perf tools: Get rid of dso__needs_decompress call in symbol__disassemble

[Jiri Olsa]

There's no need to call dso__needs_decompress twice
in the function.

Link: http://lkml.kernel.org/n/tip-4lygwpnkdyed2rtiof4bl...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/annotate.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e4268b948e0e..20061cf42288 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1629,6 +1629,7 @@ static int symbol__disassemble(struct symbol *sym, struct 
annotate_args *args)
char symfs_filename[PATH_MAX];
struct kcore_extract kce;
bool delete_extract = false;
+   bool decomp = false;
int stdout_fd[2];
int lineno = 0;
int nline;
@@ -1662,6 +1663,7 @@ static int symbol__disassemble(struct symbol *sym, struct 
annotate_args *args)
 tmp, sizeof(tmp)) < 0)
goto out;
 
+   decomp = true;
strcpy(symfs_filename, tmp);
}
 
@@ -1748,7 +1750,7 @@ static int symbol__disassemble(struct symbol *sym, struct 
annotate_args *args)
 out_remove_tmp:
close(stdout_fd[0]);
 
-   if (dso__needs_decompress(dso))
+   if (decomp)
unlink(symfs_filename);
 
if (delete_extract)
-- 
2.17.1

[PATCH 04/13] perf tools: Make decompress_to_file function static

[Jiri Olsa]

There's no outside user of it.

Link: http://lkml.kernel.org/n/tip-w7pmh9n76tz9xt5r4xnsn...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/dso.c | 3 ++-
 tools/perf/util/dso.h | 1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 8ee1faa5726f..3f38b6a08a9a 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -239,7 +239,8 @@ bool is_kernel_module(const char *pathname, int cpumode)
return m.kmod;
 }
 
-bool decompress_to_file(const char *ext, const char *filename, int output_fd)
+static bool
+decompress_to_file(const char *ext, const char *filename, int output_fd)
 {
unsigned i;
 
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index ef69de2e69ea..e1adadd1fe1e 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -252,7 +252,6 @@ int dso__read_binary_type_filename(const struct dso *dso, 
enum dso_binary_type t
   char *root_dir, char *filename, size_t size);
 bool is_supported_compression(const char *ext);
 bool is_kernel_module(const char *pathname, int cpumode);
-bool decompress_to_file(const char *ext, const char *filename, int output_fd);
 bool dso__needs_decompress(struct dso *dso);
 int dso__decompress_kmodule_fd(struct dso *dso, const char *name);
 int dso__decompress_kmodule_path(struct dso *dso, const char *name,
-- 
2.17.1

[PATCH 05/13] perf tools: Make is_supported_compression function static

[Jiri Olsa]

There's no outside user of it.

Link: http://lkml.kernel.org/n/tip-w7pmh9n76tz9xt5r4xnsn...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/dso.c | 2 +-
 tools/perf/util/dso.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 3f38b6a08a9a..4449a7257340 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -202,7 +202,7 @@ static const struct {
{ NULL, NULL },
 };
 
-bool is_supported_compression(const char *ext)
+static bool is_supported_compression(const char *ext)
 {
unsigned i;
 
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index e1adadd1fe1e..870346b333ee 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -250,7 +250,6 @@ int dso__kernel_module_get_build_id(struct dso *dso, const 
char *root_dir);
 char dso__symtab_origin(const struct dso *dso);
 int dso__read_binary_type_filename(const struct dso *dso, enum dso_binary_type 
type,
   char *root_dir, char *filename, size_t size);
-bool is_supported_compression(const char *ext);
 bool is_kernel_module(const char *pathname, int cpumode);
 bool dso__needs_decompress(struct dso *dso);
 int dso__decompress_kmodule_fd(struct dso *dso, const char *name);
-- 
2.17.1

[PATCH 01/13] perf tools: Get rid of dso__needs_decompress call in read_object_code

[Jiri Olsa]

There's no need to call dso__needs_decompress twice
in the function.

Link: http://lkml.kernel.org/n/tip-ze5ga3ioou08aq94pe59v...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/tests/code-reading.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 4892bd2dc33e..6b049f3f5cf4 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -232,6 +232,7 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
u64 objdump_addr;
const char *objdump_name;
char decomp_name[KMOD_DECOMP_LEN];
+   bool decomp = false;
int ret;
 
pr_debug("Reading object code for memory address: %#"PRIx64"\n", addr);
@@ -305,6 +306,7 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
return -1;
}
 
+   decomp = true;
objdump_name = decomp_name;
}
 
@@ -312,7 +314,7 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
objdump_addr = map__rip_2objdump(al.map, al.addr);
ret = read_via_objdump(objdump_name, objdump_addr, buf2, len);
 
-   if (dso__needs_decompress(al.map->dso))
+   if (decomp)
unlink(objdump_name);
 
if (ret > 0) {
-- 
2.17.1

[PATCH 00/13] perf tools: Use plain debug files for compressed objects

[Jiri Olsa]

hi,
currently we don't allow to open plain debug files for
compressed kernel module objects, ending up with following
warning:

  $ perf report --stdio
  lzma: failed The input is not in the .xz format
  lzma: failed The input is not in the .xz format
  lzma: failed The input is not in the .xz format
  lzma: failed The input is not in the .xz format
  # To display the perf.data header info, please use --header/--header-only 
options.

The reason is behind the logic we open the DSO object files,
when we try all possible 'debug' objects until we find the
data. So even if the DSO is represented by 'krava.xz' module,
we can end up opening ~/.debug/23432432/debug' file which
is not compressed and we fail with above error.

This patchset adds the code to detect un/compressed files and
return plain debug file when available even for compressed
kernel modules.

Also available in here:
  git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
  perf/fixes

thanks,
jirka


---
Jiri Olsa (13):
  perf tools: Get rid of dso__needs_decompress call in read_object_code
  perf tools: Get rid of dso__needs_decompress call in symbol__disassemble
  perf tools: Get rid of dso__needs_decompress call in __open_dso
  perf tools: Make decompress_to_file function static
  perf tools: Make is_supported_compression function static
  perf tools: Add compression id into struct kmod_path
  perf tools: Store compression id into struct dso
  perf tools: Use compression id in decompress_kmodule function
  perf tools: Move the temp file processing into decompress_kmodule
  perf tools: Add is_compressed callback to compressions array
  perf tools: Add lzma_is_compressed function
  perf tools: Add gzip_is_compressed function
  perf tools: Remove ext from struct kmod_path

 tools/perf/tests/code-reading.c |   4 +++-
 tools/perf/tests/kmod-path.c| 136 
++---
 tools/perf/util/annotate.c  |   4 +++-
 tools/perf/util/compress.h  |   2 ++
 tools/perf/util/dso.c   | 111 
++---
 tools/perf/util/dso.h   |  13 +
 tools/perf/util/lzma.c  |  20 +++
 tools/perf/util/machine.c   |   4 +++-
 tools/perf/util/zlib.c  |  18 +
 9 files changed, 172 insertions(+), 140 deletions(-)

[PATCH 09/13] perf tools: Move the temp file processing into decompress_kmodule

[Jiri Olsa]

We will add compression check in following patch and it
makes it easier if the tem file processing is done in the
single place. It also makes the current code simpler.

The decompress_kmodule function now returns the fd of the
uncompressed file and the file name in pathname arg, if it's
provided.

Link: http://lkml.kernel.org/n/tip-n8ul4r0tny6n16012uncx...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/dso.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 1cee958c9a2a..0f07aab30ffe 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -250,8 +250,10 @@ bool dso__needs_decompress(struct dso *dso)
dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE_COMP;
 }
 
-static int decompress_kmodule(struct dso *dso, const char *name, char *tmpbuf)
+static int decompress_kmodule(struct dso *dso, const char *name,
+ char *pathname, size_t len)
 {
+   char tmpbuf[] = KMOD_DECOMP_NAME;
int fd = -1;
 
if (!dso__needs_decompress(dso))
@@ -272,34 +274,27 @@ static int decompress_kmodule(struct dso *dso, const char 
*name, char *tmpbuf)
fd = -1;
}
 
+   if (!pathname || (fd < 0))
+   unlink(tmpbuf);
+
+   if (pathname && (fd >= 0))
+   strncpy(pathname, tmpbuf, len);
+
return fd;
 }
 
 int dso__decompress_kmodule_fd(struct dso *dso, const char *name)
 {
-   char tmpbuf[] = KMOD_DECOMP_NAME;
-   int fd;
-
-   fd = decompress_kmodule(dso, name, tmpbuf);
-   unlink(tmpbuf);
-   return fd;
+   return decompress_kmodule(dso, name, NULL, 0);
 }
 
 int dso__decompress_kmodule_path(struct dso *dso, const char *name,
 char *pathname, size_t len)
 {
-   char tmpbuf[] = KMOD_DECOMP_NAME;
-   int fd;
-
-   fd = decompress_kmodule(dso, name, tmpbuf);
-   if (fd < 0) {
-   unlink(tmpbuf);
-   return -1;
-   }
+   int fd = decompress_kmodule(dso, name, pathname, len);
 
-   strncpy(pathname, tmpbuf, len);
close(fd);
-   return 0;
+   return fd >= 0 ? 0 : -1;
 }
 
 /*
-- 
2.17.1

[PATCH 12/13] perf tools: Add gzip_is_compressed function

[Jiri Olsa]

Add implementation of the is_compressed callback for gzip.

Link: http://lkml.kernel.org/n/tip-f9ponomi33whctnx9vnad...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/zlib.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/zlib.c b/tools/perf/util/zlib.c
index e68317214679..902ce6384f57 100644
--- a/tools/perf/util/zlib.c
+++ b/tools/perf/util/zlib.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "util/compress.h"
 #include "util/util.h"
@@ -81,7 +82,18 @@ int gzip_decompress_to_file(const char *input, int output_fd)
return ret == Z_STREAM_END ? 0 : -1;
 }
 
-bool gzip_is_compressed(const char *input __maybe_unused)
+bool gzip_is_compressed(const char *input)
 {
-   return true;
+   int fd = open(input, O_RDONLY);
+   const uint8_t magic[2] = { 0x1f, 0x8b };
+   char buf[2] = { 0 };
+   ssize_t rc;
+
+   if (fd < 0)
+   return -1;
+
+   rc = read(fd, buf, sizeof(buf));
+   close(fd);
+   return rc == sizeof(buf) ?
+  memcmp(buf, magic, sizeof(buf)) == 0 : false;
 }
-- 
2.17.1

[PATCH 13/13] perf tools: Remove ext from struct kmod_path

[Jiri Olsa]

Having comp carrying the compression ID, we no longer
need return the extension. Removing it and updating the
automated test.

Link: http://lkml.kernel.org/n/tip-u2gmyuspmefg0ns9svpzd...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/tests/kmod-path.c | 136 +--
 tools/perf/util/dso.c|  10 +--
 tools/perf/util/dso.h|   8 +--
 3 files changed, 69 insertions(+), 85 deletions(-)

diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index f92f78f683ea..0579a70bbbff 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -5,34 +5,28 @@
 #include "dso.h"
 #include "debug.h"
 
-static int test(const char *path, bool alloc_name, bool alloc_ext,
-   bool kmod, int comp, const char *name, const char *ext)
+static int test(const char *path, bool alloc_name, bool kmod,
+   int comp, const char *name)
 {
struct kmod_path m;
 
memset(&m, 0x0, sizeof(m));
 
TEST_ASSERT_VAL("kmod_path__parse",
-   !__kmod_path__parse(&m, path, alloc_name, alloc_ext));
+   !__kmod_path__parse(&m, path, alloc_name));
 
-   pr_debug("%s - alloc name %d, alloc ext %d, kmod %d, comp %d, name 
'%s', ext '%s'\n",
-path, alloc_name, alloc_ext, m.kmod, m.comp, m.name, m.ext);
+   pr_debug("%s - alloc name %d, kmod %d, comp %d, name '%s'\n",
+path, alloc_name, m.kmod, m.comp, m.name);
 
TEST_ASSERT_VAL("wrong kmod", m.kmod == kmod);
TEST_ASSERT_VAL("wrong comp", m.comp == comp);
 
-   if (ext)
-   TEST_ASSERT_VAL("wrong ext", m.ext && !strcmp(ext, m.ext));
-   else
-   TEST_ASSERT_VAL("wrong ext", !m.ext);
-
if (name)
TEST_ASSERT_VAL("wrong name", m.name && !strcmp(name, m.name));
else
TEST_ASSERT_VAL("wrong name", !m.name);
 
free(m.name);
-   free(m.ext);
return 0;
 }
 
@@ -45,118 +39,118 @@ static int test_is_kernel_module(const char *path, int 
cpumode, bool expect)
return 0;
 }
 
-#define T(path, an, ae, k, c, n, e) \
-   TEST_ASSERT_VAL("failed", !test(path, an, ae, k, c, n, e))
+#define T(path, an, k, c, n) \
+   TEST_ASSERT_VAL("failed", !test(path, an, k, c, n))
 
 #define M(path, c, e) \
TEST_ASSERT_VAL("failed", !test_is_kernel_module(path, c, e))
 
 int test__kmod_path__parse(struct test *t __maybe_unused, int subtest 
__maybe_unused)
 {
-   /* pathalloc_name  alloc_ext   kmod  comp   name 
ext */
-   T("///x-x.ko", true  , true  , true, 0, "[x_x]", 
NULL);
-   T("///x-x.ko", false , true  , true, 0, NULL   , 
NULL);
-   T("///x-x.ko", true  , false , true, 0, "[x_x]", 
NULL);
-   T("///x-x.ko", false , false , true, 0, NULL   , 
NULL);
+   /* pathalloc_name  kmod  comp   name   */
+   T("///x-x.ko", true  , true, 0, "[x_x]");
+   T("///x-x.ko", false , true, 0, NULL   );
+   T("///x-x.ko", true  , true, 0, "[x_x]");
+   T("///x-x.ko", false , true, 0, NULL   );
M("///x-x.ko", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x-x.ko", PERF_RECORD_MISC_KERNEL, true);
M("///x-x.ko", PERF_RECORD_MISC_USER, false);
 
 #ifdef HAVE_ZLIB_SUPPORT
-   /* pathalloc_name  alloc_ext   kmod  comp  name   ext */
-   T("///x.ko.gz", true , true  , true, 1   , "[x]", "gz");
-   T("///x.ko.gz", false, true  , true, 1   , NULL , "gz");
-   T("///x.ko.gz", true , false , true, 1   , "[x]", NULL);
-   T("///x.ko.gz", false, false , true, 1   , NULL , NULL);
+   /* pathalloc_name   kmod  comp  name  */
+   T("///x.ko.gz", true , true, 1   , "[x]");
+   T("///x.ko.gz", false, true, 1   , NULL );
+   T("///x.ko.gz", true , true, 1   , "[x]");
+   T("///x.ko.gz", false, true, 1   , NULL );
M("///x.ko.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x.ko.gz", PERF_RECORD_MISC_KERNEL, true);
M("///x.ko.gz", PERF_RECORD_MISC_USER, false);
 
-   /* path  alloc_name  alloc_ext  kmod   comp  nameext */
-   T("///x.gz", true  , true , false, 1   , "x.gz" ,"gz");
-   T("///x.gz", false , true , false, 1   , NULL   ,"gz");
-   T("///x.gz", true  , false, false, 1   , "x.gz" , NULL);
-   T("///x.gz", false , false, false, 1   , NULL   , NULL);
+   /* path  alloc_name  kmod   comp  name  */
+   T("///x.gz", true  , false, 1   , "x.gz");
+   T("///x.gz", false , false, 1   ,

[PATCH 11/13] perf tools: Add lzma_is_compressed function

[Jiri Olsa]

Add implementation of the is_compressed callback for lzma.

Link: http://lkml.kernel.org/n/tip-tdgpdhdfk7sm5hsyjvfs2...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/lzma.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c
index 7032caaf75eb..b1dd29a9d915 100644
--- a/tools/perf/util/lzma.c
+++ b/tools/perf/util/lzma.c
@@ -3,9 +3,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "compress.h"
 #include "util.h"
 #include "debug.h"
+#include 
 
 #define BUFSIZE 8192
 
@@ -100,7 +104,18 @@ int lzma_decompress_to_file(const char *input, int 
output_fd)
return err;
 }
 
-bool lzma_is_compressed(const char *input __maybe_unused)
+bool lzma_is_compressed(const char *input)
 {
-   return true;
+   int fd = open(input, O_RDONLY);
+   const uint8_t magic[6] = { 0xFD, '7', 'z', 'X', 'Z', 0x00 };
+   char buf[6] = { 0 };
+   ssize_t rc;
+
+   if (fd < 0)
+   return -1;
+
+   rc = read(fd, buf, sizeof(buf));
+   close(fd);
+   return rc == sizeof(buf) ?
+  memcmp(buf, magic, sizeof(buf)) == 0 : false;
 }
-- 
2.17.1

[PATCH 07/13] perf tools: Store compression id into struct dso

[Jiri Olsa]

Adding comp into struct dso to hold the compression index.
It will be used in following patches.

Link: http://lkml.kernel.org/n/tip-84cxf8bbc0etndwzrzqxx...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/dso.c | 5 -
 tools/perf/util/dso.h | 1 +
 tools/perf/util/machine.c | 4 +++-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index f5f8babea17c..f0e4cc43c97e 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -418,8 +418,10 @@ void dso__set_module_info(struct dso *dso, struct 
kmod_path *m,
dso->symtab_type = DSO_BINARY_TYPE__GUEST_KMODULE;
 
/* _KMODULE_COMP should be next to _KMODULE */
-   if (m->kmod && m->comp)
+   if (m->kmod && m->comp) {
dso->symtab_type++;
+   dso->comp = m->comp;
+   }
 
dso__set_short_name(dso, strdup(m->name), true);
 }
@@ -1225,6 +1227,7 @@ struct dso *dso__new(const char *name)
dso->a2l_fails = 1;
dso->kernel = DSO_TYPE_USER;
dso->needs_swap = DSO_SWAP__UNSET;
+   dso->comp = COMP_ID__NONE;
RB_CLEAR_NODE(&dso->rb_node);
dso->root = NULL;
INIT_LIST_HEAD(&dso->node);
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index 7bde23f6e5a9..a6c7af52115f 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -175,6 +175,7 @@ struct dso {
u16  short_name_len;
void*dwfl;  /* DWARF debug info */
struct auxtrace_cache *auxtrace_cache;
+   int  comp;
 
/* dso data file */
struct {
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index b300a3973448..c4acd2001db0 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1212,8 +1212,10 @@ static int map_groups__set_module_path(struct map_groups 
*mg, const char *path,
 * Full name could reveal us kmod compression, so
 * we need to update the symtab_type if needed.
 */
-   if (m->comp && is_kmod_dso(map->dso))
+   if (m->comp && is_kmod_dso(map->dso)) {
map->dso->symtab_type++;
+   map->dso->comp = m->comp;
+   }
 
return 0;
 }
-- 
2.17.1

[PATCH 06/13] perf tools: Add compression id into struct kmod_path

[Jiri Olsa]

Storing decompression ID in the struct kmod_path, so it
can be later stored in the struct dso.

Switching the struct kmod_path::comp from bool to int
to return the compressions array index. Adding 0 index
item into compressions array, so the comp usage stays
as it was: 0 - no compression, != 0 index of compression.

Updating the kmod_path tests.

Link: http://lkml.kernel.org/n/tip-vxxfco32fh5veg1817udc...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/tests/kmod-path.c | 42 ++--
 tools/perf/util/dso.c| 18 ++--
 tools/perf/util/dso.h|  2 +-
 3 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index 148dd31cc201..f92f78f683ea 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -6,7 +6,7 @@
 #include "debug.h"
 
 static int test(const char *path, bool alloc_name, bool alloc_ext,
-   bool kmod, bool comp, const char *name, const char *ext)
+   bool kmod, int comp, const char *name, const char *ext)
 {
struct kmod_path m;
 
@@ -54,47 +54,47 @@ static int test_is_kernel_module(const char *path, int 
cpumode, bool expect)
 int test__kmod_path__parse(struct test *t __maybe_unused, int subtest 
__maybe_unused)
 {
/* pathalloc_name  alloc_ext   kmod  comp   name 
ext */
-   T("///x-x.ko", true  , true  , true, false, "[x_x]", 
NULL);
-   T("///x-x.ko", false , true  , true, false, NULL   , 
NULL);
-   T("///x-x.ko", true  , false , true, false, "[x_x]", 
NULL);
-   T("///x-x.ko", false , false , true, false, NULL   , 
NULL);
+   T("///x-x.ko", true  , true  , true, 0, "[x_x]", 
NULL);
+   T("///x-x.ko", false , true  , true, 0, NULL   , 
NULL);
+   T("///x-x.ko", true  , false , true, 0, "[x_x]", 
NULL);
+   T("///x-x.ko", false , false , true, 0, NULL   , 
NULL);
M("///x-x.ko", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x-x.ko", PERF_RECORD_MISC_KERNEL, true);
M("///x-x.ko", PERF_RECORD_MISC_USER, false);
 
 #ifdef HAVE_ZLIB_SUPPORT
/* pathalloc_name  alloc_ext   kmod  comp  name   ext */
-   T("///x.ko.gz", true , true  , true, true, "[x]", "gz");
-   T("///x.ko.gz", false, true  , true, true, NULL , "gz");
-   T("///x.ko.gz", true , false , true, true, "[x]", NULL);
-   T("///x.ko.gz", false, false , true, true, NULL , NULL);
+   T("///x.ko.gz", true , true  , true, 1   , "[x]", "gz");
+   T("///x.ko.gz", false, true  , true, 1   , NULL , "gz");
+   T("///x.ko.gz", true , false , true, 1   , "[x]", NULL);
+   T("///x.ko.gz", false, false , true, 1   , NULL , NULL);
M("///x.ko.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x.ko.gz", PERF_RECORD_MISC_KERNEL, true);
M("///x.ko.gz", PERF_RECORD_MISC_USER, false);
 
/* path  alloc_name  alloc_ext  kmod   comp  nameext */
-   T("///x.gz", true  , true , false, true, "x.gz" ,"gz");
-   T("///x.gz", false , true , false, true, NULL   ,"gz");
-   T("///x.gz", true  , false, false, true, "x.gz" , NULL);
-   T("///x.gz", false , false, false, true, NULL   , NULL);
+   T("///x.gz", true  , true , false, 1   , "x.gz" ,"gz");
+   T("///x.gz", false , true , false, 1   , NULL   ,"gz");
+   T("///x.gz", true  , false, false, 1   , "x.gz" , NULL);
+   T("///x.gz", false , false, false, 1   , NULL   , NULL);
M("///x.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, false);
M("///x.gz", PERF_RECORD_MISC_KERNEL, false);
M("///x.gz", PERF_RECORD_MISC_USER, false);
 
/* path   alloc_name  alloc_ext  kmod   comp  name ext */
-   T("x.gz", true  , true , false, true, "x.gz", "gz");
-   T("x.gz", false , true , false, true, NULL  , "gz");
-   T("x.gz", true  , false, false, true, "x.gz", NULL);
-   T("x.gz", false , false, false, true, NULL  , NULL);
+   T("x.gz", true  , true , false, 1   , "x.gz", "gz");
+   T("x.gz", false , true , false, 1   , NULL  , "gz");
+   T("x.gz", true  , false, false, 1   , "x.gz", NULL);
+   T("x.gz", false , false, false, 1   , NULL  , NULL);
M("x.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, false);
M("x.gz", PERF_RECORD_MISC_KERNEL, false);
M("x.gz", PERF_RECORD_MISC_USER, false);
 
/* path  alloc_name  alloc_ext  kmod  

[PATCH 10/13] perf tools: Add is_compressed callback to compressions array

[Jiri Olsa]

Adding is_compressed callback to compressions array,
that returns 0 if the file is compressed or != 0 if not.

The new callback is used to recognize the situation when
we have 'compressed' object, like:
  /lib/modules/.../drivers/net/ethernet/intel/igb/igb.ko.xz

but we need to read its debug data from debuginfo files,
which might not be compressed, like:
  /root/.debug/.build-id/d6/...c4b301f/debug

So even for 'compressed' object we read data from plain
uncompressed object. To keep this transparent, we detect
this in decompress_kmodule and return the file descriptor
to the uncompressed file.

Link: http://lkml.kernel.org/n/tip-diw1xpztojz0pj2wgdt6a...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/compress.h |  2 ++
 tools/perf/util/dso.c  | 23 ---
 tools/perf/util/lzma.c |  5 +
 tools/perf/util/zlib.c |  6 ++
 4 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/compress.h b/tools/perf/util/compress.h
index ecca688a25fb..892e92e7e7fc 100644
--- a/tools/perf/util/compress.h
+++ b/tools/perf/util/compress.h
@@ -4,10 +4,12 @@
 
 #ifdef HAVE_ZLIB_SUPPORT
 int gzip_decompress_to_file(const char *input, int output_fd);
+bool gzip_is_compressed(const char *input);
 #endif
 
 #ifdef HAVE_LZMA_SUPPORT
 int lzma_decompress_to_file(const char *input, int output_fd);
+bool lzma_is_compressed(const char *input);
 #endif
 
 #endif /* PERF_COMPRESS_H */
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 0f07aab30ffe..a7f2162ba730 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -196,15 +196,16 @@ enum {
 static const struct {
const char *fmt;
int (*decompress)(const char *input, int output);
+   bool (*is_compressed)(const char *input);
 } compressions[] = {
[COMP_ID__NONE] = { 0 },
 #ifdef HAVE_ZLIB_SUPPORT
-   { "gz", gzip_decompress_to_file },
+   { "gz", gzip_decompress_to_file, gzip_is_compressed },
 #endif
 #ifdef HAVE_LZMA_SUPPORT
-   { "xz", lzma_decompress_to_file },
+   { "xz", lzma_decompress_to_file, lzma_is_compressed },
 #endif
-   { NULL, NULL },
+   { NULL, NULL, NULL },
 };
 
 static int is_supported_compression(const char *ext)
@@ -262,6 +263,22 @@ static int decompress_kmodule(struct dso *dso, const char 
*name,
if (dso->comp == COMP_ID__NONE)
return -1;
 
+   /*
+* We have proper compression id for DSO and yet the file
+* behind the 'name' can still be plain uncompressed object.
+*
+* The reason is behind the logic we open the DSO object files,
+* when we try all possible 'debug' objects until we find the
+* data. So even if the DSO is represented by 'krava.xz' module,
+* we can end up here opening ~/.debug/23432432/debug' file
+* which is not compressed.
+*
+* To keep this transparent, we detect this and return the file
+* descriptor to the uncompressed file.
+*/
+   if (!compressions[dso->comp].is_compressed(name))
+   return open(name, O_RDONLY);
+
fd = mkstemp(tmpbuf);
if (fd < 0) {
dso->load_errno = errno;
diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c
index 07498eaddc08..7032caaf75eb 100644
--- a/tools/perf/util/lzma.c
+++ b/tools/perf/util/lzma.c
@@ -99,3 +99,8 @@ int lzma_decompress_to_file(const char *input, int output_fd)
fclose(infile);
return err;
 }
+
+bool lzma_is_compressed(const char *input __maybe_unused)
+{
+   return true;
+}
diff --git a/tools/perf/util/zlib.c b/tools/perf/util/zlib.c
index a725b958cf31..e68317214679 100644
--- a/tools/perf/util/zlib.c
+++ b/tools/perf/util/zlib.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "util/compress.h"
 #include "util/util.h"
@@ -79,3 +80,8 @@ int gzip_decompress_to_file(const char *input, int output_fd)
 
return ret == Z_STREAM_END ? 0 : -1;
 }
+
+bool gzip_is_compressed(const char *input __maybe_unused)
+{
+   return true;
+}
-- 
2.17.1

[PATCH 08/13] perf tools: Use compression id in decompress_kmodule function

[Jiri Olsa]

Once we parsed out the compression ID, we dont need to
iterate all available compressions and we can call it
directly.

Link: http://lkml.kernel.org/n/tip-55zrhxhr699pswx34d0hd...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/dso.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index f0e4cc43c97e..1cee958c9a2a 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -244,19 +244,6 @@ bool is_kernel_module(const char *pathname, int cpumode)
return m.kmod;
 }
 
-static bool
-decompress_to_file(const char *ext, const char *filename, int output_fd)
-{
-   unsigned i;
-
-   for (i = 0; compressions[i].fmt; i++) {
-   if (!strcmp(ext, compressions[i].fmt))
-   return !compressions[i].decompress(filename,
-  output_fd);
-   }
-   return false;
-}
-
 bool dso__needs_decompress(struct dso *dso)
 {
return dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP ||
@@ -266,31 +253,25 @@ bool dso__needs_decompress(struct dso *dso)
 static int decompress_kmodule(struct dso *dso, const char *name, char *tmpbuf)
 {
int fd = -1;
-   struct kmod_path m;
 
if (!dso__needs_decompress(dso))
return -1;
 
-   if (kmod_path__parse_ext(&m, dso->long_name))
+   if (dso->comp == COMP_ID__NONE)
return -1;
 
-   if (!m.comp)
-   goto out;
-
fd = mkstemp(tmpbuf);
if (fd < 0) {
dso->load_errno = errno;
-   goto out;
+   return -1;
}
 
-   if (!decompress_to_file(m.ext, name, fd)) {
+   if (compressions[dso->comp].decompress(name, fd)) {
dso->load_errno = DSO_LOAD_ERRNO__DECOMPRESSION_FAILURE;
close(fd);
fd = -1;
}
 
-out:
-   free(m.ext);
return fd;
 }
 
-- 
2.17.1

Re: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings

[Simon Horman]

On Tue, Aug 14, 2018 at 01:32:15PM +0100, Fabrizio Castro wrote:
> Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible
> with this driver, therefore document RZ/G2M specific bindings.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Reviewed-by: Simon Horman 

[PATCH 03/13] perf tools: Get rid of dso__needs_decompress call in __open_dso

[Jiri Olsa]

There's no need to call dso__needs_decompress twice
in the function.

Link: http://lkml.kernel.org/n/tip-06j86wkfb4lxw3oqj50ga...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/dso.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 51cf82cf1882..8ee1faa5726f 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -468,6 +468,7 @@ static int __open_dso(struct dso *dso, struct machine 
*machine)
int fd = -EINVAL;
char *root_dir = (char *)"";
char *name = malloc(PATH_MAX);
+   bool decomp = false;
 
if (!name)
return -ENOMEM;
@@ -491,12 +492,13 @@ static int __open_dso(struct dso *dso, struct machine 
*machine)
goto out;
}
 
+   decomp = true;
strcpy(name, newpath);
}
 
fd = do_open(name);
 
-   if (dso__needs_decompress(dso))
+   if (decomp)
unlink(name);
 
 out:
-- 
2.17.1

Re: [PATCH v4 3/4] mm/memory_hotplug: Define nodemask_t as a stack variable

[David Hildenbrand]

On 17.08.2018 11:00, Oscar Salvador wrote:
> From: Oscar Salvador 
> 
> Currently, unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
> in order to check whithin the loop which nodes have already been unlinked,
> so we do not repeat the operation on them.
> 
> NODEMASK_ALLOC calls kmalloc() if NODES_SHIFT > 8, otherwise
> it just declares a nodemask_t variable whithin the stack.
> 
> Since kmalloc() can fail, we actually check whether NODEMASK_ALLOC failed
> or not, and we return -ENOMEM accordingly.
> remove_memory_section() does not check for the return value though.
> It is pretty rare that such a tiny allocation can fail, but if it does,
> we will be left with dangled symlinks under /sys/devices/system/node/,
> since the mem_blk's directories will be removed no matter what
> unregister_mem_sect_under_nodes() returns.
> 
> One way to solve this is to check whether unlinked_nodes is NULL or not.
> In the case it is not, we can just use it as before, but if it is NULL,
> we can just skip the node_test_and_set check, and call sysfs_remove_link()
> unconditionally.
> This is harmless as sysfs_remove_link() backs off somewhere down the chain
> in case the link has already been removed.
> This method was presented in v3 of the path [1].
> 
> But since the maximum number of nodes we can have is 1024,
> when NODES_SHIFT = 10, that gives us a nodemask_t of 128 bytes.
> Although everything depends on how deep the stack is, I think we can afford
> to define the nodemask_t variable whithin the stack.
> 
> That simplifies the code, and we do not need to worry about untested error
> code paths.
> 
> If we see that this causes troubles with the stack, we can always return to 
> [1].
> 
> [1] https://patchwork.kernel.org/patch/10566673/
> 
> Signed-off-by: Oscar Salvador 
> ---
>  drivers/base/node.c  | 16 ++--
>  include/linux/node.h |  5 ++---
>  2 files changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index dd3bdab230b2..6b8c9b4537c9 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -449,35 +449,31 @@ int register_mem_sect_under_node(struct memory_block 
> *mem_blk, void *arg)
>  }
>  
>  /* unregister memory section under all nodes that it spans */
> -int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
> +void unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
>   unsigned long phys_index)

I am a friend of fixing up alignment of other parameters.

>  {
> - NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
> + nodemask_t unlinked_nodes;
>   unsigned long pfn, sect_start_pfn, sect_end_pfn;
>  
> - if (!unlinked_nodes)
> - return -ENOMEM;
> - nodes_clear(*unlinked_nodes);
> + nodes_clear(unlinked_nodes);
>  
>   sect_start_pfn = section_nr_to_pfn(phys_index);
>   sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
>   for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> - int nid;
> + int nid = get_nid_for_pfn(pfn);
>  
> - nid = get_nid_for_pfn(pfn);
>   if (nid < 0)
>   continue;
>   if (!node_online(nid))
>   continue;
> - if (node_test_and_set(nid, *unlinked_nodes))
> + if (node_test_and_set(nid, unlinked_nodes))
>   continue;
> +
>   sysfs_remove_link(&node_devices[nid]->dev.kobj,
>kobject_name(&mem_blk->dev.kobj));
>   sysfs_remove_link(&mem_blk->dev.kobj,
>kobject_name(&node_devices[nid]->dev.kobj));
>   }
> - NODEMASK_FREE(unlinked_nodes);
> - return 0;
>  }
>  
>  int link_mem_sections(int nid, unsigned long start_pfn, unsigned long 
> end_pfn)
> diff --git a/include/linux/node.h b/include/linux/node.h
> index 257bb3d6d014..1203378e596a 100644
> --- a/include/linux/node.h
> +++ b/include/linux/node.h
> @@ -72,7 +72,7 @@ extern int register_cpu_under_node(unsigned int cpu, 
> unsigned int nid);
>  extern int unregister_cpu_under_node(unsigned int cpu, unsigned int nid);
>  extern int register_mem_sect_under_node(struct memory_block *mem_blk,
>   void *arg);
> -extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
> +extern void unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
>  unsigned long phys_index);

dito

>  
>  #ifdef CONFIG_HUGETLBFS
> @@ -105,10 +105,9 @@ static inline int register_mem_sect_under_node(struct 
> memory_block *mem_blk,
>  {
>   return 0;
>  }
> -static inline int unregister_mem_sect_under_nodes(struct memory_block 
> *mem_blk,
> +static inline void unregister_mem_sect_under_nodes(struct memory_block 
> *mem_blk,
> unsigned long phys_index)

dito

>  {
> - return 0;
>  }
>  
>  

[PATCH] intel_punit_ipc: include linux/io.h

[Arnd Bergmann]

After we stop including linux/irq.h implicitly, we don't see linux/io.h
in intel_punit_ipc.c, leading to a build failure:

drivers/platform/x86/intel_punit_ipc.c: In function 'ipc_read_status':
drivers/platform/x86/intel_punit_ipc.c:55:9: error: implicit declaration of 
function 'readl' [-Werror=implicit-function-declaration]

Add back the include that is clearly needed.

Fixes: 447ae3166702 ("x86: Don't include linux/irq.h from asm/hardirq.h")
Cc: Nicolai Stange 
Cc: Thomas Gleixner 
Signed-off-by: Arnd Bergmann 
---
 drivers/platform/x86/intel_punit_ipc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/intel_punit_ipc.c 
b/drivers/platform/x86/intel_punit_ipc.c
index f1afc0ebbc68..2efeab650345 100644
--- a/drivers/platform/x86/intel_punit_ipc.c
+++ b/drivers/platform/x86/intel_punit_ipc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.18.0

[PATCH] x86: mce: add notifier_block forward declaration

[Arnd Bergmann]

Without linux/irq.h, we don't see a declaration of notifier_block,
leading to a build warning:

In file included from arch/x86/kernel/cpu/mcheck/threshold.c:10:
arch/x86/include/asm/mce.h:151:46: error: 'struct notifier_block' declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]

It's sufficient to declare the struct tag here, which avoids pulling
in more header files.

Fixes: 447ae3166702 ("x86: Don't include linux/irq.h from asm/hardirq.h")
Signed-off-by: Arnd Bergmann 
---
 arch/x86/include/asm/mce.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 8c7b3e5a2d01..3a17107594c8 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -148,6 +148,7 @@ enum mce_notifier_prios {
MCE_PRIO_LOWEST = 0,
 };
 
+struct notifier_block;
 extern void mce_register_decode_chain(struct notifier_block *nb);
 extern void mce_unregister_decode_chain(struct notifier_block *nb);
 
-- 
2.18.0

Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped

[Rafael J. Wysocki]

On Fri, Aug 17, 2018 at 11:34 AM Rafael J. Wysocki  wrote:
>
> On Thursday, August 16, 2018 3:27:24 PM CEST Frederic Weisbecker wrote:
> > On Thu, Aug 09, 2018 at 07:08:34PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki 
> > >
> > > If the tick has been stopped already, but the governor has not asked to
> > > stop it (which it can do sometimes), the idle loop should invoke
> > > tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> > > of this case properly.
> > >
> > > Fixes: 554c8aa8ecad (sched: idle: Select idle state before stopping the 
> > > tick)
> > > Signed-off-by: Rafael J. Wysocki 
> > > ---
> > >  kernel/sched/idle.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Index: linux-pm/kernel/sched/idle.c
> > > ===
> > > --- linux-pm.orig/kernel/sched/idle.c
> > > +++ linux-pm/kernel/sched/idle.c
> > > @@ -190,7 +190,7 @@ static void cpuidle_idle_call(void)
> > >  */
> > > next_state = cpuidle_select(drv, dev, &stop_tick);
> > >
> > > -   if (stop_tick)
> > > +   if (stop_tick || tick_nohz_tick_stopped())
> > > tick_nohz_idle_stop_tick();
> > > else
> > > tick_nohz_idle_retain_tick();
> >
> > So what if tick_nohz_idle_stop_tick() sees no timer to schedule and
> > cancels it, we may remain idle in a shallow state for a long while?
>
> Yes, but the governor is expected to avoid using shallow states when the
> tick is stopped already.
>
> > Otherwise we can have something like this:
> >
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index da9455a..408c985 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, 
> > int cpu)
> >  static void tick_nohz_retain_tick(struct tick_sched *ts)
> >  {
> >   ts->timer_expires_base = 0;
> > +
> > + if (ts->tick_stopped)
> > + tick_nohz_restart(ts, ktime_get());
> >  }
> >
> >  #ifdef CONFIG_NO_HZ_FULL
> >
>
> We could do that, but my concern with that approach is that we may end up
> stopping and starting the tick back and forth without exiting the loop
> in do_idle() just because somebody uses a periodic timer behind our
> back and the governor gets confused.
>
> Besides, that would be a change in behavior, while the $subject patch
> simply fixes a mistake in the original design.

Anyway, I'm sort of divided here.

We need to do something, this way or another, because the current code
is not strictly correct.

If there are no concerns about the possible extra overhead related to
restarting the tick, I'd just add a tick_nohz_idle_restart_tick() to
the tick_nohz_idle_retain_tick() branch in cpuidle_idle_call() (it
would do what's needed in there without affecting any other places).

Then, of course, governors would not need to worry about leaving the
tick stopped, so menu could be simplified somewhat, which may be a
good thing after all.

Cheers,
Rafael

[PATCH] spi: fsl-espi: master->mem_ops is implemented in the controller

[Chuanhua Han]

The length of the transmitted data needs to be adjusted due to the maximum 
length limit for espi transmission messages

Signed-off-by: Chuanhua Han 
---
 drivers/spi/spi-fsl-espi.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index 1d332e2..4724127 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* eSPI Controller registers */
 #define ESPI_SPMODE0x00/* eSPI mode register */
@@ -659,6 +660,29 @@ static void fsl_espi_init_regs(struct device *dev, bool 
initial)
fsl_espi_write_reg(espi, ESPI_SPMODE, SPMODE_INIT_VAL | SPMODE_ENABLE);
 }
 
+static int fsl_espi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+   if (!mem || !op)
+   return -EINVAL;
+   op->data.nbytes = min3((unsigned long)op->data.nbytes,
+   spi_max_transfer_size(mem->spi),
+   spi_max_message_size(mem->spi) -
+   sizeof(op->cmd.opcode) -
+   op->addr.nbytes -
+   op->dummy.nbytes);
+   return 0;
+}
+
+static int fsl_espi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+   return -ENOTSUPP;
+}
+
+static const struct spi_controller_mem_ops fsl_espi_mem_ops = {
+   .adjust_op_size = fsl_espi_adjust_op_size,
+   .exec_op = fsl_espi_exec_op,
+};
+
 static int fsl_espi_probe(struct device *dev, struct resource *mem,
  unsigned int irq, unsigned int num_cs)
 {
@@ -682,6 +706,7 @@ static int fsl_espi_probe(struct device *dev, struct 
resource *mem,
master->auto_runtime_pm = true;
master->max_message_size = fsl_espi_max_message_size;
master->num_chipselect = num_cs;
+   master->mem_ops = &fsl_espi_mem_ops;
 
espi = spi_master_get_devdata(master);
spin_lock_init(&espi->lock);
-- 
2.7.4

Re: [PATCH 3.18 00/15] 3.18.119-stable review

[Greg Kroah-Hartman]

On Thu, Aug 16, 2018 at 12:44:40PM -0700, Nathan Chancellor wrote:
> On Thu, Aug 16, 2018 at 08:41:37PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.119 release.
> > There are 15 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Aug 18 17:16:20 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.119-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Merged, compiled with -Werror, and installed onto my Pixel XL.
> 
> No initial issues noticed in dmesg or general usage.

Thanks for testing two of these and letting me know.

greg k-h

Query on shrink list

[Mukesh Ojha]

Hi Al Viro,

Is there is reason we have kept data->found++, if the dentry already 
there in shrink list ?


static enum d_walk_ret select_collect(
...
    if (dentry->d_flags & DCACHE_SHRINK_LIST) {
    data->found++;
    } else {
  ..

If the dentry is already there on shrink list, does it not mean that 
data->found is already non-zero ?

Can't we just go out from here directly?


Regards,
Mukesh

[PATCH] linux/compiler.h: don't use bool

[Rasmus Villemoes]

Appararently, it's possible to have a non-trivial TU include a few headers,
including linux/build_bug.h, without ending up with linux/types.h. So
the 0day bot sent me

config: um-x86_64_defconfig (attached as .config)

>> include/linux/compiler.h:316:3: error: unknown type name 'bool'; did you 
>> mean '_Bool'?
  bool __cond = !(condition);\

for something I'm working on.

Rather than contributing to the #include madness and including
linux/types.h from compiler.h, just use int.

Signed-off-by: Rasmus Villemoes 
---
 include/linux/compiler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 42506e4d1f53..c8eab637a2a7 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -313,7 +313,7 @@ unsigned long read_word_at_a_time(const void *addr)
 #ifdef __OPTIMIZE__
 # define __compiletime_assert(condition, msg, prefix, suffix)  \
do {\
-   bool __cond = !(condition); \
+   int __cond = !(condition);  \
extern void prefix ## suffix(void) __compiletime_error(msg); \
if (__cond) \
prefix ## suffix(); \
-- 
2.16.4

Re: [RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

[Hari Vyas]

On Fri, Aug 17, 2018 at 3:09 PM, Benjamin Herrenschmidt
 wrote:
> On Fri, 2018-08-17 at 14:30 +0530, Hari Vyas wrote:
>> So many mail threads for common issues going so just trying to
>> summarize concern from my side.
>> 1) HW level
>> PCI Config data overwritten (ex: PCI_COMMAND bits etc) was happening
>> at lower layer so from my
>> perspective, it is best to handle concern at lower level with locking
>> mechanism and that is what
>> I proposed in my upcoming patch. Without that, I guess, we may end up
>> in issues later with some weird scenario
>> which may not be known today  and we will again be fine tuning stuff
>> here and there.
>
> Maybe... at this point I'm not trying to address that specific issue.
> That being said, the PCI_COMMAND register should be under control of
> the driver at runtime and thus shouldn't be exposed to races like that
> except in the usual case of races in configuring bridges. Those races
> definitely need to be handled at the higher level.
>
> So I'm rather dubious of adding a whole new layer of "modify" callbacks
> to config space accessors for that, especially since they won't do any
> good on architectures with lockless config accesses such as ... x86
>
modify() is optional.  host/controller layers may override it.
It was just a proposal to avoid race issues which happens in SMP environment and
solves other issues. I agree, nothing great anyhow can be done in
lockless config

>> 2) SW level(internal data structure):
>> About is_added,is_busmaster: These all are bit fields so infact I too
>> suggested to remove those bit fields and
>> make separate variables in pci_dev structure.
>> This will avoid all data-overwritten,concurrency issues but ofcourse
>> at the level of space cost.
>
> It's unnecessary to do blanket changes without first understanding the
> details of what's going on. A lot of these things are never touched
> outside of the overall single threaded environment of
> discovery/assignment or under driver control, in which case it's
> expectd that the driver doesn't call them in racy ways
>
> That said, I'm happy to move some of them under my proposed
> dev_state_lock.
>
> For is_added specifically, the field is simply set at the wrong time as
> you can see in my previous patch.
>
Issue needs to be addressed and that is our goal.
Some times simple mistakes need lot of debugging which happened in my case and
my suggestion is to just avoid. SMP related issues are popping up now
so we just need
to be careful.
>> Other possibility will be either to use atomic
>
> Atomic is almost always wrong. It doesn't synchronize anything other
> than the field, so either it's a big waste of it gives a false sense of
> security for something that's almost always still racy.
>
> I'd rather keep the indication that a bunch of those fields *are*
> unprotected and rely on the outer layers being single threaded.
>
>>  or locking mechanism
>> for these. My point here is also same, better
>> avoid fine tuning later stage.
>> Moving is_added up and down doesn't look like good as we are just
>> shifting issue up and down.
>
> No, you are wrong. I also originally covered is_added with my new mutex
> but in hindsight it's the wrong thing to do, and went back to the
> correct fix at this point which is precisely to move it up.
>
> is_added is essentially owned by the part of the PCI probe code that
> runs single threaded before the device gets exposed to the device
> model.
>
> Pretty much all of the code, including all the corresponding fields
> (struct resources etc...) in pci_dev are unprotected and rely on being
> accessed in a single threaded manner. is_added is no exception.
>
> It was simply a mistake to set it after device_attach().
>
> Thus moving it back up fixes it *correctly* by making it follow the
> same rules as all the related fields.
>
> That said, if we want to start adding protection to all those other
> fields, then this is a different matter alltogether. But at this point,
> this is the best fix for the problem at hand.
>
>> Please check and decide accordingly. I will hold my to-be-submitted
>> modify() patch about handling hw level
>> over-written case with locking around read-write operation.
>
> Can you remind us in this thread which specific cases of RMW races of
> config space you were trying to address ?
>
Same pci bridge master, memory bit setting concern only (which my
colleague Srinath figured
out after lot of effort some time back) where only one bit in
PCI_COMMAND  was getting set.
(Bug 200793 - PCI: read-write config operation doesn't look like SMP safe)
My approach is to handle with modify operations at lower level so bits
are not over-written or lost.


As stated earlier, issue should be just resolved in better way. No
issue in going with majority
Regards,
hari
> Cheers,
> Ben.
>
>

Re: [PATCH v10 00/10] livepatch: Atomic replace feature

[Evgenii Shatokhin]

Hi,

On 07.03.2018 11:20, Petr Mladek wrote:

The atomic replace allows to create cumulative patches. They
are useful when you maintain many livepatches and want to remove
one that is lower on the stack. In addition it is very useful when
more patches touch the same function and there are dependencies
between them.


Could you tell me what is the current status of this series? Looks like 
I lost track of it.


Is there anything else that should be done here before this series could 
be merged?





Changes against v9:

   + Fixed check of valid NOPs for already loaded objects,
 regression introduced in v9 [Joe, Mirek]
   + Allow to replace even disabled patches [Evgenii]

Changes against v8:

   + Fixed handling of statically defined struct klp_object
 with empty array of functions [Joe, Mirek]
   + Removed redundant func->new_func assignment for NOPs [Mirek]
   + Improved some wording [Mirek]

Changes against v7:

   + Fixed handling of NOPs for not-yet-loaded modules
   + Made klp_replaced_patches list static [Mirek]
   + Made klp_free_object() public later [Mirek]
   + Fixed several reported typos [Mirek, Joe]
   + Updated documentation according to the feedback [Joe]
   + Added some Acks [Mirek]

Changes against v6:

   + used list_move when disabling replaced patches [Jason]
   + renamed KLP_FUNC_ORIGINAL -> KLP_FUNC_STATIC [Mirek]
   + used klp_is_func_type() in klp_unpatch_object() [Mirek]
   + moved static definition of klp_get_or_add_object() [Mirek]
   + updated comment about synchronization in forced mode [Mirek]
   + added user documentation
   + fixed several typos


Jason Baron (5):
   livepatch: Use lists to manage patches, objects and functions
   livepatch: Initial support for dynamic structures
   livepatch: Allow to unpatch only functions of the given type
   livepatch: Support separate list for replaced patches.
   livepatch: Add atomic replace

Petr Mladek (5):
   livepatch: Free only structures with initialized kobject
   livepatch: Correctly handle atomic replace for not yet loaded modules
   livepatch: Improve dynamic struct klp_object detection and
 manipulation
   livepatch: Allow to replace even disabled patches
   livepatch: Atomic replace and cumulative patches documentation

  Documentation/livepatch/cumulative-patches.txt |  83 +
  include/linux/livepatch.h  |  65 +++-
  kernel/livepatch/core.c| 422 ++---
  kernel/livepatch/core.h|   4 +
  kernel/livepatch/patch.c   |  31 +-
  kernel/livepatch/patch.h   |   4 +-
  kernel/livepatch/transition.c  |  41 ++-
  7 files changed, 598 insertions(+), 52 deletions(-)
  create mode 100644 Documentation/livepatch/cumulative-patches.txt



Regards,
Evgenii

[GIT PULL] MMC updates for v4.19

[Ulf Hansson]

Hi Linus,

Here's a PR with the updates for MMC for v4.19. Details about the highlights are
as usual found in the signed tag.

Note, this time I have also merged an immutable branch/tag for switching the
pxa platforms to DMA slave maps, by Robert Jarzmik. This was needed due to
dependency for additional changes of the pxamci mmc driver.

Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit 3b1074bf9817bf43d4da375aa5f4b6c88f1d953e:

  mmc: mxcmmc: Fix missing parentheses and brace (2018-07-16 11:45:44 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.19

for you to fetch changes up to 7f38abf220e2c800a2c451372e9f07ed5fd0ea49:

  mmc: core: improve reasonableness of bus width setting for HS400es 
(2018-08-01 14:15:28 +0200)


MMC core:
 - Add some fine-grained hooks to further support HS400 tuning
 - Improve error path for bus width setting for HS400es
 - Use a common method when checking R1 status

MMC host:
 - renesas_sdhi: Add r8a77990 support
 - renesas_sdhi: Add eMMC HS400 mode support
 - tmio/renesas_sdhi: Improve tuning/clock management
 - tmio: Add eMMC HS400 mode support
 - sunxi: Add support for 3.3V eMMC DDR mode
 - mmci: Initial support to manage variant specific callbacks
 - sdhci: Don't try 3.3V I/O voltage if not supported
 - sdhci-pci-dwc-mshc: Add driver to support Synopsys dwc mshc SDHCI PCI
 - sdhci-of-dwcmshc: Add driver to support Synopsys DWC MSHC SDHCI
 - sdhci-msm: Add support for new version sdcc V5
 - sdhci-pci-o2micro: Add support for O2 eMMC HS200 mode
 - sdhci-pci-o2micro: Add support for O2 hardware tuning
 - sdhci-pci-o2micro: Add MSI interrupt support for O2 SD host
 - sdhci-pci: Add support for Intel ICP
 - sdhci-tegra: Prevent ACMD23 and HS200 mode on Tegra 3
 - sdhci-tegra: Fix eMMC DDR52 mode
 - sdhci-tegra: Improve clock management
 - dw_mmc-rockchip: Document compatible string for px30
 - sdhci-esdhc-imx: Add support for 3.3V eMMC DDR mode
 - sdhci-of-esdhc: Set proper DMA mask for ls104x chips
 - sdhci-of-esdhc: Improve clock management
 - sdhci-of-arasan: Add a quirk to manage unstable clocks
 - dw_mmc-exynos: Address potential external abort during system resume
 - pxamci: Add support for common MMC DT bindings
 - pxamci: Several cleanups and improvements
 - pxamci: Merge immutable branch for pxa to switch to DMA slave maps


Aapo Vienamo (3):
  mmc: tegra: Use sdhci_pltfm_clk_get_max_clock
  mmc: tegra: Add and use tegra_sdhci_get_max_clock()
  mmc: tegra: Force correct divider calculation on DDR50/52

Adrian Hunter (1):
  mmc: sdhci-pci: Add support for Intel ICP

Andre Przywara (1):
  mmc: sunxi: remove output of virtual base address

Daniel Mack (9):
  mmc: pxamci: remove irq from private context
  mmc: pxamci: remove dma resources from private context
  mmc: pxamci: remove dead code from pxamci_remove()
  mmc: pxamci: fix indenting
  mmc: pxamci: call mmc_of_parse()
  mmc: pxamci: remove pxa-mmc, gpio-power from devicetree bindings
  mmc: pxamci: let mmc core handle regulators
  mmc: pxamci: make GPIO lookups from pdata optional
  mmc: pxamci: provide a short-hand for &pdev->dev

Fabio Estevam (1):
  mmc: sdhci-esdhc-imx: Switch to SPDX identifier

Gustavo A. R. Silva (1):
  mmc: sdhci-xenon: mark expected switch fall-through

Helmut Grohne (2):
  dt-bindings: mmc: broken clock stable indicator on arasan controllers
  mmc: sdhci-of-arasan: Add quirk for unstable clocks

Hongjie Fang (1):
  mmc: core: improve reasonableness of bus width setting for HS400es

Icenowy Zheng (1):
  mmc: sunxi: allow 3.3V DDR when DDR is available

Jisheng Zhang (2):
  dt: bindings: Add bindings for SDHCI Synopsys DWC MSHC
  mmc: sdhci-of-dwcmshc: add SDHCI OF Synopsys DWC MSHC driver

Laurentiu Tudor (1):
  mmc: sdhci-of-esdhc: set proper dma mask for ls104x chips

Liang Chen (1):
  dt-bindings: mmc: rockchip-dw-mshc: add description for px30

Marek Szyprowski (1):
  mmc: dw_mmc-exynos: fix potential external abort in resume_noirq()

Masaharu Hayakawa (3):
  mmc: tmio: add eMMC HS400 mode support
  mmc: renesas_sdhi: add eMMC HS400 mode support
  mmc: tmio: Fix tuning flow

Masahiro Yamada (1):
  mmc: tmio: remove unneeded variable in tmio_mmc_start_command()

Niklas S??derlund (1):
  mmc: renesas_sdhi: Fix sampling clock position selecting

Prabu Thangamuthu (1):
  mmc: sdhci-pci-dwc-mshc: synopsys dwc mshc support

Robert Jarzmik (10):
  dmaengine: pxa: use a dma slave map
  ARM: pxa: add dma slave map
  dmaengine: pxa: add a default requestor policy
  mmc: pxamci: remove the dmaengine compat need
  media: pxa_camera: remove the dmaengine compat need
  mtd: rawnand: marvell: remove the dmaengine compat need
   

[PATCH v2 0/3] arm64 live patching

[Torsten Duwe]

Hi all!

Here's v2; I hope I have incorporated all feedback properly.
Julien: #S_X28 + 8 is in, but ftrace_modify_call() is referenced
from generic code: kernel/trace/ftrace.c __ftrace_replace_code()

And I'd *really* like some feedback from ARM/Linaro/... on the stack
unwinder!

[Changes from v1]:

* Missing compiler support is now a Makefile error, instead
  of a warning. This will keep the compile log shorter and
  it will thus be easier to spot the problem.

* A separate ftrace_regs_caller. Only that one will write out
  a complete pt_regs, for efficiency.

* Replace the use of X19 with X28 to remember the old PC during
  live patch detection, as only that is saved&restored now for
  non-regs ftrace.

* CONFIG_DYNAMIC_FTRACE_WITH_REGS and CC_USING_PATCHABLE_FUNCTION_ENTRY
  are currently synonymous on arm64, but differentiate better for
  the future when this is no longer the case.

* Clean up "old"/"new" insn value setting vs. #ifdefs.

* #define a INSN_MOV_X9_X30 with suggested aarch64_insn_gen call
  and use that instead of an immediate hex value.

Torsten

Re: [RFC PATCH 5/6] pci: Protect the enable/disable state of pci_dev using the state mutex

[Benjamin Herrenschmidt]

On Fri, 2018-08-17 at 15:40 +0530, Hari Vyas wrote:
> 
> > So I'm rather dubious of adding a whole new layer of "modify" callbacks
> > to config space accessors for that, especially since they won't do any
> > good on architectures with lockless config accesses such as ... x86
> > 
> 
> modify() is optional.  host/controller layers may override it.
> It was just a proposal to avoid race issues which happens in SMP environment 
> and
> solves other issues. I agree, nothing great anyhow can be done in
> lockless config

Right so let's not go down the path of creating low level accessors
providing a semantic that cannot actually be provided by some
architectures :-)

> > > 2) SW level(internal data structure):
> > > About is_added,is_busmaster: These all are bit fields so infact I too
> > > suggested to remove those bit fields and
> > > make separate variables in pci_dev structure.
> > > This will avoid all data-overwritten,concurrency issues but ofcourse
> > > at the level of space cost.
> > 
> > It's unnecessary to do blanket changes without first understanding the
> > details of what's going on. A lot of these things are never touched
> > outside of the overall single threaded environment of
> > discovery/assignment or under driver control, in which case it's
> > expectd that the driver doesn't call them in racy ways
> > 
> > That said, I'm happy to move some of them under my proposed
> > dev_state_lock.
> > 
> > For is_added specifically, the field is simply set at the wrong time as
> > you can see in my previous patch.
> > 
> Issue needs to be addressed and that is our goal.

Yes.

> Some times simple mistakes need lot of debugging which happened in my case and
> my suggestion is to just avoid. SMP related issues are popping up now
> so we just need to be careful.

Oh I agree, and I took me a while to re-debug independently some of the
issues on my side too :-) I should be clearer that I very much do
appreciate your debugging work and finding those problems !

I might disagree on the solution but your effort is very valuable and
I'm sure we can converge on a solution that works for everybody.

 .../...

> > Can you remind us in this thread which specific cases of RMW races of
> > config space you were trying to address ?
> > 
> 
> Same pci bridge master, memory bit setting concern only (which my
> colleague Srinath figured out after lot of effort some time back) where only 
> one bit in
> PCI_COMMAND  was getting set.
> (Bug 200793 - PCI: read-write config operation doesn't look like SMP safe)
> My approach is to handle with modify operations at lower level so bits
> are not over-written or lost.

Right so those are the same old races with pci_set_master() on the
bridge upward chain ?

If yes then this should be addressed by my patches but there are still
some debate about whether to add that new mutex or try to use an
existing one, so let's see what Bjorn has to say.

I think the set-master and enable/disable issues are intimately related
and should be solved together by some higher level locking.

This is a typical case where the "atomic" enable_cnt provided people
with a false sense of safety while the code in practice was still
completely racy.

> As stated earlier, issue should be just resolved in better way. No
> issue in going with majority

Hehe, ok. I think the is_added fix is simply to move it up since it
matches the rest of the code in that area, but let's see what Bjorn has
to say in that regard.

As for the enable/disable/set_master races, Ive wrote my arguments in
favor of a dedicated lock, let's see what others have to respond.

Cheers,
Ben.

> Regards,
> hari
> > Cheers,
> > Ben.
> > 
> > 

[PATCH v2 2/3] arm64: implement live patching

[Torsten Duwe]

Based on ftrace with regs, do the usual thing. Also allocate a
task flag for whatever consistency handling will be used.
Watch out for interactions with the graph tracer.

Signed-off-by: Torsten Duwe 

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -119,6 +119,7 @@ config ARM64
select HAVE_GENERIC_DMA_COHERENT
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_IRQ_TIME_ACCOUNTING
+   select HAVE_LIVEPATCH
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP if NUMA
select HAVE_NMI
@@ -1349,4 +1350,6 @@ if CRYPTO
 source "arch/arm64/crypto/Kconfig"
 endif
 
+source "kernel/livepatch/Kconfig"
+
 source "lib/Kconfig"
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -76,6 +76,7 @@ void arch_release_task_struct(struct tas
 #define TIF_FOREIGN_FPSTATE3   /* CPU's FP state is not current's */
 #define TIF_UPROBE 4   /* uprobe breakpoint or singlestep */
 #define TIF_FSCHECK5   /* Check FS is USER_DS on return */
+#define TIF_PATCH_PENDING  6
 #define TIF_NOHZ   7
 #define TIF_SYSCALL_TRACE  8
 #define TIF_SYSCALL_AUDIT  9
@@ -94,6 +95,7 @@ void arch_release_task_struct(struct tas
 #define _TIF_NEED_RESCHED  (1 << TIF_NEED_RESCHED)
 #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
 #define _TIF_FOREIGN_FPSTATE   (1 << TIF_FOREIGN_FPSTATE)
+#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
 #define _TIF_NOHZ  (1 << TIF_NOHZ)
 #define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
 #define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
@@ -106,7 +108,8 @@ void arch_release_task_struct(struct tas
 
 #define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
 _TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \
-_TIF_UPROBE | _TIF_FSCHECK)
+_TIF_UPROBE | _TIF_FSCHECK | \
+_TIF_PATCH_PENDING)
 
 #define _TIF_SYSCALL_WORK  (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
 _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \
--- /dev/null
+++ b/arch/arm64/include/asm/livepatch.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * livepatch.h - arm64-specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2016,2018 SUSE
+ *
+ * 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 .
+ */
+#ifndef _ASM_ARM64_LIVEPATCH_H
+#define _ASM_ARM64_LIVEPATCH_H
+
+#include 
+#include 
+
+#ifdef CONFIG_LIVEPATCH
+static inline int klp_check_compiler_support(void)
+{
+   return 0;
+}
+
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+   regs->pc = ip;
+}
+#endif /* CONFIG_LIVEPATCH */
+
+#endif /* _ASM_ARM64_LIVEPATCH_H */
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -209,6 +209,9 @@ ftrace_common:
str x9, [sp, #S_LR]
/* The program counter just after the ftrace call site */
str lr, [sp, #S_PC]
+#if defined(CONFIG_LIVEPATCH) && defined(CONFIG_FUNCTION_GRAPH_TRACER)
+   mov x28,lr  /* remember old return address */
+#endif
/* The stack pointer as it was on ftrace_caller entry... */
add x29, sp, #S_FRAME_SIZE+16   /* ...is also our new FP */
str x29, [sp, #S_SP]
@@ -224,6 +227,16 @@ ftrace_call:
 
bl  ftrace_stub
 
+#if defined(CONFIG_LIVEPATCH) && defined(CONFIG_FUNCTION_GRAPH_TRACER)
+   /* Is the trace function a live patcher an has messed with
+* the return address?
+   */
+   ldr x9, [sp, #S_PC]
+   cmp x9, x28 /* compare with the value we remembered */
+   /* to not call graph tracer's "call" mechanism twice! */
+   b.neftrace_common_return
+#endif
+
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
.global ftrace_graph_call
 ftrace_graph_call: // ftrace_graph_caller();

[PATCH v2 3/3] arm64: reliable stacktraces

[Torsten Duwe]

This is more an RFC in the original sense: is this basically
the correct approach? (as I had to tweak the save_stack API a bit).

In particular the code does not detect interrupts and exception
frames, and does not yet check whether the code address is valid.
The latter check would also have to be omitted for the latest frame
on other tasks' stacks. This would require some more tweaking.

unwind_frame() now reports whether we had to stop normally or due to
an error condition; walk_stackframe() will pass that info.
__save_stack_trace() is used for a start to check the validity of a
frame; maybe save_stack_trace_tsk_reliable() will need its own callback.

The question is whether this change, once complete, is sufficient
(as on powerpc) or whether a port of objtool is needed, like x86.

I can dig into this myself and draw conclusions, but I'd prefer
to have some input from ARM people here...

Signed-off-by: Torsten Duwe 

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -127,8 +127,9 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
-   select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
+   select HAVE_REGS_AND_STACK_ACCESS_API
+   select HAVE_RELIABLE_STACKTRACE
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -33,7 +33,7 @@ struct stackframe {
 };
 
 extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
-extern void walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
+extern int walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
int (*fn)(struct stackframe *, void *), void *data);
 extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk);
 
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d5718a060672..fe0dd4745ff3 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -81,23 +81,27 @@ int notrace unwind_frame(struct task_struct *tsk, struct 
stackframe *frame)
 * both are NULL.
 */
if (!frame->fp && !frame->pc)
-   return -EINVAL;
+   return 1;
 
return 0;
 }
 
-void notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
+int notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
 int (*fn)(struct stackframe *, void *), void *data)
 {
while (1) {
int ret;
 
-   if (fn(frame, data))
-   break;
+   ret = fn(frame, data);
+   if (ret)
+   return ret;
ret = unwind_frame(tsk, frame);
if (ret < 0)
+   return ret;
+   if (ret > 0)
break;
}
+   return 0;
 }
 
 #ifdef CONFIG_STACKTRACE
@@ -145,14 +149,15 @@ void save_stack_trace_regs(struct pt_regs *regs, struct 
stack_trace *trace)
trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
-static noinline void __save_stack_trace(struct task_struct *tsk,
+static noinline int __save_stack_trace(struct task_struct *tsk,
struct stack_trace *trace, unsigned int nosched)
 {
struct stack_trace_data data;
struct stackframe frame;
+   int ret;
 
if (!try_get_task_stack(tsk))
-   return;
+   return -EBUSY;
 
data.trace = trace;
data.skip = trace->skip;
@@ -171,11 +176,12 @@ static noinline void __save_stack_trace(struct 
task_struct *tsk,
frame.graph = tsk->curr_ret_stack;
 #endif
 
-   walk_stackframe(tsk, &frame, save_trace, &data);
+   ret = walk_stackframe(tsk, &frame, save_trace, &data);
if (trace->nr_entries < trace->max_entries)
trace->entries[trace->nr_entries++] = ULONG_MAX;
 
put_task_stack(tsk);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
 
@@ -190,4 +196,12 @@ void save_stack_trace(struct stack_trace *trace)
 }
 
 EXPORT_SYMBOL_GPL(save_stack_trace);
+
+int save_stack_trace_tsk_reliable(struct task_struct *tsk,
+ struct stack_trace *trace)
+{
+   return __save_stack_trace(tsk, trace, 1);
+}
+EXPORT_SYMBOL_GPL(save_stack_trace_tsk_reliable);
+
 #endif

[PATCH v2 1/3] arm64: implement ftrace with regs

[Torsten Duwe]

Check for compiler support of -fpatchable-function-entry and use it
to intercept functions immediately on entry, saving the LR in x9.
Disable ftracing in efi/libstub, because this triggers cross-section
linker errors now (-pg is disabled already for those files).
Add an ftrace_caller which can handle LR in x9, as well as an
ftrace_regs_caller that additionally writes out a set of pt_regs
for inspection.

Signed-off-by: Torsten Duwe 

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -110,6 +110,7 @@ config ARM64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
+   select HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_EFFICIENT_UNALIGNED_ACCESS
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_TRACER
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -78,6 +78,15 @@ ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
 KBUILD_LDFLAGS_MODULE  += -T $(srctree)/arch/arm64/kernel/module.lds
 endif
 
+ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+  CC_FLAGS_FTRACE := -fpatchable-function-entry=2
+  KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
+  ifeq ($(call cc-option,-fpatchable-function-entry=2),)
+$(error Cannot use CONFIG_DYNAMIC_FTRACE_WITH_REGS: \
+ -fpatchable-function-entry not supported by compiler)
+  endif
+endif
+
 # Default value
 head-y := arch/arm64/kernel/head.o
 
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -16,6 +16,13 @@
 #define MCOUNT_ADDR((unsigned long)_mcount)
 #define MCOUNT_INSN_SIZE   AARCH64_INSN_SIZE
 
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+#define ARCH_SUPPORTS_FTRACE_OPS 1
+#define REC_IP_BRANCH_OFFSET 4
+#else
+#define REC_IP_BRANCH_OFFSET 0
+#endif
+
 #ifndef __ASSEMBLY__
 #include 
 
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -7,9 +7,9 @@ CPPFLAGS_vmlinux.lds:= -DTEXT_OFFSET=$(
 AFLAGS_head.o  := -DTEXT_OFFSET=$(TEXT_OFFSET)
 CFLAGS_armv8_deprecated.o := -I$(src)
 
-CFLAGS_REMOVE_ftrace.o = -pg
-CFLAGS_REMOVE_insn.o = -pg
-CFLAGS_REMOVE_return_address.o = -pg
+CFLAGS_REMOVE_ftrace.o = -pg $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_insn.o = -pg $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_return_address.o = -pg $(CC_FLAGS_FTRACE)
 
 # Object file lists.
 arm64-obj-y:= debug-monitors.o entry.o irq.o fpsimd.o  
\
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -11,7 +11,8 @@ cflags-$(CONFIG_X86)  += -m$(BITS) -D__K
   -fPIC -fno-strict-aliasing -mno-red-zone \
   -mno-mmx -mno-sse -fshort-wchar
 
-cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
+cflags-$(CONFIG_ARM64) := $(filter-out -pg $(CC_FLAGS_FTRACE)\
+ ,$(KBUILD_CFLAGS)) -fpie
 cflags-$(CONFIG_ARM)   := $(subst -pg,,$(KBUILD_CFLAGS)) \
   -fno-builtin -fpic -mno-single-pic-base
 
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * Gcc with -pg will put the following code in the beginning of each function:
@@ -123,6 +125,7 @@ skip_ftrace_call:   // }
 ENDPROC(_mcount)
 
 #else /* CONFIG_DYNAMIC_FTRACE */
+#ifndef CC_USING_PATCHABLE_FUNCTION_ENTRY
 /*
  * _mcount() is used to build the kernel with -pg option, but all the branch
  * instructions to _mcount() are replaced to NOP initially at kernel start up,
@@ -162,6 +165,88 @@ ftrace_graph_call: // ftrace_graph_cal
 
mcount_exit
 ENDPROC(ftrace_caller)
+#else /* CC_USING_PATCHABLE_FUNCTION_ENTRY */
+ENTRY(_mcount)
+   mov x10, lr
+   mov lr, x9
+   ret x10
+ENDPROC(_mcount)
+
+ENTRY(ftrace_regs_caller)
+   stp x29, x9, [sp, #-16]!
+   sub sp, sp, #S_FRAME_SIZE
+
+   stp x10, x11, [sp, #80]
+   stp x12, x13, [sp, #96]
+   stp x14, x15, [sp, #112]
+   stp x16, x17, [sp, #128]
+   stp x18, x19, [sp, #144]
+   stp x20, x21, [sp, #160]
+   stp x22, x23, [sp, #176]
+   stp x24, x25, [sp, #192]
+   stp x26, x27, [sp, #208]
+
+   b   ftrace_common
+ENDPROC(ftrace_regs_caller)
+
+ENTRY(ftrace_caller)
+   stp x29, x9, [sp, #-16]!
+   sub sp, sp, #S_FRAME_SIZE
+
+ftrace_common:
+   stp x28, x29, [sp, #224]
+
+   /* save function arguments */
+   stp x0, x1, [sp]
+   stp x2, x3, [sp, #16]
+   stp x4, x5, [sp, #32]
+   stp x6, x7, [sp, #48]
+   stp x8, x9, [sp, #64]
+
+   /* The link Register at callee entry */
+   str x9, [sp, #S_LR]
+   /* The program counter just after the ftrace call site */
+   str lr, [sp, #S_PC]
+   /* The stack pointer as it was on ftrace_caller entry... */
+   add x29, sp, #S_FRAME_SIZE+16

Re: [PATCH v2] console: Add console=auto option

[Prarit Bhargava]

On 08/17/2018 04:19 AM, Petr Mladek wrote:
> On Thu 2018-08-16 13:39:01, Prarit Bhargava wrote:
>> ACPI may contain an SPCR table that defines a default system console.
>> On ARM if the table is present then the SPCR console is enabled by default.
>> On x86 the SPCR console is used if 'earlycon' (no parameters) is
>> specified as a kernel parameter and is used only as the early console.
>> To use the SPCR data as a console a user must boot with 'earlycon',
>> grep logs & specify a console= kernel parameter, and then reboot again.
>>
>> Add 'console=auto' that enables a firmware or hardware console, and on
>> x86 enable the SPCR console if 'console=auto' is specified.
> 
> I basically like the idea. Just one or two nits below.
> 
> 
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index a32f2a126791..dd057224f33b 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -635,6 +635,7 @@
>>  
>>  hvc  Use the hypervisor console device . This is for
>>  both Xen and PowerPC hypervisors.
>> +auto[X86] Enable ACPI SPCR console
> 
> The "auto" option sounds reasonable. But earlycon does exactly this
> when used without no extra options. I prefer to stay consistent
> with the existing earlycon behavior.

Hi Petr, on x86 earlycon still only enables the early console but does not
enable the console.

> 
> 
>>  If the device connected to the port is not a TTY but a braille
>>  device, prepend "brl," before the device type, for instance
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index 3b20607d581b..fb2616ba3b21 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -1771,3 +1771,8 @@ void __init 
>> arch_reserve_mem_area(acpi_physical_address addr, size_t size)
>>  e820__range_add(addr, size, E820_TYPE_ACPI);
>>  e820__update_table_print();
>>  }
>> +
>> +void __init arch_console_setup(void)
>> +{
>> +acpi_parse_spcr(false, true);
> 
> Just for record. I was curious that this might be called twice
> (also from acpi_boot_init(). But it looks safe after all.
> 

Yes, the console code prevents the same console from being registered twice.

> The trick is in the two bool parameters. One call allows to
> register/enable earlycon and ignores normal console. This other
> call does exactly the opposite. I do not see any unwanted side
> effects.

Thanks.  I'd like to know if you (or anyone else) has strong feelings about
changing the behaviour of earlycon on x86?  I could make it so that specifying
just earlycon would also initialize the console.

P.

> 
> Best Regards,
> Petr
> 

Re: [PATCH] sched/fair: Avoid divide by zero when rebalancing domains

[Matt Fleming]

On Thu, 05 Jul, at 05:54:02PM, Valentin Schneider wrote:
> On 05/07/18 14:27, Matt Fleming wrote:
> > On Thu, 05 Jul, at 11:10:42AM, Valentin Schneider wrote:
> >> Hi,
> >>
> >> On 04/07/18 15:24, Matt Fleming wrote:
> >>> It's possible that the CPU doing nohz idle balance hasn't had its own
> >>> load updated for many seconds. This can lead to huge deltas between
> >>> rq->avg_stamp and rq->clock when rebalancing, and has been seen to
> >>> cause the following crash:
> >>>
> >>>  divide error:  [#1] SMP
> >>>  Call Trace:
> >>>   [] update_sd_lb_stats+0xe8/0x560
> 
> My confusion comes from not seeing where that crash happens. Would you mind
> sharing the associated line number? I can feel the "how did I not see this"
> from there but it can't be helped :(

The divide by zero comes from scale_rt_capacity() where 'total' is a
u64 but gets truncated when passed to div_u64() since the divisor
parameter is u32.

Sure, you could use div64_u64() instead, but the real issue is that
the load hasn't been updated for a very long time and that we're
trying to balance the domains with stale data.

Re: [PATCH] spi: fsl-espi: master->mem_ops is implemented in the controller

[Boris Brezillon]

On Fri, 17 Aug 2018 18:07:05 +0800
Chuanhua Han  wrote:

> The length of the transmitted data needs to be adjusted due to the maximum 
> length limit for espi transmission messages
> 
> Signed-off-by: Chuanhua Han 
> ---
>  drivers/spi/spi-fsl-espi.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
> index 1d332e2..4724127 100644
> --- a/drivers/spi/spi-fsl-espi.c
> +++ b/drivers/spi/spi-fsl-espi.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* eSPI Controller registers */
>  #define ESPI_SPMODE  0x00/* eSPI mode register */
> @@ -659,6 +660,29 @@ static void fsl_espi_init_regs(struct device *dev, bool 
> initial)
>   fsl_espi_write_reg(espi, ESPI_SPMODE, SPMODE_INIT_VAL | SPMODE_ENABLE);
>  }
>  
> +static int fsl_espi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op 
> *op)
> +{
> + if (!mem || !op)
> + return -EINVAL;
> + op->data.nbytes = min3((unsigned long)op->data.nbytes,
> + spi_max_transfer_size(mem->spi),
> + spi_max_message_size(mem->spi) -
> + sizeof(op->cmd.opcode) -
> + op->addr.nbytes -
> + op->dummy.nbytes);

Oops! Looks like I was wrong in my initial review, this code is generic
and should be placed in spi_mem_adjust_op_size() if !ctlr->mem_ops
or !ctlr->mem_ops->exec_op:

int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
{
struct spi_controller *ctlr = mem->spi->controller;

if (ctlr->mem_ops && ctlr->mem_ops->adjust_op_size)
return ctlr->mem_ops->adjust_op_size(mem, op);

if (!ctlr->mem_ops || !ctlr->mem_ops->exec_op)
op->data.nbytes = min3((unsigned long)op->data.nbytes,
   spi_max_transfer_size(mem->spi),
   spi_max_message_size(mem->spi) -
   sizeof(op->cmd.opcode) -
   op->addr.nbytes -
   op->dummy.nbytes);

return 0;
}

Also, you don't seem to check spi_max_message_size(mem->spi) value
before subtracting opcode, addr and dummy bytes.


> + return 0;
> +}
> +
> +static int fsl_espi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static const struct spi_controller_mem_ops fsl_espi_mem_ops = {
> + .adjust_op_size = fsl_espi_adjust_op_size,
> + .exec_op = fsl_espi_exec_op,
> +};
> +
>  static int fsl_espi_probe(struct device *dev, struct resource *mem,
> unsigned int irq, unsigned int num_cs)
>  {
> @@ -682,6 +706,7 @@ static int fsl_espi_probe(struct device *dev, struct 
> resource *mem,
>   master->auto_runtime_pm = true;
>   master->max_message_size = fsl_espi_max_message_size;
>   master->num_chipselect = num_cs;
> + master->mem_ops = &fsl_espi_mem_ops;
>  
>   espi = spi_master_get_devdata(master);
>   spin_lock_init(&espi->lock);

[RFC 02/15] PCI: move pci_scan_bus into callers

[Arnd Bergmann]

There are only two remaining callers of the old pci_scan_bus()
interface. Since we want to expose the pci_host_bridge structure
everywhere and discourage users from calling the old interfaces,
let's move the implementation into the respective callsites.

While this duplicates the source code, it makes the object code
smaller for all users by avoiding the global implementation,
and it allows further cleanup of the two callers.

Signed-off-by: Arnd Bergmann 
---
 arch/sparc/kernel/pcic.c  | 35 ++
 drivers/pci/hotplug/ibmphp_core.c | 35 ++
 drivers/pci/probe.c   | 36 ---
 include/linux/pci.h   |  1 -
 4 files changed, 70 insertions(+), 37 deletions(-)

diff --git a/arch/sparc/kernel/pcic.c b/arch/sparc/kernel/pcic.c
index ee4c9a9a171c..0197b80fe590 100644
--- a/arch/sparc/kernel/pcic.c
+++ b/arch/sparc/kernel/pcic.c
@@ -387,6 +387,41 @@ int __init pcic_probe(void)
return 0;
 }
 
+static struct resource busn_resource = {
+   .name   = "PCI busn",
+   .start  = 0,
+   .end= 255,
+   .flags  = IORESOURCE_BUS,
+};
+
+static struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops,
+   void *sysdata)
+{
+   struct pci_host_bridge *bridge;
+   int error;
+
+   bridge = pci_alloc_host_bridge(0);
+   if (!bridge)
+   return NULL;
+
+   pci_add_resource(&bridge->windows, &ioport_resource);
+   pci_add_resource(&bridge->windows, &iomem_resource);
+   pci_add_resource(&bridge->windows, &busn_resource);
+   bridge->sysdata = sysdata;
+   bridge->busnr = bus;
+   bridge->ops = ops;
+
+   error = pci_scan_root_bus_bridge(bridge);
+   if (error < 0)
+   goto err;
+
+   return bridge->bus;
+
+err_res:
+   pci_free_host_bridge(bridge);
+   return NULL;
+}
+
 static void __init pcic_pbm_scan_bus(struct linux_pcic *pcic)
 {
struct linux_pbm_info *pbm = &pcic->pbm;
diff --git a/drivers/pci/hotplug/ibmphp_core.c 
b/drivers/pci/hotplug/ibmphp_core.c
index 4ea57e9019f1..d35463ee96ba 100644
--- a/drivers/pci/hotplug/ibmphp_core.c
+++ b/drivers/pci/hotplug/ibmphp_core.c
@@ -717,6 +717,41 @@ static void ibm_unconfigure_device(struct pci_func *func)
pci_unlock_rescan_remove();
 }
 
+static struct resource busn_resource = {
+   .name   = "pci busn",
+   .start  = 0,
+   .end= 255,
+   .flags  = IORESOURCE_BUS,
+};
+
+static struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops,
+   void *sysdata)
+{
+   struct pci_host_bridge *bridge;
+   int error;
+
+   bridge = pci_alloc_host_bridge(0);
+   if (!bridge)
+   return NULL;
+
+   pci_add_resource(&bridge->windows, &ioport_resource);
+   pci_add_resource(&bridge->windows, &iomem_resource);
+   pci_add_resource(&bridge->windows, &busn_resource);
+   bridge->sysdata = sysdata;
+   bridge->busnr = bus;
+   bridge->ops = ops;
+
+   error = pci_scan_root_bus_bridge(bridge);
+   if (error < 0)
+   goto err;
+
+   return bridge->bus;
+
+err:
+   pci_free_host_bridge(bridge);
+   return NULL;
+}
+
 /*
  * The following function is to fix kernel bug regarding
  * getting bus entries, here we manually add those primary
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b0f666271245..12c3aa63c34d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -3078,42 +3078,6 @@ struct pci_bus *pci_scan_root_bus(struct device *parent, 
int bus,
 }
 EXPORT_SYMBOL(pci_scan_root_bus);
 
-static struct resource busn_resource = {
-   .name   = "PCI busn",
-   .start  = 0,
-   .end= 255,
-   .flags  = IORESOURCE_BUS,
-};
-
-struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops,
-   void *sysdata)
-{
-   struct pci_host_bridge *bridge;
-   int error;
-
-   bridge = pci_alloc_host_bridge(0);
-   if (!bridge)
-   goto err;
-
-   pci_add_resource(&bridge->windows, &ioport_resource);
-   pci_add_resource(&bridge->windows, &iomem_resource);
-   pci_add_resource(&bridge->windows, &busn_resource);
-   bridge->sysdata = sysdata;
-   bridge->busnr = bus;
-   bridge->ops = ops;
-
-   error = pci_scan_root_bus_bridge(bridge);
-   if (error < 0)
-   goto err;
-
-   return bridge->bus;
-
-err:
-   pci_free_host_bridge(bridge);
-   return NULL;
-}
-EXPORT_SYMBOL(pci_scan_bus);
-
 /**
  * pci_rescan_bus_bridge_resize - Scan a PCI bus for devices
  * @bridge: PCI bridge for the bus to scan
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e72ca8dd6241..d77ce35a2b33 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -905,7 +905,6 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct 
resource *res,
 void pcibios_scan_specific_bus

[RFC 14/15] PCI: make pcibios_root_bridge_prepare a callback

[Arnd Bergmann]

pcibios_root_bridge_prepare() is always used as a per host bridge
function, not per architecture.

Making it a callback in the pci_host_bridge instead lets the host
bridge implementation easily override it, and avoids the checks
in the architecture for which host bridge implementation is being
used.

Alternatively, we could probably just call the pcibios_root_bridge_prepare
after alloc_pci_host_bridge() here and get rid of it as a generic
interface altogether, but doing that has a slightly higher chance
of breaking something subtle.

Signed-off-by: Arnd Bergmann 
---
 arch/arm64/kernel/pci.c  | 18 --
 arch/ia64/pci/pci.c  | 15 ---
 arch/powerpc/kernel/pci-common.c |  9 +
 arch/x86/pci/acpi.c  | 15 ---
 drivers/acpi/pci_root.c  |  1 +
 drivers/pci/probe.c  | 28 
 include/linux/acpi.h |  2 ++
 include/linux/pci.h  |  3 +--
 8 files changed, 37 insertions(+), 54 deletions(-)

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 3d196c68e362..8958a7c32a9f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -71,19 +71,17 @@ int acpi_pci_bus_find_domain_nr(struct pci_bus *bus)
return root->segment;
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
+int acpi_pci_root_bridge_prepare(struct pci_host_bridge *bridge)
 {
-   if (!acpi_disabled) {
-   struct pci_config_window *cfg = bridge->bus->sysdata;
-   struct acpi_device *adev = to_acpi_device(cfg->parent);
-   struct device *bus_dev = &bridge->bus->dev;
+   struct pci_config_window *cfg = bridge->bus->sysdata;
+   struct acpi_device *adev = to_acpi_device(cfg->parent);
+   struct device *bus_dev = &bridge->bus->dev;
 
-   ACPI_COMPANION_SET(&bridge->dev, adev);
-   set_dev_node(bus_dev, acpi_get_node(acpi_device_handle(adev)));
+   ACPI_COMPANION_SET(&bridge->dev, adev);
+   set_dev_node(bus_dev, acpi_get_node(acpi_device_handle(adev)));
 
-   /* Try to assign the IRQ number when probing a new device */
-   bridge->alloc_irq = acpi_pci_irq_enable;
-   }
+   /* Try to assign the IRQ number when probing a new device */
+   bridge->alloc_irq = acpi_pci_irq_enable;
 
return 0;
 }
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 7ccc64d5fe3e..511b8a058d80 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -308,18 +308,11 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
&info->common, &info->controller);
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
+int acpi_pci_root_bridge_prepare(struct pci_host_bridge *bridge)
 {
-   /*
-* We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
-* here, pci_create_root_bus() has been called by someone else and
-* sysdata is likely to be different from what we expect.  Let it go in
-* that case.
-*/
-   if (!bridge->dev.parent) {
-   struct pci_controller *controller = bridge->bus->sysdata;
-   ACPI_COMPANION_SET(&bridge->dev, controller->companion);
-   }
+   struct pci_controller *controller = bridge->bus->sysdata;
+   ACPI_COMPANION_SET(&bridge->dev, controller->companion);
+
return 0;
 }
 
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index afc9598e4349..5e5c6dd7ebe8 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -771,14 +771,6 @@ int pci_proc_domain(struct pci_bus *bus)
return 1;
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
-   if (ppc_md.pcibios_root_bridge_prepare)
-   return ppc_md.pcibios_root_bridge_prepare(bridge);
-
-   return 0;
-}
-
 /* This header fixup will do the resource fixup for all devices as they are
  * probed, but not for bridge ranges
  */
@@ -1612,6 +1604,7 @@ void pcibios_scan_phb(struct pci_controller *hose)
pci_add_resource(&bridge->windows, &hose->busn);
 
bridge->bus_add_device = ppc_md->pcibios_bus_add_device;
+   bridge->prepare = ppc_md->pcibios_root_bridge_prepare;
bridge->dev.parent = hose->parent;
bridge->sysdata = hose;
bridge->busnr = hose->first_busno;
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 5559dcaddd5e..041b2003707c 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -382,18 +382,11 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
return bus;
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
+int acpi_pci_root_bridge_prepare(struct pci_host_bridge *bridge)
 {
-   /*
-* We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
-* here, pci_create_root_bus() has been called 

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Quentin Perret]

Hi Patrick,

On Thursday 09 Aug 2018 at 16:23:13 (+0100), Patrick Bellasi wrote:
> On 09-Aug 11:50, Juri Lelli wrote:
> > On 09/08/18 10:14, Patrick Bellasi wrote:
> > > On 07-Aug 14:35, Juri Lelli wrote:
> > > > On 06/08/18 17:39, Patrick Bellasi wrote:
> 
> [...]
> 
> > > 1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
> > >time parameter to relax this check
> > 
> > It seems to me that this might work well with that the intended usage of
> > the interface that you depict above. SMS only (or any privileged user)
> > will be in control of how groups are configured, so no problem for
> > normal users.
> 
> Yes, well... apart normal users still getting a -ENOSPC is they are
> requesting one of the not pre-configured clamp values. Which is why
> the following bits can be helpful.

So IIUC, normal users would still be free of choosing their clamp values
as long as they choose one in the list of pre-allocated ones ? Is that
correct ?

If yes, that would still let normal users make they tasks look bigger no ?
They could just choose the clamp group with the highest min_clamp or
something. Isn't this a problem too ? I mean, if that can be abused easily,
I'm pretty sure people _will_ abuse it ...

Or maybe I misunderstood something ?

Thanks,
Quentin

Re: [PATCH v2] console: Add console=auto option

[Prarit Bhargava]

On 08/17/2018 05:38 AM, Sergey Senozhatsky wrote:
> On (08/16/18 13:39), Prarit Bhargava wrote:
>>
>> +auto[X86] Enable ACPI SPCR console
>   
>   And arm64?

Hi Sergey, on arm64 if an SPCR is present the early console and console are
initialized by default.  IOW no kernel parameter is necessary to initialize the
console in that case.

> 
> 
> Any chance we can rename param to "spcr" or something more clear?
> To explicitly state what exactly it's going to do. `auto' sounds
> too general and doesn't tell me that much. I'm probably the only
> here who can't see a connection between "auto" and "SPCR", but
> still.

I came up with "auto" because I think it is generic.  I also thought about
"console=fw", or just "console".  If in the future another arch wants to
optionally bring up a firmware or hardware defined console then they could use
auto too.

> 
> One more thing, as far as I can tell, acpi_parse_spcr() can fail
> and return an error. arch_console_setup() hides all errors and
> returns void. Should it return error code?
> 
>   int arch_console_setup(void)
>   {
>   return acpi_parse_spcr(false, true);
>   }
> 
> Or maybe
> 
>   void arch_console_setup(void)
>   {
>   if (acpi_parse_spcr(false, true))
>   pr_err(.);
>   }
> 
> There can be other consoles in the system, logging an error is not
> such a useless thing.

I can make the second change.  The problem (IIRC) with returning an error in an
setup fn is that the rest of the setup functions will not execute.  I don't want
to fail the setup callbacks because of an incorrect SPCR table.

Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong
feelings about changing the behaviour of earlycon on x86?  I could make it so
that specifying just earlycon would also initialize the console.

P.

> 
>   -ss
> 

Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[dkota]

On 2018-08-14 20:33, Mark Brown wrote:

On Tue, Aug 14, 2018 at 02:30:02PM +0530, dk...@codeaurora.org wrote:

On 2018-08-10 22:16, Mark Brown wrote:
> On Fri, Aug 10, 2018 at 09:59:46PM +0530, dk...@codeaurora.org wrote:



> > delay_usecs is for inter-transfer delays within a message rather than
> > after the initial chip select assert (it can be used to keep chip
> > select
> > asserted for longer after the final transfer too).  Obviously this is
> > also something that shouldn't be configured in a driver specific
> > fashion.



> Hmmm ok, so you mean don't send these as controller_data, rather add
> new
> members to the spi_device struct ?


spi_cs_clk_delay -> Adds Delay from CS line toggle to Clock line 
toggle

spi_inter_words_delay -> Adds inter-word delay for each transfer.



Could you please provide more information on accommodating these
parameters in SPI core structures like spi_device or spi_transfer? Why
because these are very
specific to Qualcomm SPI GENI controller.


I'm not sure what specific information you're looking for here - these
things are not obviously specific to your controller, I'm even aware of
other controllers which can do them.

If we define them in spi core framework structures, SPI Slave driver 
will

program and expect it in the SPI transfers.


Sure.


Thanks Brown for clarifying it. As similar fields are not present in the 
spi core framework i thought these are not generic across the 
controllers.

I will add these fields in the SPI core framework structures.

Could you please clarify on below query.


+   mas->cur_speed_hz = spi_slv->max_speed_hz;


Why can't you use clk_get_rate() instead? Or call clk_set_rate() with
the rate you want the master clk to run at and then divide that down
from there?



> Not sure I follow, the intention is to run the controller clock based on
> the slave's max frequency.



That's good. The problem I see is that we have to specify the max
frequency in the controller/bus node, and also in the child/slave
node.
It should only need to be specified in the slave node, so making the
cur_speed_hz equal the max_speed_hz is problematic. The current speed
of
the master should be determined by calling clk_get_rate().


We don't require that the slaves all individually set a speed since it
gets a bit redundant, it should be enough to just use the default the
controller provides.  A bigger problem with this is that the driver
will
never see a transfer which doesn't explicitly have a speed set as the
core will ensure something is set, open coding this logic in every
driver would obviously be tiresome.


clock_get_rate() will returns the rate which got set as per the clock
plan(which was the rounded up frequency) which can be less than or equal
to the requested frequency. For that reason using the cur_speed_hz to
store the requested frequency and skip clock configuration for the
consecutive transfers with same frequency.

--Dilip

Re: [PATCH] intel_punit_ipc: include linux/io.h

[Andy Shevchenko]

On Fri, Aug 17, 2018 at 12:51 PM, Arnd Bergmann  wrote:
> After we stop including linux/irq.h implicitly, we don't see linux/io.h
> in intel_punit_ipc.c, leading to a build failure:
>
> drivers/platform/x86/intel_punit_ipc.c: In function 'ipc_read_status':
> drivers/platform/x86/intel_punit_ipc.c:55:9: error: implicit declaration of 
> function 'readl' [-Werror=implicit-function-declaration]
>
> Add back the include that is clearly needed.
>

Thanks, Randy already sent a patch

> Fixes: 447ae3166702 ("x86: Don't include linux/irq.h from asm/hardirq.h")
> Cc: Nicolai Stange 
> Cc: Thomas Gleixner 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/platform/x86/intel_punit_ipc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/platform/x86/intel_punit_ipc.c 
> b/drivers/platform/x86/intel_punit_ipc.c
> index f1afc0ebbc68..2efeab650345 100644
> --- a/drivers/platform/x86/intel_punit_ipc.c
> +++ b/drivers/platform/x86/intel_punit_ipc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> --
> 2.18.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] console: Add console=auto option

[Sergey Senozhatsky]

Hello,

Cc-ing Peter Zijlstra

  lkml.kernel.org/r/728a8e68-ea4b-4040-a0fc-217df4f19...@redhat.com
  lkml.kernel.org/r/20180817081947.m425gok2ugt7t...@pathway.suse.cz
  lkml.kernel.org/r/00c60dca-60bc-8568-eaa3-d4b0c326c...@redhat.com

On (08/17/18 06:36), Prarit Bhargava wrote:
> On 08/17/2018 05:38 AM, Sergey Senozhatsky wrote:
> > On (08/16/18 13:39), Prarit Bhargava wrote:
> >>
> >> +  auto[X86] Enable ACPI SPCR console
> > 
> > And arm64?
> 
> Hi Sergey, on arm64 if an SPCR is present the early console and console are
> initialized by default.  IOW no kernel parameter is necessary to initialize 
> the
> console in that case.

OK, thanks.

> > Any chance we can rename param to "spcr" or something more clear?
> > To explicitly state what exactly it's going to do. `auto' sounds
> > too general and doesn't tell me that much. I'm probably the only
> > here who can't see a connection between "auto" and "SPCR", but
> > still.
> 
> I came up with "auto" because I think it is generic.  I also thought about
> "console=fw", or just "console".  If in the future another arch wants to
> optionally bring up a firmware or hardware defined console then they could use
> auto too.

Hmm, I see your point.
My [sort of a] problem with "auto" is that it tells me as much as "magic"
[and "magic" tells me almost nothing]. By the way, would be fun if we had
"magic" instead of "auto" all over the kernel

echo "magic" > /sys/bus/usb/./power/control

> > void arch_console_setup(void)
> > {
> > if (acpi_parse_spcr(false, true))
> > pr_err(.);
> > }
> > 
> > There can be other consoles in the system, logging an error is not
> > such a useless thing.
> 
> I can make the second change.  The problem (IIRC) with returning an error in 
> an
> setup fn is that the rest of the setup functions will not execute.  I don't 
> want
> to fail the setup callbacks because of an incorrect SPCR table.

OK, fair enough.
Letting users know that SPCR is incorrect also makes sense, so option #2
I guess is what we want after all.

> Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong
> feelings about changing the behaviour of earlycon on x86?  I could make it so
> that specifying just earlycon would also initialize the console.

x86 people and/or scheduler people might have strong opinions on this.
I Cc-ed Peter Zijlstra; he represents both groups and is known to be
a hardcore earlycon user.

-ss

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Patrick Bellasi]

On 17-Aug 11:34, Quentin Perret wrote:
> Hi Patrick,
> 
> On Thursday 09 Aug 2018 at 16:23:13 (+0100), Patrick Bellasi wrote:
> > On 09-Aug 11:50, Juri Lelli wrote:
> > > On 09/08/18 10:14, Patrick Bellasi wrote:
> > > > On 07-Aug 14:35, Juri Lelli wrote:
> > > > > On 06/08/18 17:39, Patrick Bellasi wrote:
> > 
> > [...]
> > 
> > > > 1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
> > > >time parameter to relax this check
> > > 
> > > It seems to me that this might work well with that the intended usage of
> > > the interface that you depict above. SMS only (or any privileged user)
> > > will be in control of how groups are configured, so no problem for
> > > normal users.
> > 
> > Yes, well... apart normal users still getting a -ENOSPC is they are
> > requesting one of the not pre-configured clamp values. Which is why
> > the following bits can be helpful.
> 
> So IIUC, normal users would still be free of choosing their clamp values
> as long as they choose one in the list of pre-allocated ones ? Is that
> correct ?

No, with the CAP_SYS_NICE/ADMIN guard in place, as discussed above in
point 1, the syscall will just fail for normal users.

Only privileged tasks (i.e. SMS control threads) can change clamp values.

> If yes, that would still let normal users make they tasks look bigger no ?
> They could just choose the clamp group with the highest min_clamp or
> something. Isn't this a problem too ? I mean, if that can be abused easily,
> I'm pretty sure people _will_ abuse it ...

It should not be possible with 1) in place.

However, if the system is booted with that check disabled (e.g. via
kernel boot parameter) that probably means you trust/control your
userspace and don't want to impose restrictions on non privileged
tasks. In this case "abuses" are just "acceptable usages"...

-- 
#include 

Patrick Bellasi

Re: [PATCH] platform/x86: fix intel_punit_ipc.c build errors

[Andy Shevchenko]

On Wed, Aug 15, 2018 at 7:12 PM, Randy Dunlap  wrote:
> From: Randy Dunlap 
>
> Fix build errors by #including .
>
> ../drivers/platform/x86/intel_punit_ipc.c: In function 'ipc_read_status':
> ../drivers/platform/x86/intel_punit_ipc.c:55:2: error: implicit declaration 
> of function 'readl' [-Werror=implicit-function-declaration]
>   return readl(ipcdev->base[type][BASE_IFACE]);
> ../drivers/platform/x86/intel_punit_ipc.c: In function 'ipc_write_cmd':
> ../drivers/platform/x86/intel_punit_ipc.c:60:2: error: implicit declaration 
> of function 'writel' [-Werror=implicit-function-declaration]
>   writel(cmd, ipcdev->base[type][BASE_IFACE]);
>

Thanks, pushed to our for-next queue, with Fixes tag appended.

> Signed-off-by: Randy Dunlap 
> Cc: Zha Qipeng 
> Cc: platform-driver-...@vger.kernel.org
> ---
> Found in linux-next but applies to current mainline also.
>
>  drivers/platform/x86/intel_punit_ipc.c |1 +
>  1 file changed, 1 insertion(+)
>
> --- linux-next-20180815.orig/drivers/platform/x86/intel_punit_ipc.c
> +++ linux-next-20180815/drivers/platform/x86/intel_punit_ipc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
>
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 03/14] sched/core: uclamp: add CPU's clamp groups accounting

[Patrick Bellasi]

On 06-Aug 17:39, Patrick Bellasi wrote:

[...]

> +/**
> + * uclamp_cpu_get_id(): increase reference count for a clamp group on a CPU
> + * @p: the task being enqueued on a CPU
> + * @rq: the CPU's rq where the clamp group has to be reference counted
> + * @clamp_id: the utilization clamp (e.g. min or max utilization) to 
> reference
> + *
> + * Once a task is enqueued on a CPU's RQ, the clamp group currently defined 
> by
> + * the task's uclamp.group_id is reference counted on that CPU.
> + */
> +static inline void uclamp_cpu_get_id(struct task_struct *p,
> +  struct rq *rq, int clamp_id)
> +{
> + struct uclamp_group *uc_grp;
> + struct uclamp_cpu *uc_cpu;
> + int clamp_value;
> + int group_id;
> +
> + /* No task specific clamp values: nothing to do */
> + group_id = p->uclamp[clamp_id].group_id;
> + if (group_id == UCLAMP_NOT_VALID)
> + return;

This is broken for util_max aggression.

By not refcounting tasks without a task specific clamp value, we end
up enforcing a max_util to these tasks when they are co-scheduled with
another max clamped task.

I need to fix this by removing this "optimization" (working just for
util_min) and refcount all the tasks.

> +
> + /* Reference count the task into its current group_id */
> + uc_grp = &rq->uclamp.group[clamp_id][0];
> + uc_grp[group_id].tasks += 1;
> +
> + /*
> +  * If this is the new max utilization clamp value, then we can update
> +  * straight away the CPU clamp value. Otherwise, the current CPU clamp
> +  * value is still valid and we are done.
> +  */
> + uc_cpu = &rq->uclamp;
> + clamp_value = p->uclamp[clamp_id].value;
> + if (uc_cpu->value[clamp_id] < clamp_value)
> + uc_cpu->value[clamp_id] = clamp_value;
> +}
> +

-- 
#include 

Patrick Bellasi

Re: [PATCH v2] console: Add console=auto option

[Prarit Bhargava]

On 08/17/2018 06:50 AM, Sergey Senozhatsky wrote:
> Hello,
> 
> Cc-ing Peter Zijlstra
> 
>   lkml.kernel.org/r/728a8e68-ea4b-4040-a0fc-217df4f19...@redhat.com
>   lkml.kernel.org/r/20180817081947.m425gok2ugt7t...@pathway.suse.cz
>   lkml.kernel.org/r/00c60dca-60bc-8568-eaa3-d4b0c326c...@redhat.com
> 
> On (08/17/18 06:36), Prarit Bhargava wrote:
>> On 08/17/2018 05:38 AM, Sergey Senozhatsky wrote:
>>> On (08/16/18 13:39), Prarit Bhargava wrote:

 +  auto[X86] Enable ACPI SPCR console
>>> 
>>> And arm64?
>>
>> Hi Sergey, on arm64 if an SPCR is present the early console and console are
>> initialized by default.  IOW no kernel parameter is necessary to initialize 
>> the
>> console in that case.
> 
> OK, thanks.
> 
>>> Any chance we can rename param to "spcr" or something more clear?
>>> To explicitly state what exactly it's going to do. `auto' sounds
>>> too general and doesn't tell me that much. I'm probably the only
>>> here who can't see a connection between "auto" and "SPCR", but
>>> still.
>>
>> I came up with "auto" because I think it is generic.  I also thought about
>> "console=fw", or just "console".  If in the future another arch wants to
>> optionally bring up a firmware or hardware defined console then they could 
>> use
>> auto too.
> 
> Hmm, I see your point.
> My [sort of a] problem with "auto" is that it tells me as much as "magic"
> [and "magic" tells me almost nothing]. By the way, would be fun if we had
> "magic" instead of "auto" all over the kernel
> 
>   echo "magic" > /sys/bus/usb/./power/control
> 
>>> void arch_console_setup(void)
>>> {
>>> if (acpi_parse_spcr(false, true))
>>> pr_err(.);
>>> }
>>>
>>> There can be other consoles in the system, logging an error is not
>>> such a useless thing.
>>
>> I can make the second change.  The problem (IIRC) with returning an error in 
>> an
>> setup fn is that the rest of the setup functions will not execute.  I don't 
>> want
>> to fail the setup callbacks because of an incorrect SPCR table.
> 
> OK, fair enough.
> Letting users know that SPCR is incorrect also makes sense, so option #2
> I guess is what we want after all.
> 
>> Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong
>> feelings about changing the behaviour of earlycon on x86?  I could make it so
>> that specifying just earlycon would also initialize the console.
> 
> x86 people and/or scheduler people might have strong opinions on this.
> I Cc-ed Peter Zijlstra; he represents both groups and is known to be
> a hardcore earlycon user.

Thanks, I'm a user of earlycon too, but only moderately.

peterz, to give you an overview:  Currently on x86, the SPCR information is only
interpreted by the early console code, and can be enabled with kernel parameter
"earlycon" (no arguments).  In this patch I'm proposing adding "console=auto"
that would enable the console based on the SPCR data.

There are two options on the table.  One, we could go with this patch which
would make users do "earlycon console=auto" or, I could just change the
behaviour of earlycon (no arguments) to also bring up the console.  In the
second case the kernel parameter would just be "earlycon".  There is precedent
for the second option as arm64 enables both the earlycon and console by default
if SPCR is present.  However, on x86, I know many users do not want the console
enabled by default so we should keep it on demand.

tl;dr: Pick one

Option 1: earlycon enables both the early console and console.
Option 2: earlycon only enables the early console, and console=auto enables the
console.

P.

> 
>   -ss
> 

Re: [PATCH] platform/x86: acer-wmi: Silence "unsupported" message a bit

[Andy Shevchenko]

On Thu, Aug 16, 2018 at 2:27 AM, Benjamin Herrenschmidt
 wrote:
> This driver prints that "Unsupported machine..." message on every boot on
> ThinkPad X1 Carbon laptops (and I assume a number of other systems), which
> causes graphical boots to "glitch" a bit and is rather annoying ...
>
> Make it a pr_debug instead.

Thanks for the patch. Unfortunately it doesn't apply.
Please, check your mail clients and tools for formatting patch (it
produced at the end spaces instead of tabs)

>
> Signed-off-by: Benjamin Herrenschmidt 
> ---
>
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 8952173dd380..7f7192e8fdab 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -2216,7 +2216,7 @@ static int __init acer_wmi_init(void)
> if (wmi_has_guid(AMW0_GUID1) &&
> !dmi_check_system(amw0_whitelist) &&
> quirks == &quirk_unknown) {
> -   pr_err("Unsupported machine has AMW0_GUID1, unable to 
> load\n");
> +   pr_debug("Unsupported machine has AMW0_GUID1, unable to 
> load\n");
> return -ENODEV;
> }
>
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] tty: vt_ioctl: fix potential Spectre v1

[Alan Cox]

On Thu, 16 Aug 2018 15:30:38 -0500
"Gustavo A. R. Silva"  wrote:

> vsa.console is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
> 
> This issue was detected with the help of Smatch:
> 
> drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue
> 'vc_cons' [r]
> 
> Fix this by sanitizing vsa.console before using it to index vc_cons
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Alan Cox 

Alan

Re: [PATCH] platform/x86: acer-wmi: Silence "unsupported" message a bit

[Andy Shevchenko]

On Fri, Aug 17, 2018 at 2:07 PM, Andy Shevchenko
 wrote:
> On Thu, Aug 16, 2018 at 2:27 AM, Benjamin Herrenschmidt
>  wrote:
>> This driver prints that "Unsupported machine..." message on every boot on
>> ThinkPad X1 Carbon laptops (and I assume a number of other systems), which
>> causes graphical boots to "glitch" a bit and is rather annoying ...
>>
>> Make it a pr_debug instead.
>
> Thanks for the patch. Unfortunately it doesn't apply.
> Please, check your mail clients and tools for formatting patch (it
> produced at the end spaces instead of tabs)

No need to resend _this_ time. I have pushed to my review and testing queue.

>>
>> Signed-off-by: Benjamin Herrenschmidt 
>> ---
>>
>> diff --git a/drivers/platform/x86/acer-wmi.c 
>> b/drivers/platform/x86/acer-wmi.c
>> index 8952173dd380..7f7192e8fdab 100644
>> --- a/drivers/platform/x86/acer-wmi.c
>> +++ b/drivers/platform/x86/acer-wmi.c
>> @@ -2216,7 +2216,7 @@ static int __init acer_wmi_init(void)
>> if (wmi_has_guid(AMW0_GUID1) &&
>> !dmi_check_system(amw0_whitelist) &&
>> quirks == &quirk_unknown) {
>> -   pr_err("Unsupported machine has AMW0_GUID1, unable to 
>> load\n");
>> +   pr_debug("Unsupported machine has AMW0_GUID1, unable to 
>> load\n");
>> return -ENODEV;
>> }
>>
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Quentin Perret]

On Friday 17 Aug 2018 at 11:57:31 (+0100), Patrick Bellasi wrote:
> On 17-Aug 11:34, Quentin Perret wrote:
> > Hi Patrick,
> > 
> > On Thursday 09 Aug 2018 at 16:23:13 (+0100), Patrick Bellasi wrote:
> > > On 09-Aug 11:50, Juri Lelli wrote:
> > > > On 09/08/18 10:14, Patrick Bellasi wrote:
> > > > > On 07-Aug 14:35, Juri Lelli wrote:
> > > > > > On 06/08/18 17:39, Patrick Bellasi wrote:
> > > 
> > > [...]
> > > 
> > > > > 1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
> > > > >time parameter to relax this check
> > > > 
> > > > It seems to me that this might work well with that the intended usage of
> > > > the interface that you depict above. SMS only (or any privileged user)
> > > > will be in control of how groups are configured, so no problem for
> > > > normal users.
> > > 
> > > Yes, well... apart normal users still getting a -ENOSPC is they are
> > > requesting one of the not pre-configured clamp values. Which is why
> > > the following bits can be helpful.
> > 
> > So IIUC, normal users would still be free of choosing their clamp values
> > as long as they choose one in the list of pre-allocated ones ? Is that
> > correct ?
> 
> No, with the CAP_SYS_NICE/ADMIN guard in place, as discussed above in
> point 1, the syscall will just fail for normal users.

Right, I just misunderstood then :-)
Sorry for the noise ...

Thanks,
Quentin