Product Inquiry

[Julian Smith]

Hello, 

My name is Ms Julian Smith and i am from Sinara Group Co.
We are glad to know about your company from the web and we are interested in
your products.Please send us your Latest catalog and price list for our
trial order. 

Julian Smith, 
Purchasing Manager
Sinara Group Co.
7 Krasnogo Znameni Ave.
Vladivostok,690106,Ukraine


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

[PATCH 5/6] tty: serial: Add RDA Micro UART driver

[Andreas Färber]

Add "rda" earlycon driver for RDA8810PL UART.

Signed-off-by: Andreas Färber 
---
 Documentation/admin-guide/kernel-parameters.txt |   6 ++
 drivers/tty/serial/Kconfig  |  19 
 drivers/tty/serial/Makefile |   1 +
 drivers/tty/serial/rda-uart.c   | 117 
 4 files changed, 143 insertions(+)
 create mode 100644 drivers/tty/serial/rda-uart.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 0e2091c6fa6b..c97f8b64b3f1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -967,6 +967,12 @@
specified address. The serial port must already be
setup and configured. Options are not yet supported.
 
+   rda,
+   Start an early, polled-mode console on a serial port
+   of an RDA Micro SoC, such as RDA8810PL, at the
+   specified address. The serial port must already be
+   setup and configured. Options are not yet supported.
+
smh Use ARM semihosting calls for early console.
 
s3c2410,
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 1f096e2bb398..25e106a62e06 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1707,6 +1707,25 @@ config SERIAL_OWL_CONSOLE
  Say 'Y' here if you wish to use Actions Semiconductor S500/S900 UART
  as the system console. Only earlycon is implemented currently.
 
+config SERIAL_RDA
+   bool "RDA Micro serial port support"
+   depends on ARCH_RDA || COMPILE_TEST
+   select SERIAL_CORE
+   help
+ This driver is for RDA8810PL SoC's UART.
+ Say 'Y' here if you wish to use the on-board serial port.
+ Otherwise, say 'N'.
+
+config SERIAL_RDA_CONSOLE
+   bool "Console on RDA Micro serial port"
+   depends on SERIAL_RDA=y
+   select SERIAL_CORE_CONSOLE
+   select SERIAL_EARLYCON
+   default y
+   help
+ Say 'Y' here if you wish to use the RDA8810PL UART as the system
+ console. Only earlycon is implemented currently.
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index fe88a75d9a59..87f5a6e1e2d4 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_MVEBU_UART)   += mvebu-uart.o
 obj-$(CONFIG_SERIAL_PIC32) += pic32_uart.o
 obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o
 obj-$(CONFIG_SERIAL_OWL)   += owl-uart.o
+obj-$(CONFIG_SERIAL_RDA)   += rda-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/rda-uart.c b/drivers/tty/serial/rda-uart.c
new file mode 100644
index ..c3c9cf1df015
--- /dev/null
+++ b/drivers/tty/serial/rda-uart.c
@@ -0,0 +1,117 @@
+/*
+ * RDA8810PL serial console
+ *
+ * Copyright RDA Microelectronics Company Limited
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RDA_UART_CTRL  0x00
+#define RDA_UART_STATUS0x04
+#define RDA_UART_RXTX_BUFFER   0x08
+#define RDA_UART_IRQ_MASK  0x0c
+
+#define RDA_UART_STATUS_TX_FIFO_SPACE_MASK (0x1f << 8)
+
+static inline void rda_uart_write(struct uart_port *port, u32 val, unsigned 
int off)
+{
+   writel(val, port->membase + off);
+}
+
+static inline u32 rda_uart_read(struct uart_port *port, unsigned int off)
+{
+   return readl(port->membase + off);
+}
+
+#ifdef CONFIG_SERIAL_RDA_CONSOLE
+
+static void rda_console_putchar(struct uart_port *port, int ch)
+{
+   if (!port->membase)
+   return;
+
+   while (!(rda_uart_read(port, RDA_UART_STATUS) & 
RDA_UART_STATUS_TX_FIFO_SPACE_MASK))
+   cpu_relax();
+
+   rda_uart_write(port, ch, RDA_UART_RXTX_BUFFER);
+}
+
+static void rda_uart_port_write(struct uart_port *port, const char *s,
+   u_int count)
+{
+   u32 old_irq_mask;
+   unsigned long flags;
+   int locked;
+
+   loc

Re: [PATCH v3 0/4] kmod: help make deterministic

[Luis R. Rodriguez]

On Tue, Jun 27, 2017 at 12:44:42AM +0200, Luis R. Rodriguez wrote:
> On Mon, Jun 26, 2017 at 11:37:36PM +0200, Jessica Yu wrote:
> > +++ Kees Cook [20/06/17 17:23 -0700]:
> > > On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez  
> > > wrote:
> > > > On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote:
> > > > > Luis R. Rodriguez (4):
> > > > >   module: use list_for_each_entry_rcu() on find_module_all()
> > > > >   kmod: reduce atomic operations on kmod_concurrent and simplify
> > > > >   kmod: add test driver to stress test the module loader
> > > > >   kmod: throttle kmod thread limit
> > > > 
> > > > About a month now with no further nitpicks. What tree should these 
> > > > changes
> > > > go through if there are no issues? Andrew's, Jessica's ?
> > > 
> > > Seems like going through Jessica's would make the most sense?
> > 
> > Would be happy to take patches 01 (which I need to anyway), 02,
> > possibly 04 if decoupled from the test driver (03).
> 
> Feel free to decouple it, but note that then the commit log must then be
> changed. My own take is this fix is not so critical as it is a corner case, so
> I have instead preferred to couple in the test case and respective fix
> together. I'll leave it up to you how to proceed.

Note: Linus noted swait is actually very special use-case [0] so I'd hate to
add a new use case not vetted for. This use case on kmod.c really does *not*
require anything but a simple wait though, so really am inclined to let that
through unless I hear back...

[0] https://lkml.kernel.org/r/20170627001534.gk21...@wotan.suse.de

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

Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper

[Ram Pai]

On Sun, Jun 25, 2017 at 11:02:58PM -0500, Benjamin Herrenschmidt wrote:
> On Mon, 2017-06-26 at 09:03 +1000, Balbir Singh wrote:
> > On Wed, 2017-06-21 at 18:39 -0700, Ram Pai wrote:
> > > Introduce set_hidx_slot() which sets the (H_PAGE_F_SECOND|H_PAGE_F_GIX)
> > > bits at  the  appropriate  location  in  the  PTE  of  4K  PTE.  In the
> > > case of 64K PTE, it sets the bits in the second part of the PTE. Though
> > > the implementation for the former just needs the slot parameter, it does
> > > take some additional parameters to keep the prototype consistent.
> > > 
> > > This function will come in handy as we  work  towards  re-arranging the
> > > bits in the later patches.
> 
> The name somewhat sucks. Something like pte_set_hash_slot() or
> something like that would be much more meaningful.

ok. pte_set_hash_slot() sounds good.
RP

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

Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper

[Ram Pai]

On Mon, Jun 26, 2017 at 09:03:18AM +1000, Balbir Singh wrote:
> On Wed, 2017-06-21 at 18:39 -0700, Ram Pai wrote:
> > Introduce set_hidx_slot() which sets the (H_PAGE_F_SECOND|H_PAGE_F_GIX)
> > bits at  the  appropriate  location  in  the  PTE  of  4K  PTE.  In the
> > case of 64K PTE, it sets the bits in the second part of the PTE. Though
> > the implementation for the former just needs the slot parameter, it does
> > take some additional parameters to keep the prototype consistent.
> > 
> > This function will come in handy as we  work  towards  re-arranging the
> > bits in the later patches.
> > 
> > Signed-off-by: Ram Pai 
> > ---
> >  arch/powerpc/include/asm/book3s/64/hash-4k.h  |  7 +++
> >  arch/powerpc/include/asm/book3s/64/hash-64k.h | 16 
> >  2 files changed, 23 insertions(+)
> > 
> > diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h 
> > b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > index 9c2c8f1..cef644c 100644
> > --- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > +++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > @@ -55,6 +55,13 @@ static inline int hash__hugepd_ok(hugepd_t hpd)
> >  }
> >  #endif
> >  
> > +static inline unsigned long set_hidx_slot(pte_t *ptep, real_pte_t rpte,
> > +   unsigned int subpg_index, unsigned long slot)
> > +{
> > +   return (slot << H_PAGE_F_GIX_SHIFT) &
> > +   (H_PAGE_F_SECOND | H_PAGE_F_GIX);
> > +}
> > +
> 
> A comment on top would help explain that 4k and 64k are different, 64k
> is a new layout.

ok.

> 
> >  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >  
> >  static inline char *get_hpte_slot_array(pmd_t *pmdp)
> > diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h 
> > b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> > index 3f49941..4bac70a 100644
> > --- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
> > +++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> > @@ -75,6 +75,22 @@ static inline unsigned long __rpte_to_hidx(real_pte_t 
> > rpte, unsigned long index)
> > return (pte_val(rpte.pte) >> H_PAGE_F_GIX_SHIFT) & 0xf;
> >  }
> >  
> > +static inline unsigned long set_hidx_slot(pte_t *ptep, real_pte_t rpte,
> > +   unsigned int subpg_index, unsigned long slot)
> > +{
> > +   unsigned long *hidxp = (unsigned long *)(ptep + PTRS_PER_PTE);
> > +
> > +   rpte.hidx &= ~(0xfUL << (subpg_index << 2));
> > +   *hidxp = rpte.hidx  | (slot << (subpg_index << 2));
> > +   /*
> > +* Avoid race with __real_pte()
> > +* hidx must be committed to memory before committing
> > +* the pte.
> > +*/
> > +   smp_wmb();
> 
> Whats the other paired barrier, is it in set_pte()?

 __real_pte() reads the hidx. The smp_rmb() is in that function.

> 
> > +   return 0x0UL;
> > +}
> 
> We return 0 here and slot information for 4k pages, it is not that
> clear

We return 0 here and commit the 4k-hpte hidx. 


RP

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

Re: [PATCH 2/3] usb: gadget: f_uac*: Reduce code duplication

[kbuild test robot]

Hi Julian,

[auto build test ERROR on balbi-usb/next]
[also build test ERROR on next-20170626]
[cannot apply to v4.12-rc7]
[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/Julian-Scheel/usb-gadget-f_uac1-Fix-endpoint-reading/20170626-202843
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: arm-imx_v6_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> drivers/usb/gadget/legacy/audio.c:24:20: fatal error: u_uac2.h: No such file 
>> or directory
#include "u_uac2.h"
   ^
   compilation terminated.

vim +24 drivers/usb/gadget/legacy/audio.c

c6994e6f drivers/usb/gadget/audio.cBryan Wu  2009-06-03 
 18  #define DRIVER_DESC"Linux USB Audio Gadget"
132fcb46 drivers/usb/gadget/audio.cJassi Brar2012-02-02 
 19  #define DRIVER_VERSION "Feb 2, 2012"
c6994e6f drivers/usb/gadget/audio.cBryan Wu  2009-06-03 
 20  
7d16e8d3 drivers/usb/gadget/audio.cSebastian Andrzej Siewior 2012-09-10 
 21  USB_GADGET_COMPOSITE_OPTIONS();
c6994e6f drivers/usb/gadget/audio.cBryan Wu  2009-06-03 
 22  
0591bc23 drivers/usb/gadget/legacy/audio.c Ruslan Bilovol2017-06-18 
 23  #ifndef CONFIG_GADGET_UAC1
065a107c drivers/usb/gadget/legacy/audio.c Andrzej Pietrasiewicz 2014-07-22 
@24  #include "u_uac2.h"
065a107c drivers/usb/gadget/legacy/audio.c Andrzej Pietrasiewicz 2014-07-22 
 25  
ad94ac0c drivers/usb/gadget/legacy/audio.c Andrzej Pietrasiewicz 2014-07-22 
 26  /* Playback(USB-IN) Default Stereo - Fl/Fr */
065a107c drivers/usb/gadget/legacy/audio.c Andrzej Pietrasiewicz 2014-07-22 
 27  static int p_chmask = UAC2_DEF_PCHMASK;

:: The code at line 24 was first introduced by commit
:: 065a107cdd70f0621011424009b3ecd4e42481b1 usb: gadget: f_uac2: use 
defined constants as defaults

:: TO: Andrzej Pietrasiewicz 
:: CC: Felipe Balbi 

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


.config.gz
Description: application/gzip

Re: [PATCH v3 0/4] kmod: help make deterministic

[Luis R. Rodriguez]

On Mon, Jun 26, 2017 at 11:37:36PM +0200, Jessica Yu wrote:
> +++ Kees Cook [20/06/17 17:23 -0700]:
> > On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez  
> > wrote:
> > > On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote:
> > > > This v3 nukes the proc sysctl interface in favor for just letting 
> > > > userspace
> > > > just check kernel revision. Prior to whenever this is merged userspace 
> > > > should
> > > > try to avoid hammering more than 50 kmod threads as they can fail and 
> > > > it'd
> > > > get -ENOMEM.
> > > > 
> > > > We do away with the old heuristics on assuming you could end up with
> > > > less than max_threads/2 < 50 threads as Dmitry notes this would mean 
> > > > having
> > > > a system with 16 MiB of RAM with modules enabled. It simplifies our 
> > > > patch
> > > > "kmod: reduce atomic operations on kmod_concurrent" considerbly.
> > > > 
> > > > Since the sysctl interface is gone, this no longer depends on any
> > > > other patches, the series is independent. As usual the series is
> > > > available on my linux-next 20170526-kmod-only branch which is based
> > > > on next-20170526.
> > > > 
> > > > [0] 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170526-kmod-only
> > > > 
> > > >   Luis
> > > > 
> > > > Luis R. Rodriguez (4):
> > > >   module: use list_for_each_entry_rcu() on find_module_all()
> > > >   kmod: reduce atomic operations on kmod_concurrent and simplify
> > > >   kmod: add test driver to stress test the module loader
> > > >   kmod: throttle kmod thread limit
> > > 
> > > About a month now with no further nitpicks. What tree should these changes
> > > go through if there are no issues? Andrew's, Jessica's ?
> > 
> > Seems like going through Jessica's would make the most sense?
> 
> Would be happy to take patches 01 (which I need to anyway), 02,
> possibly 04 if decoupled from the test driver (03).

Feel free to decouple it, but note that then the commit log must then be
changed. My own take is this fix is not so critical as it is a corner case, so
I have instead preferred to couple in the test case and respective fix
together. I'll leave it up to you how to proceed.

> I can't take patch 03 through my tree just yet, as I haven't had time to give
> it a look yet :-/

Understood. I'd appreciate at least a review though.

> [ Side comment, it seems that kmod.c isn't directly maintained by anyone
> right now, perhaps Luis would be interested in picking it up? :-) ]

Sure thing, I'm not sure if it makes sense to decouple kernel/kmod.c on
MAINTAINERS though, if you do let me know what you'd prefer to call it,
"KMOD MODULE USERMODE HELPER" ?

If you prefer to keep them together I can certainly volunteer to review all
kmod changes and can send a patch to add kmod and myself under "MODULE
SUPPORT".

Either way, let me know!

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

Re: [PATCH v3 0/4] kmod: help make deterministic

[Jessica Yu]

+++ Kees Cook [20/06/17 17:23 -0700]:

On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez  wrote:

On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote:

This v3 nukes the proc sysctl interface in favor for just letting userspace
just check kernel revision. Prior to whenever this is merged userspace should
try to avoid hammering more than 50 kmod threads as they can fail and it'd
get -ENOMEM.

We do away with the old heuristics on assuming you could end up with
less than max_threads/2 < 50 threads as Dmitry notes this would mean having
a system with 16 MiB of RAM with modules enabled. It simplifies our patch
"kmod: reduce atomic operations on kmod_concurrent" considerbly.

Since the sysctl interface is gone, this no longer depends on any
other patches, the series is independent. As usual the series is
available on my linux-next 20170526-kmod-only branch which is based
on next-20170526.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170526-kmod-only

  Luis

Luis R. Rodriguez (4):
  module: use list_for_each_entry_rcu() on find_module_all()
  kmod: reduce atomic operations on kmod_concurrent and simplify
  kmod: add test driver to stress test the module loader
  kmod: throttle kmod thread limit


About a month now with no further nitpicks. What tree should these changes
go through if there are no issues? Andrew's, Jessica's ?


Seems like going through Jessica's would make the most sense?


Would be happy to take patches 01 (which I need to anyway), 02,
possibly 04 if decoupled from the test driver (03). I can't take patch
03 through my tree just yet, as I haven't had time to give it a look
yet :-/

[ Side comment, it seems that kmod.c isn't directly maintained by anyone
right now, perhaps Luis would be interested in picking it up? :-) ]

Thanks,

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

Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

[Tom Lendacky]

On 6/26/2017 10:45 AM, Borislav Petkov wrote:

On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:

Normally the __p4d() macro would be used and that would be ok whether
CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
paravirt ops path I have to use native_make_p4d().


So __p4d is in !CONFIG_PARAVIRT path.

Regardless, we use the native_* variants in generic code to mean, not
paravirt. Just define it in a separate patch like the rest of the p4*
machinery and use it in your code. Sooner or later someone else will
need it.


Ok, will do.




True, 5-level will only be turned on for specific hardware which is why
I originally had this as only 4-level pagetables. But in a comment from
you back on the v5 version you said it needed to support 5-level. I
guess we should have discussed this more,


AFAIR, I said something along the lines of "what about 5-level page
tables?" and whether we care.


My bad, I took the meaning of that question the wrong way then.

Thanks,
Tom




but I also thought that should our hardware ever support 5-level
paging in the future then this would be good to go.


There it is :-)


The macros work great if you are not running identity mapped. You could
use p*d_offset() to move easily through the tables, but those functions
use __va() to generate table virtual addresses. I've seen where
boot/compressed/pagetable.c #defines __va() to work with identity mapped
pages but that would only work if I create a separate file just for this
function.

Given when this occurs it's very similar to what __startup_64() does in
regards to the IS_ENABLED(CONFIG_X86_5LEVEL) checks.


Ok.


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

Re: [PATCH v2 12/29] kselftest.rst: do some adjustments after ReST conversion

[Shuah Khan]

On 06/25/2017 01:35 PM, Jonathan Corbet wrote:
> On Fri, 23 Jun 2017 18:47:51 -0600
> Shuah Khan  wrote:
> 
>> Please let me know if you want me to take this through linux-kselftest
>> In which case, Ack the patch. If not, you already have my Ack.
> 
> Go ahead and take it if you want:
> 
>   Acked-by: Jonathan Corbet 
> 
> I haven't quite figured out how I'm going to manage this mountain of
> patches yet; making it a little smaller can only help :)

Good luck. :)

> 
> jon
> 
> 

Thanks. Applied to linux-kselftest next for 4.13-rc1

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

Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

[Borislav Petkov]

On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:
> Normally the __p4d() macro would be used and that would be ok whether
> CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
> paravirt ops path I have to use native_make_p4d().

So __p4d is in !CONFIG_PARAVIRT path.

Regardless, we use the native_* variants in generic code to mean, not
paravirt. Just define it in a separate patch like the rest of the p4*
machinery and use it in your code. Sooner or later someone else will
need it.

> True, 5-level will only be turned on for specific hardware which is why
> I originally had this as only 4-level pagetables. But in a comment from
> you back on the v5 version you said it needed to support 5-level. I
> guess we should have discussed this more,

AFAIR, I said something along the lines of "what about 5-level page
tables?" and whether we care.

> but I also thought that should our hardware ever support 5-level
> paging in the future then this would be good to go.

There it is :-)

> The macros work great if you are not running identity mapped. You could
> use p*d_offset() to move easily through the tables, but those functions
> use __va() to generate table virtual addresses. I've seen where
> boot/compressed/pagetable.c #defines __va() to work with identity mapped
> pages but that would only work if I create a separate file just for this
> function.
> 
> Given when this occurs it's very similar to what __startup_64() does in
> regards to the IS_ENABLED(CONFIG_X86_5LEVEL) checks.

Ok.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

[Dongjiu Geng]

when SError happen, kvm notifies user space to record the CPER,
user space specifies and passes the contents of ESR_EL1 on taking
a virtual SError interrupt to KVM, KVM enables virtual system
error or asynchronous abort with this specifies syndrome. This
patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
saves the virtual SError syndrome, it becomes the ESR_EL1 value when
HCR_EL2.VSE injects an SError. This register is added by the
RAS Extensions.

Changes since v3:
(1) Move restore VSESR_EL2 value logic to a helper method
(2) In the world-switch, not save VSESR_EL2, because no one cares the
old VSESR_EL2 value
(3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
a virtual system error

Signed-off-by: Dongjiu Geng 
Signed-off-by: Quanming Wu 
---
 Documentation/virtual/kvm/api.txt| 10 ++
 arch/arm/include/asm/kvm_host.h  |  1 +
 arch/arm/kvm/arm.c   |  7 +++
 arch/arm/kvm/guest.c |  5 +
 arch/arm64/include/asm/esr.h |  2 ++
 arch/arm64/include/asm/kvm_emulate.h | 10 ++
 arch/arm64/include/asm/kvm_host.h|  2 ++
 arch/arm64/include/asm/sysreg.h  |  3 +++
 arch/arm64/kvm/guest.c   | 14 ++
 arch/arm64/kvm/handle_exit.c | 25 +++--
 arch/arm64/kvm/hyp/switch.c  | 14 ++
 include/uapi/linux/kvm.h |  8 
 12 files changed, 95 insertions(+), 6 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 3c248f7..852ac55 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3377,6 +3377,16 @@ struct kvm_ppc_resize_hpt {
__u32 pad;
 };
 
+4.104 KVM_ARM_SEI
+
+Capability: KVM_EXIT_SERROR_INTR
+Architectures: arm/arm64
+Type: vcpu ioctl
+Parameters: u64 (syndrome)
+Returns: 0 in case of success
+
+Pend an virtual system error or asynchronous abort with user space specified.
+
 5. The kvm_run structure
 
 
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 31ee468..566292a 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -244,6 +244,7 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const 
struct kvm_one_reg *);
 
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
int exception_index);
+int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
 
 static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
   unsigned long hyp_stack_ptr,
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 96dba7c..583294f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -987,6 +987,13 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
return -EFAULT;
return kvm_arm_vcpu_has_attr(vcpu, &attr);
}
+   case KVM_ARM_SEI: {
+   u64 syndrome;
+
+   if (copy_from_user(&syndrome, argp, sizeof(syndrome)))
+   return -EFAULT;
+   return kvm_vcpu_ioctl_sei(vcpu, &syndrome);
+   }
default:
return -EINVAL;
}
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index fa6182a..72505bf 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -248,6 +248,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
 }
 
+int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome)
+{
+   return 0;
+}
+
 int __attribute_const__ kvm_target_cpu(void)
 {
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 22f9c90..d009c99 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -127,6 +127,8 @@
 #define ESR_ELx_WFx_ISS_WFE(UL(1) << 0)
 #define ESR_ELx_xVC_IMM_MASK   ((1UL << 16) - 1)
 
+#define VSESR_ELx_IDS_ISS_MASK((1UL << 25) - 1)
+
 /* ESR value templates for specific events */
 
 /* BRK instruction trap from AArch64 state */
diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index 5f64ab2..93dc3d1 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -155,6 +155,16 @@ static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu 
*vcpu)
return vcpu->arch.fault.esr_el2;
 }
 
+static inline u32 kvm_vcpu_get_vsesr(const struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.fault.vsesr_el2;
+}
+
+static inline void kvm_vcpu_set_vsesr(struct kvm_vcpu *vcpu, unsigned long val)
+{
+   vcpu->arch.fault.vsesr_el2 = val;
+}
+
 static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
 {
u32 esr = kvm_vcpu_get_hsr(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index e7705e7..b6242fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.

[PATCH v4 1/3] arm64: kvm: support user space to detect RAS extension feature

[Dongjiu Geng]

Handle userspace's detection for RAS extension, because sometimes
the userspace needs to know the CPU's capacity

Signed-off-by: Dongjiu Geng 
---
 arch/arm64/kvm/reset.c   | 11 +++
 include/uapi/linux/kvm.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index d9e9697..1004039 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -64,6 +64,14 @@ static bool cpu_has_32bit_el1(void)
return !!(pfr0 & 0x20);
 }
 
+static bool kvm_arm_support_ras_extension(void)
+{
+   u64 pfr0;
+
+   pfr0 = read_system_reg(SYS_ID_AA64PFR0_EL1);
+   return !!(pfr0 & 0x1000);
+}
+
 /**
  * kvm_arch_dev_ioctl_check_extension
  *
@@ -87,6 +95,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long 
ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+   case KVM_CAP_ARM_RAS_EXTENSION:
+   r = kvm_arm_support_ras_extension();
+   break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index f51d508..27fe556 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -883,6 +883,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_PPC_MMU_RADIX 134
 #define KVM_CAP_PPC_MMU_HASH_V3 135
 #define KVM_CAP_IMMEDIATE_EXIT 136
+#define KVM_CAP_ARM_RAS_EXTENSION 137
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.10.1

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

[PATCH v4 2/3] arm64: kvm: route synchronous external abort exceptions to el2

[Dongjiu Geng]

In the firmware-first RAS solution, guest OS receives an synchronous
external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects
the HCR_EL2.TEA and chooses the target to send APEI's SEA notification.
If the SCR_EL3.EA is set, delegates the error exception to the hypervisor,
otherwise it delegates to the guest OS kernel

Signed-off-by: Dongjiu Geng 
---
 arch/arm64/include/asm/kvm_arm.h | 2 ++
 arch/arm64/include/asm/kvm_emulate.h | 7 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 61d694c..1188272 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -23,6 +23,8 @@
 #include 
 
 /* Hyp Configuration Register (HCR) bits */
+#define HCR_TEA(UL(1) << 37)
+#define HCR_TERR   (UL(1) << 36)
 #define HCR_E2H(UL(1) << 34)
 #define HCR_ID (UL(1) << 33)
 #define HCR_CD (UL(1) << 32)
diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index f5ea0ba..5f64ab2 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -47,6 +47,13 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
if (is_kernel_in_hyp_mode())
vcpu->arch.hcr_el2 |= HCR_E2H;
+   if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
+   /* route synchronous external abort exceptions to EL2 */
+   vcpu->arch.hcr_el2 |= HCR_TEA;
+   /* trap error record accesses */
+   vcpu->arch.hcr_el2 |= HCR_TERR;
+   }
+
if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
vcpu->arch.hcr_el2 &= ~HCR_RW;
 }
-- 
2.10.1

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

Re: [PATCH v4 4/4] kmod: throttle kmod thread limit

[Petr Mladek]

On Fri 2017-06-23 12:20:11, Luis R. Rodriguez wrote:
> If we reach the limit of modprobe_limit threads running the next
> request_module() call will fail. The original reason for adding
> a kill was to do away with possible issues with in old circumstances
> which would create a recursive series of request_module() calls.
> 
> We can do better than just be super aggressive and reject calls
> once we've reached the limit by simply making pending callers wait
> until the threshold has been reduced, and then throttling them in,
> one by one.
> 
> This throttling enables requests over the kmod concurrent limit to
> be processed once a pending request completes. Only the first item
> queued up to wait is woken up. The assumption here is once a task
> is woken it will have no other option to also kick the queue to check
> if there are more pending tasks -- regardless of whether or not it
> was successful.
> 
> By throttling and processing only max kmod concurrent tasks we ensure
> we avoid unexpected fatal request_module() calls, and we keep memory
> consumption on module loading to a minimum.
> 
> With x86_64 qemu, with 4 cores, 4 GiB of RAM it takes the following run
> time to run both tests:
> 
> time ./kmod.sh -t 0008
> real0m16.523s
> user0m0.879s
> sys 0m8.977s
> 
> time ./kmod.sh -t 0009
> real0m56.080s
> user0m0.717s
> sys 0m10.324s
> 
> Signed-off-by: Luis R. Rodriguez 

All the changes look fine to me. They make perfect sense.

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

Re: [PATCH v3 2/4] kmod: reduce atomic operations on kmod_concurrent and simplify

[Petr Mladek]

On Fri 2017-05-26 14:12:26, Luis R. Rodriguez wrote:
> atomic operations. We do this by inverting the logic of of the enabler,
> instead of incrementing kmod_concurrent as we get new kmod users, define the
> variable kmod_concurrent_max as the max number of currently allowed kmod
> users and as we get new kmod users just decrement it if its still positive.
> This combines the dec and read in one atomic operation.
> 
> In this case we no longer get the same false failure:
> 
> CPU1  CPU2
> atomic_dec_if_positive()
>   atomic_dec_if_positive()
> atomic_inc()
>   atomic_inc()
> 
> Suggested-by: Petr Mladek 
> Suggested-by: Dmitry Torokhov 
> Signed-off-by: Luis R. Rodriguez 

The change looks fine to me. The code is much easier and less hacky.

Reviewed-by: Petr Mladek 

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

[PATCH v4] arm64: kvm: inject SError with user space specified syndrome

[Dongjiu Geng]

when SError happen, kvm notifies user space to record the CPER,
user space specifies and passes the contents of ESR_EL1 on taking
a virtual SError interrupt to KVM, KVM enables virtual system
error or asynchronous abort with this specifies syndrome. This
patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
saves the virtual SError syndrome, it becomes the ESR_EL1 value when
HCR_EL2.VSE injects an SError. This register is added by the
RAS Extensions.

Changes since v3:
(1) Move restore VSESR_EL2 value logic to a helper method
(2) In the world-switch, not save VSESR_EL2, because no one cares the
old VSESR_EL2 value
(3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
a virtual system error

Signed-off-by: Dongjiu Geng 
Signed-off-by: Quanming Wu 
---
 Documentation/virtual/kvm/api.txt| 10 ++
 arch/arm/include/asm/kvm_host.h  |  1 +
 arch/arm/kvm/arm.c   |  6 ++
 arch/arm/kvm/guest.c |  5 +
 arch/arm64/include/asm/esr.h |  2 ++
 arch/arm64/include/asm/kvm_emulate.h | 10 ++
 arch/arm64/include/asm/kvm_host.h|  2 ++
 arch/arm64/include/asm/sysreg.h  |  3 +++
 arch/arm64/kvm/guest.c   | 14 ++
 arch/arm64/kvm/handle_exit.c | 25 +++--
 arch/arm64/kvm/hyp/switch.c  | 14 ++
 include/uapi/linux/kvm.h |  8 
 12 files changed, 94 insertions(+), 6 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 3c248f7..852ac55 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3377,6 +3377,16 @@ struct kvm_ppc_resize_hpt {
__u32 pad;
 };
 
+4.104 KVM_ARM_SEI
+
+Capability: KVM_EXIT_SERROR_INTR
+Architectures: arm/arm64
+Type: vcpu ioctl
+Parameters: u64 (syndrome)
+Returns: 0 in case of success
+
+Pend an virtual system error or asynchronous abort with user space specified.
+
 5. The kvm_run structure
 
 
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 31ee468..566292a 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -244,6 +244,7 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const 
struct kvm_one_reg *);
 
 int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
int exception_index);
+int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
 
 static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
   unsigned long hyp_stack_ptr,
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 96dba7c..2622501 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -987,6 +987,12 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
return -EFAULT;
return kvm_arm_vcpu_has_attr(vcpu, &attr);
}
+   case KVM_ARM_SEI: {
+   u64 syndrome;
+   if (copy_from_user(&syndrome, argp, sizeof(syndrome)))
+   return -EFAULT;
+   return kvm_vcpu_ioctl_sei(vcpu, &syndrome);
+   }
default:
return -EINVAL;
}
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index fa6182a..a610f8f 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -248,6 +248,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
 }
 
+int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
+{
+   return 0;
+}
+
 int __attribute_const__ kvm_target_cpu(void)
 {
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 22f9c90..d009c99 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -127,6 +127,8 @@
 #define ESR_ELx_WFx_ISS_WFE(UL(1) << 0)
 #define ESR_ELx_xVC_IMM_MASK   ((1UL << 16) - 1)
 
+#define VSESR_ELx_IDS_ISS_MASK((1UL << 25) - 1)
+
 /* ESR value templates for specific events */
 
 /* BRK instruction trap from AArch64 state */
diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index f5ea0ba..a3259a9 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -148,6 +148,16 @@ static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu 
*vcpu)
return vcpu->arch.fault.esr_el2;
 }
 
+static inline u32 kvm_vcpu_get_vsesr(const struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.fault.vsesr_el2;
+}
+
+static inline void kvm_vcpu_set_vsesr(struct kvm_vcpu *vcpu, unsigned long val)
+{
+   vcpu->arch.fault.vsesr_el2 = val;
+}
+
 static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
 {
u32 esr = kvm_vcpu_get_hsr(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index e7705e7..b6242fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h

Re: [PATCH v3 4/4] kmod: throttle kmod thread limit

[Petr Mladek]

On Fri 2017-06-23 21:16:37, Luis R. Rodriguez wrote:
> On Fri, Jun 23, 2017 at 07:56:11PM +0200, Luis R. Rodriguez wrote:
> > On Fri, Jun 23, 2017 at 06:16:19PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, Jun 22, 2017 at 05:19:36PM +0200, Petr Mladek wrote:
> > > > On Fri 2017-05-26 14:12:28, Luis R. Rodriguez wrote:
> > > > > --- a/kernel/kmod.c
> > > > > +++ b/kernel/kmod.c
> > > > > @@ -178,6 +175,7 @@ int __request_module(bool wait, const char *fmt, 
> > > > > ...)
> > > > >   ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : 
> > > > > UMH_WAIT_EXEC);
> > > > >  
> > > > >   atomic_inc(&kmod_concurrent_max);
> > > > > + wake_up_all(&kmod_wq);
> > > > 
> > > > Does it make sense to wake up all waiters when we released the resource
> > > > only for one? IMHO, a simple wake_up() should be here.
> > > 
> > > Then we should wake_up() also on failure, otherwise we have the potential
> > > to not wake some in a proper time.
> > 
> > I checked and it turns out we have no error paths after we consume a kmod
> > ticket, if you will. Once we bump with atomic_dec_if_positive() we assume
> > we're moving forward with an attempt, and the only failure path is already
> > bundled with a wake at the end of the __request_module() call.
> > 
> > Then the next question would be *who* exactly gets woken up next if we just
> > use wake_up() ? The common core wake up code varies depending on use and
> > all this reminded me of the complexity we just don't need, so I have now
> > converted to use swait. swait uses list_add() if empty and then iterates
> > with list_first_entry() on wakeup, so that should get the first item added
> > to the wait list.
> > 
> > Works with me. Will run a test a before v4 is sent, but since only 2 patches
> > are modified will only send a respective update for these 2 patches.
> 
> Alright, this worked out well! Its just a tiny bit slower on test cases 0008
> and 0009 (few seconds) but that's fine, its natural due to the lack of the
> swake_up_all().

This is interesting. I guess that it was faster with swake_up_all()
because it worked as a speculative pre-wake. I mean that it takes some
time between adding a process into run-queue and really running it.
IMHO, swake_up_all() caused that __request_module() callers were
more often really running and trying to pass that
atomic_dec_if_positive(&kmod_concurrent_max) >= 0).

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

Re: [PATCH v3 4/4] kmod: throttle kmod thread limit

[Petr Mladek]

On Fri 2017-06-23 18:16:19, Luis R. Rodriguez wrote:
> On Thu, Jun 22, 2017 at 05:19:36PM +0200, Petr Mladek wrote:
> > On Fri 2017-05-26 14:12:28, Luis R. Rodriguez wrote:
> > > --- a/kernel/kmod.c
> > > +++ b/kernel/kmod.c
> > > @@ -163,14 +163,11 @@ int __request_module(bool wait, const char *fmt, 
> > > ...)
> > >   return ret;
> > >  
> > >   if (atomic_dec_if_positive(&kmod_concurrent_max) < 0) {
> > > - /* We may be blaming an innocent here, but unlikely */
> > > - if (kmod_loop_msg < 5) {
> > > - printk(KERN_ERR
> > > -"request_module: runaway loop modprobe %s\n",
> > > -module_name);
> > > - kmod_loop_msg++;
> > > - }
> > > - return -ENOMEM;
> > > + pr_warn_ratelimited("request_module: kmod_concurrent_max (%u) 
> > > close to 0 (max_modprobes: %u), for module %s\n, throttling...",
> > > + atomic_read(&kmod_concurrent_max),
> > > + 50, module_name);
> > 
> > It is weird to pass the constant '50' via %s.
> 
> The 50 was passed with %u, so I take it you meant it is odd to use a parameter
> for it.

Yeah, I meant %u and not %s.

> > Also a #define should be
> > used to keep it in sync with the kmod_concurrent_max initialization.
> 
> OK.
> 
> > > + wait_event_interruptible(kmod_wq,
> > > +  
> > > atomic_dec_if_positive(&kmod_concurrent_max) >= 0);
> > >   }
> > >  
> > >   trace_module_request(module_name, wait, _RET_IP_);
> > > @@ -178,6 +175,7 @@ int __request_module(bool wait, const char *fmt, ...)
> > >   ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC);
> > >  
> > >   atomic_inc(&kmod_concurrent_max);
> > > + wake_up_all(&kmod_wq);
> > 
> > Does it make sense to wake up all waiters when we released the resource
> > only for one? IMHO, a simple wake_up() should be here.
> 
> Then we should wake_up() also on failure, otherwise we have the potential
> to not wake some in a proper time.

I think that we must wake_up() always when we increment
kmod_concurrent_max. If the value was negative, the increment will
allow exactly one process to pass that
atomic_dec_if_positive(&kmod_concurrent_max) >= 0). It the value
is positive, there must have been other wake_up() calls or there
is no waiter.

IMHO, this works because kmod_concurrent_max handling is atomic
and race-less now. Also (s)wait_event_interruptible() is safe
and does not allow to get into sleep when the resource is available.

Anyway, it is great that you have double checked this.

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

Re: [PATCH v2] mm: Allow slab_nomerge to be set at build time

[Michal Hocko]

On Fri 23-06-17 12:20:25, Kees Cook wrote:
> On Fri, Jun 23, 2017 at 7:06 AM, Michal Hocko  wrote:
> > On Tue 20-06-17 16:09:11, Kees Cook wrote:
> >> Some hardened environments want to build kernels with slab_nomerge
> >> already set (so that they do not depend on remembering to set the kernel
> >> command line option). This is desired to reduce the risk of kernel heap
> >> overflows being able to overwrite objects from merged caches and changes
> >> the requirements for cache layout control, increasing the difficulty of
> >> these attacks. By keeping caches unmerged, these kinds of exploits can
> >> usually only damage objects in the same cache (though the risk to metadata
> >> exploitation is unchanged).
> >
> > Do we really want to have a dedicated config for each hardening specific
> > kernel command line? I believe we have quite a lot of config options
> > already. Can we rather have a CONFIG_HARDENED_CMD_OPIONS and cover all
> > those defauls there instead?
> 
> There's not been a lot of success with grouped Kconfigs in the past
> (e.g. CONFIG_EXPERIMENTAL), but one thing that has been suggested is a
> defconfig-like make target that would collect all the things together.

Which wouldn't reduce the number of config options, would it? I don't
know but is there any usecase when somebody wants to have hardened
kernel and still want to have different defaults than you are
suggesting?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] usb: gadget: f_uac*: Support multiple sampling rates

[Julian Scheel]

Implement support for multiple sampling rates in the USB Audio gadgets.
A list of sampling rates can be specified via configfs. All enabled
sampling rates are sent to the USB host on request. When the host
selects a sampling rate the internal active rate is updated. The
currently configured rates are exposed through amixer controls. Also on
pcm open from userspace the requested rated is checked against the
currently configured rate of the host.

Signed-off-by: Julian Scheel 
---
 Documentation/ABI/testing/configfs-usb-gadget-uac1 |   4 +-
 Documentation/usb/gadget-testing.txt   |   8 +-
 drivers/usb/gadget/function/f_uac1.c   | 120 +
 drivers/usb/gadget/function/f_uac2.c   | 146 +++--
 drivers/usb/gadget/function/u_audio.c  | 116 +++-
 drivers/usb/gadget/function/u_audio.h  |   9 +-
 drivers/usb/gadget/function/u_uac.h|  69 +-
 7 files changed, 393 insertions(+), 79 deletions(-)

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 
b/Documentation/ABI/testing/configfs-usb-gadget-uac1
index abfe447c848f..ad2fa4a00918 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uac1
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1
@@ -5,10 +5,10 @@ Description:
The attributes:
 
c_chmask - capture channel mask
-   c_srate - capture sampling rate
+   c_srate - list of capture sampling rates (comma-separataed)
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
-   p_srate - playback sampling rate
+   p_srate - list of playback sampling rates (comma-separated)
p_ssize - playback sample size (bytes)
req_number - the number of pre-allocated request
for both capture and playback
diff --git a/Documentation/usb/gadget-testing.txt 
b/Documentation/usb/gadget-testing.txt
index fbc397d17e98..85878880 100644
--- a/Documentation/usb/gadget-testing.txt
+++ b/Documentation/usb/gadget-testing.txt
@@ -629,10 +629,10 @@ The function name to use when creating the function 
directory is "uac2".
 The uac2 function provides these attributes in its function directory:
 
c_chmask - capture channel mask
-   c_srate - capture sampling rate
+   c_srate - list of capture sampling rates (comma-separated)
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
-   p_srate - playback sampling rate
+   p_srate - list of playback sampling rates (comma-separated)
p_ssize - playback sample size (bytes)
req_number - the number of pre-allocated request for both capture
 and playback
@@ -790,10 +790,10 @@ The function name to use when creating the function 
directory is "uac1".
 The uac1 function provides these attributes in its function directory:
 
c_chmask - capture channel mask
-   c_srate - capture sampling rate
+   c_srate - list of capture sampling rates (comma-separated)
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
-   p_srate - playback sampling rate
+   p_srate - list of playback sampling rates (comma-separated)
p_ssize - playback sample size (bytes)
req_number - the number of pre-allocated request for both capture
 and playback
diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index 7e5a9bd46bcf..6ae210a9ddfc 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -2,6 +2,7 @@
  * f_uac1.c -- USB Audio Class 1.0 Function (using u_audio API)
  *
  * Copyright (C) 2016 Ruslan Bilovol 
+ * Copyright (C) 2017 Julian Scheel 
  *
  * This driver doesn't expect any real Audio codec to be present
  * on the device - the audio streams are simply sinked to and
@@ -177,16 +178,18 @@ static struct uac1_as_header_descriptor as_in_header_desc 
= {
.wFormatTag =   UAC_FORMAT_TYPE_I_PCM,
 };
 
-DECLARE_UAC_FORMAT_TYPE_I_DISCRETE_DESC(1);
+DECLARE_UAC_FORMAT_TYPE_I_DISCRETE_DESC(UAC_MAX_RATES);
+#define uac_format_type_i_discrete_descriptor \
+   uac_format_type_i_discrete_descriptor_##UAC_MAX_RATES
 
-static struct uac_format_type_i_discrete_descriptor_1 as_out_type_i_desc = {
-   .bLength =  UAC_FORMAT_TYPE_I_DISCRETE_DESC_SIZE(1),
+static struct uac_format_type_i_discrete_descriptor as_out_type_i_desc = {
+   .bLength =  0, /* filled on rate setup */
.bDescriptorType =  USB_DT_CS_INTERFACE,
.bDescriptorSubtype =   UAC_FORMAT_TYPE,
.bFormatType =  UAC_FORMAT_TYPE_I,
.bSubframeSize =2,
.bBitResolution =   16,
-   .bSamFreqType = 1,
+   .bSamFreqType = 0, /* filled on rate setup */
 };
 
 /* Standard ISO OUT Endpoi

[PATCH 2/3] usb: gadget: f_uac*: Reduce code duplication

[Julian Scheel]

This replaces the dedicated headers for uac1 and uac2 functions with a
shared header for both of them. Apart from unifying the struct names,
further duplicated code for configfs setup is moved out of the function
files into the shared header.

Signed-off-by: Julian Scheel 
---
 drivers/usb/gadget/function/f_uac1.c | 142 +-
 drivers/usb/gadget/function/f_uac2.c | 161 ++-
 drivers/usb/gadget/function/u_uac.h  | 115 +
 drivers/usb/gadget/function/u_uac1.h |  41 -
 drivers/usb/gadget/function/u_uac2.h |  44 --
 5 files changed, 199 insertions(+), 304 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_uac.h
 delete mode 100644 drivers/usb/gadget/function/u_uac1.h
 delete mode 100644 drivers/usb/gadget/function/u_uac2.h

diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index b955913bd7ea..7e5a9bd46bcf 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -21,18 +21,9 @@
 #include 
 
 #include "u_audio.h"
-#include "u_uac1.h"
+#include "u_uac.h"
 
-struct f_uac1 {
-   struct g_audio g_audio;
-   u8 ac_intf, as_in_intf, as_out_intf;
-   u8 ac_alt, as_in_alt, as_out_alt;   /* needed for get_alt() */
-};
-
-static inline struct f_uac1 *func_to_uac1(struct usb_function *f)
-{
-   return container_of(f, struct f_uac1, g_audio.func);
-}
+#define UAC1_OUT_EP_MAX_PACKET_SIZE 200
 
 /*
  * DESCRIPTORS ... most are static, but strings and full
@@ -435,7 +426,7 @@ static int f_audio_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
struct usb_composite_dev *cdev = f->config->cdev;
struct usb_gadget *gadget = cdev->gadget;
struct device *dev = &gadget->dev;
-   struct f_uac1 *uac1 = func_to_uac1(f);
+   struct f_uac *uac1 = func_to_uac(f);
int ret = 0;
 
/* No i/f has more than 2 alt settings */
@@ -480,7 +471,7 @@ static int f_audio_get_alt(struct usb_function *f, unsigned 
intf)
struct usb_composite_dev *cdev = f->config->cdev;
struct usb_gadget *gadget = cdev->gadget;
struct device *dev = &gadget->dev;
-   struct f_uac1 *uac1 = func_to_uac1(f);
+   struct f_uac *uac1 = func_to_uac(f);
 
if (intf == uac1->ac_intf)
return uac1->ac_alt;
@@ -498,7 +489,7 @@ static int f_audio_get_alt(struct usb_function *f, unsigned 
intf)
 
 static void f_audio_disable(struct usb_function *f)
 {
-   struct f_uac1 *uac1 = func_to_uac1(f);
+   struct f_uac *uac1 = func_to_uac(f);
 
uac1->as_out_alt = 0;
uac1->as_in_alt = 0;
@@ -513,16 +504,16 @@ static int f_audio_bind(struct usb_configuration *c, 
struct usb_function *f)
 {
struct usb_composite_dev*cdev = c->cdev;
struct usb_gadget   *gadget = cdev->gadget;
-   struct f_uac1   *uac1 = func_to_uac1(f);
+   struct f_uac*uac1 = func_to_uac(f);
struct g_audio  *audio = func_to_g_audio(f);
-   struct f_uac1_opts  *audio_opts;
+   struct f_uac_opts   *audio_opts;
struct usb_ep   *ep = NULL;
struct usb_string   *us;
u8  *sam_freq;
int rate;
int status;
 
-   audio_opts = container_of(f->fi, struct f_uac1_opts, func_inst);
+   audio_opts = container_of(f->fi, struct f_uac_opts, func_inst);
 
us = usb_gstrings_attach(cdev, uac1_strings, ARRAY_SIZE(strings_uac1));
if (IS_ERR(us))
@@ -630,82 +621,27 @@ static int f_audio_bind(struct usb_configuration *c, 
struct usb_function *f)
 
 /*-*/
 
-static inline struct f_uac1_opts *to_f_uac1_opts(struct config_item *item)
-{
-   return container_of(to_config_group(item), struct f_uac1_opts,
-   func_inst.group);
-}
-
-static void f_uac1_attr_release(struct config_item *item)
-{
-   struct f_uac1_opts *opts = to_f_uac1_opts(item);
-
-   usb_put_function_instance(&opts->func_inst);
-}
-
 static struct configfs_item_operations f_uac1_item_ops = {
-   .release= f_uac1_attr_release,
+   .release= f_uac_attr_release,
 };
 
-#define UAC1_ATTRIBUTE(name)   \
-static ssize_t f_uac1_opts_##name##_show(  \
- struct config_item *item, \
- char *page)   \
-{  \
-   struct f_uac1_opts *opts = to_f_uac1_opts(item);\
-   int result; \
-

[PATCH 1/3] usb: gadget: f_uac1: Fix endpoint reading

[Julian Scheel]

The endpoint is stored in the lower byte of wIndex, according to USB
Audio 1.0 specification, section 5.2.1.1.

Signed-off-by: Julian Scheel 
---
 drivers/usb/gadget/function/f_uac1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index 8656f84e17d9..b955913bd7ea 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -327,7 +327,7 @@ static int audio_set_endpoint_req(struct usb_function *f,
 {
struct usb_composite_dev *cdev = f->config->cdev;
int value = -EOPNOTSUPP;
-   u16 ep = le16_to_cpu(ctrl->wIndex);
+   u8  ep = le16_to_cpu(ctrl->wIndex) & 0xff;
u16 len = le16_to_cpu(ctrl->wLength);
u16 w_value = le16_to_cpu(ctrl->wValue);
 
@@ -363,7 +363,7 @@ static int audio_get_endpoint_req(struct usb_function *f,
 {
struct usb_composite_dev *cdev = f->config->cdev;
int value = -EOPNOTSUPP;
-   u8 ep = ((le16_to_cpu(ctrl->wIndex) >> 8) & 0xFF);
+   u8 ep = le16_to_cpu(ctrl->wIndex) & 0xff;
u16 len = le16_to_cpu(ctrl->wLength);
u16 w_value = le16_to_cpu(ctrl->wValue);
 
-- 
2.13.1

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

[PATCH 0/3] USB Audio Gadget: Support multiple sampling rates

[Julian Scheel]

This patch series adds support for exposing multiple supported sampling rates
from UAC1 and UAC2 USB gadgets to the connected host. It is currently limited
to up to ten discrete sampling frequencies. The USB specification does not
actually limit this, but to avoid complex list handling I am using a static
array for now.
As the configfs bindings for f_uac1 and f_uac2 have been identical already, I
decided to move the shared code for this out of the functions first. This
avoids code duplication and simplifies the addition of the list parsing for
sampling rates.
The host can configure active sampling rate and the function adapts it's
internal active rate automatically. On playback/capture start the rate is
checked, so that the user recognizes rate mismatches. Furthermore the active
rate is exposed as an amixer control with change notifications, so that
users can check current rate upfront and get notified about updates.

Julian Scheel (3):
  usb: gadget: f_uac1: Fix endpoint reading
  usb: gadget: f_uac*: Reduce code duplication
  usb: gadget: f_uac*: Support multiple sampling rates

 Documentation/ABI/testing/configfs-usb-gadget-uac1 |   4 +-
 Documentation/usb/gadget-testing.txt   |   8 +-
 drivers/usb/gadget/function/f_uac1.c   | 258 +-
 drivers/usb/gadget/function/f_uac2.c   | 297 ++---
 drivers/usb/gadget/function/u_audio.c  | 116 +++-
 drivers/usb/gadget/function/u_audio.h  |   9 +-
 drivers/usb/gadget/function/u_uac.h| 178 
 drivers/usb/gadget/function/u_uac1.h   |  41 ---
 drivers/usb/gadget/function/u_uac2.h   |  44 ---
 9 files changed, 582 insertions(+), 373 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_uac.h
 delete mode 100644 drivers/usb/gadget/function/u_uac1.h
 delete mode 100644 drivers/usb/gadget/function/u_uac2.h

-- 
2.13.1

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