Re: [PATCH] pcmcia: ds: Remove if with always false condition

[Dominik Brodowski]

Am Mon, Mar 01, 2021 at 06:38:47PM +0100 schrieb Uwe Kleine-König:
> pcmcia_device_remove() is only ever called by the driver core with
> dev->driver pointing to a valid driver. (And even if dev->driver was
> NULL, p_drv wouldn't be NULL as p_drv is assigned as follows:
> 
>   p_drv = to_pcmcia_drv(dev->driver);
> 
> and to_pcmcia_drv is a container_of operation on struct
> pcmcia_driver::drv which isn't the first member in struct
> pcmcia_driver.)
> 
> Signed-off-by: Uwe Kleine-König 

Applied to pcmcia-next, thanks.

Dominik

Re: [PATCH 0/6] Rid W=1 warnings from PCMCIA

[Dominik Brodowski]

Am Fri, Mar 12, 2021 at 11:02:33AM + schrieb Lee Jones:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
> 
> Lee Jones (6):
>   pcmcia: rsrc_nonstatic: Demote kernel-doc abuses
>   pcmcia: cistpl: Demote non-conformant kernel-doc headers to standard
> comments
>   pcmcia: pcmcia_cis: Demote non-conforming kernel-doc headers to
> standard kernel-doc
>   pcmcia: ds: Fix function name disparity in header
>   pcmcia: pcmcia_resource: Fix some kernel-doc formatting/disparities
> and demote others
>   pcmcia: rsrc_nonstatic: Fix call-back function as reference formatting

Applied the whole series to pcmcia-next, thanks.

Dominik

[GIT PULL] pcmcia updates for v5.12

[Dominik Brodowski]

Linus,

A lone PCMCIA change since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:

  Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)

is available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git pcmcia-next

for you to fetch changes up to 4ce6b242b78d355ba899f1b16c6bfcd43df155a0:

  pcmcia: Switch to using the new API kobj_to_dev() (2021-01-04 08:16:00 +0100)


The patch contained in this pull request improves the use of the kobj API
in the core of the Linux PCMCIA subsystem.


Thanks,
Dominik


Tian Tao (1):
  pcmcia: Switch to using the new API kobj_to_dev()

 drivers/pcmcia/cistpl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] pcmcia: Switch to using the new API kobj_to_dev()

[Dominik Brodowski]

Am Tue, Feb 23, 2021 at 05:26:50PM +0800 schrieb Yang Li:
> fixed the following coccicheck:
> ./drivers/pcmcia/cistpl.c:1584:53-54: WARNING opportunity for
> kobj_to_dev()
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 

Sorry, an equivalent patch is already in pcmcia-next and about to be sent
upstream.

Thanks,
Dominik

Re: [PATCH] cpufreq: Remove CPUFREQ_STICKY flag

[Dominik Brodowski]

Viresh,

Am Mon, Feb 01, 2021 at 01:35:51PM +0530 schrieb Viresh Kumar:
> The removal of such a driver is avoided if the driver carries the
> CPUFREQ_STICKY flag. This was added way back [1] in 2004 and perhaps no
> one should ever need it now. A lot of driver do set this flag, probably
> because they just copied it from another driver.

IIRC, it was required on various ARM systems,[*] as CPUs were registered as
subsys_initcall(), while cpufreq used to be initialized only later, as an
arch_initcall(). If the ordering is opposite now on all architectures (it
wasn't on ARM back then), we should be fine.

[*] 
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/arm/mach-sa1100/cpu-sa1100.c?id=f59d3bbe35f6268d729f51be82af8325d62f20f5

Thanks,
Dominik

Re: [PATCH 1/2] docs: Make syscalls' helpers naming consistent

[Dominik Brodowski]

On Fri, Jan 29, 2021 at 10:45:46PM -0300, André Almeida wrote:
> The documentation explains the need to create internal syscalls' helpers,
> and that they should be called `kern_xyzzy()`. However, the comment at
> include/linux/syscall.h says that they should be named as
> `ksys_xyzzy()`, and so are all the helpers declared bellow it. Change the
> documentation to reflect this.
> 
> Cc: Dominik Brodowski 
> Fixes: 819671ff849b ("syscalls: define and explain goal to not call syscalls 
> in the kernel")
> Signed-off-by: André Almeida 

Reviewed-by: Dominik Brodowski 

Thanks,
Dominik

Re: [PATCH] pcmcia: Switch to using the new API kobj_to_dev()

[Dominik Brodowski]

Am Mon, Jan 04, 2021 at 09:59:30AM +0800 schrieb Tian Tao:
> fixed the following coccicheck:
> drivers/pcmcia/cistpl.c:1557:54-55: WARNING opportunity for kobj_to_dev()
> drivers/pcmcia/cistpl.c:1584:53-54: WARNING opportunity for kobj_to_dev()
> 
> Signed-off-by: Tian Tao 

Applied to pcmcia-next, thanks!

Dominik

[GIT PULL] pcmcia updates for v5.11

[Dominik Brodowski]

Linus,

The following changes since commit b3298500b23f0b53a8d81e0d5ad98a29db71f4f0:

  Merge tag 'for-5.10/dm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm 
(2020-12-04 13:28:39 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git pcmcia-next

for you to fetch changes up to 70d3a462fc244b0580268cc8e6c47ae4463db68a:

  pcmcia: omap: Fix error return code in omap_cf_probe() (2020-12-05 09:59:13 
+0100)


Besides a few PCMCIA odd fixes, the NEC VRC4173 CARDU driver is
removed, as it has not compiled in ages.


Thanks,
Dominik



Christophe JAILLET (1):
  pcmcia/electra_cf: Fix some return values in 'electra_cf_probe()' in case 
of error

Jason Yan (1):
  pcmcia: db1xxx_ss: remove unneeded semicolon

Sebastian Andrzej Siewior (1):
  pcmcia: Remove NEC VRC4173 CARDU

Wang ShaoBo (1):
  pcmcia: omap: Fix error return code in omap_cf_probe()

 drivers/pcmcia/Kconfig |   4 -
 drivers/pcmcia/Makefile|   1 -
 drivers/pcmcia/db1xxx_ss.c |   2 +-
 drivers/pcmcia/electra_cf.c|   2 +
 drivers/pcmcia/omap_cf.c   |   8 +-
 drivers/pcmcia/vrc4173_cardu.c | 591 -
 drivers/pcmcia/vrc4173_cardu.h | 247 -
 7 files changed, 9 insertions(+), 846 deletions(-)
 delete mode 100644 drivers/pcmcia/vrc4173_cardu.c
 delete mode 100644 drivers/pcmcia/vrc4173_cardu.h


signature.asc
Description: PGP signature

Re: [PATCH] init: fix msleep() is not accurate

[Dominik Brodowski]

Am Fri, Dec 11, 2020 at 11:24:12AM +0800 schrieb Yejune Deng:
> See Documentation/timers/timers-howto.rst, msleep() is not
> for (1ms - 20ms),use usleep_range() instead.

While technically correct, this branch is only taken if the "rootwait"
kernel parameter is passed -- and as the kernel is looping here, it does not
really hurt if the msleep(5) takes a bit longer than advertised.

Thanks,
Dominik

Re: [PATCH] pcmcia/electra_cf: Fix some return values in 'electra_cf_probe()' in case of error

[Dominik Brodowski]

Am Wed, Jun 17, 2020 at 09:53:26PM +0200 schrieb Christophe JAILLET:
> 'status' is known to be 0 at this point. It must be set to a meaningful
> value in order to return an error code if one of the 'of_get_property()'
> call fails.
> 
> Return -EINVAL in such a case.
> 
> Fixes: 2b571a066a2f("pcmcia: CompactFlash driver for PA Semi Electra boards")
> Signed-off-by: Christophe JAILLET 

Applied to pcmcia-next. Thanks!

Dominik

Re: [PATCH REPOST] pcmcia: Remove NEC VRC4173 CARDU

[Dominik Brodowski]

Am Fri, Dec 04, 2020 at 08:20:09PM +0100 schrieb Sebastian Andrzej Siewior:
> On 2020-11-19 18:06:24 [+0100], To linux-kernel@vger.kernel.org wrote:
> > On 2020-11-13 22:34:08 [+0100], To linux-kernel@vger.kernel.org wrote:
> > > This driver is the very definition of bitrotting:
> > > - Introduced in commit
> > >   79a140932c776 ("[PATCH] mips: vR41xx updates")
> > >   which is 2.6.11-rc3.
> > > 
> > > - Provides ->register_callback which was removed in commit
> > >   7f316b033b36a ("[PATCH] pcmcia: remove socket register_callback")
> > >   which is v2.6.14-rc3
> > > 
> > > - Uses INIT_WORK() with three arguments which was removed in commit
> > >   65f27f38446e1 ("WorkStruct: Pass the work_struct pointer instead of 
> > > context data")
> > >   which is v2.6.20-rc1
> > > 
> > > - Provides ->inquire_socket and uses socket_cap_t which was removed in
> > >   commit
> > >   b7949fdacbe00 ("[PCMCIA] Remove inquire_socket")
> > >   which is 2.5.72
> > > 
> > > - Provides ->get_io_map which was removed in commit
> > >   d7de1b64a23b9 ("[PCMCIA] pcmcia-2: Remove get_io_map and get_mem_map 
> > > socket methods.")
> > >   which is 2.5.66
> > > 
> > > Remove VRC4173 CARDU from the tree because it never had the luck to be
> > > successfully compiled. Let it finally find peace in byte heaven.
> > …
> > > This is a repost of
> > >   https://lkml.kernel.org/r/20201001193234.gi6fp4vk3dypw...@linutronix.de
> > > 
> > > which was a repost of
> > >   https://lkml.kernel.org/r/20200916081629.cfi6svr3yjvzi...@linutronix.de
> > 
> > Andrew, are you okay with routing this via your tree?
> > Nobody responded to this and as I documented in the patch description it
> > never compiled so.
> 
> Andrew, any chance?

It's in pcmcia-next now.

Thanks,
Dominik

Re: [PATCH] pcmcia: db1xxx_ss: remove unneeded semicolon

[Dominik Brodowski]

Am Thu, Sep 10, 2020 at 10:05:24PM +0800 schrieb Jason Yan:
> Eliminate the following coccicheck warning:
> 
> drivers/pcmcia/db1xxx_ss.c:455:2-3: Unneeded semicolon
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Jason Yan 

Applied to pcmcia-next.

Thanks,
Dominik

Re: [PATCH 1/2] pcmcia: at91_cf: move definitions locally

[Dominik Brodowski]

Am Tue, Nov 24, 2020 at 12:07:30PM +0100 schrieb Alexandre Belloni:
> On Wed, 30 Sep 2020 20:48:02 +0200, Alexandre Belloni wrote:
> > struct at91_cf_data is only used in the driver since all the platforms moved
> > to device tree, move its definition locally.
> 
> I've now applied those patches on the at91-drivers branch, please shout if you
> want them to go through your branch.
> 
> [1/2] pcmcia: at91_cf: move definitions locally
>   commit: 496e9b64d7297d3e6c209c51218cee2939694b25
> [2/2] pcmcia: at91_cf: remove platform data support
>   commit: 91be3e89f450aa738204f6629f06d8b0e3d8d77b

Thanks, I'm fine with that.

Dominik

Re: [PATCH] drivers/pcmcia: Fix error return code in electra_cf_probe()

[Dominik Brodowski]

Am Tue, Nov 24, 2020 at 03:00:40PM +0800 schrieb Wei Li:
> When it fails to call of_get_property(), it just jumps to 'fail1',
> while the 'status' which will be returned is not updated.
> 
> Fixes: 2b571a066a2f ("pcmcia: CompactFlash driver for PA Semi Electra boards")
> Signed-off-by: Wei Li 

Thnaks for the patch. However, this issue is already fixed by
commit f15480e947d4 ("pcmcia/electra_cf: Fix some return values in 
'electra_cf_probe()'
in case of error")
in pcmcia-next.

Thanks,
Dominik

Re: [PATCH] pcmcia: omap: Fix error return code in omap_cf_probe()

[Dominik Brodowski]

Am Wed, Nov 25, 2020 at 08:50:57PM +0800 schrieb Wang ShaoBo:
> Fix to return proper error code instaed of 0 in omap_cf_probe(), as done
> elsewhere in this function.
> 
> Signed-off-by: Wang ShaoBo 

Applied to pcmcia-next.

Thanks,
Dominik

Re: [PATCH] pcmcia: Remove NEC VRC4173 CARDU

[Dominik Brodowski]

Am Wed, Sep 16, 2020 at 10:16:29AM +0200 schrieb Sebastian Andrzej Siewior:
> This driver is the very definition of bitrotting:
> - Introduced in commit
>   79a140932c776 ("[PATCH] mips: vR41xx updates")
>   which is 2.6.11-rc3.
> 
> - Provides ->register_callback which was removed in commit
>   7f316b033b36a ("[PATCH] pcmcia: remove socket register_callback")
>   which is v2.6.14-rc3
> 
> - Uses INIT_WORK() with three arguments which was removed in commit
>   65f27f38446e1 ("WorkStruct: Pass the work_struct pointer instead of context 
> data")
>   which is v2.6.20-rc1
> 
> - Provides ->inquire_socket and uses socket_cap_t which was removed in
>   commit
>   b7949fdacbe00 ("[PCMCIA] Remove inquire_socket")
>   which is 2.5.72
> 
> - Provides ->get_io_map which was removed in commit
>   d7de1b64a23b9 ("[PCMCIA] pcmcia-2: Remove get_io_map and get_mem_map socket 
> methods.")
>   which is 2.5.66
> 
> Remove VRC4173 CARDU from the tree because it never had the luck to be
> successfully compiled. Let it finally find peace in byte heaven.
> 
> Cc: Reported-by: kernel test robot 
> Signed-off-by: Sebastian Andrzej Siewior 

Applied to pcmcia-next.

Thanks,
Dominik

Re: [PATCH 1/3] dma-mapping: remove DMA_MASK_NONE

[Dominik Brodowski]

On Tue, Sep 22, 2020 at 03:40:00PM +0200, Christoph Hellwig wrote:
> This value is only used by a PCMCIA driver and not very useful.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: Dominik Brodowski 

Re: [RESEND PATCH] sys_personality: Add optional arch hook arch_check_personality

[Dominik Brodowski]

On Mon, Jun 08, 2020 at 10:46:41AM +0100, Catalin Marinas wrote:
> On Mon, Jun 08, 2020 at 10:49:25AM +0800, Wang ShaoBo wrote:
> > Currently arm64 personality syscall uses wrapper __arm64_sys_personality
> > to redirect to __arm64_sys_arm64_personality, it's easily confused,
> > Whereas using an normal hook arch_check_personality() can reject
> > additional settings like this for special case of different architectures.
> > 
> > This makes code clean and easier for subsequent modification.
> 
> Do you plan to add more stuff here? Curious what triggered this patch.
> 
> > diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
> > index d5ffaaab31a7..5c01816d7a77 100644
> > --- a/arch/arm64/kernel/sys.c
> > +++ b/arch/arm64/kernel/sys.c
> > @@ -28,12 +28,13 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned 
> > long, len,
> > return ksys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
> >  }
> >  
> > -SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
> > +int arch_check_personality(unsigned int personality)
> >  {
> > if (personality(personality) == PER_LINUX32 &&
> > !system_supports_32bit_el0())
> > return -EINVAL;
> > -   return ksys_personality(personality);
> > +
> > +   return 0;
> >  }
> 
> We use the ksys_* pattern in other places as well, so this wouldn't be
> something new.
> 
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 1815065d52f3..3dbbad498027 100644
> > --- a/include/linux/syscalls.h
> > +++ b/include/linux/syscalls.h
> > @@ -1393,16 +1393,6 @@ static inline long ksys_truncate(const char __user 
> > *pathname, loff_t length)
> > return do_sys_truncate(pathname, length);
> >  }
> >  
> > -static inline unsigned int ksys_personality(unsigned int personality)
> > -{
> > -   unsigned int old = current->personality;
> > -
> > -   if (personality != 0x)
> > -   set_personality(personality);
> > -
> > -   return old;
> > -}
> > -
> >  /* for __ARCH_WANT_SYS_IPC */
> >  long ksys_semtimedop(int semid, struct sembuf __user *tsops,
> >  unsigned int nsops,
> > diff --git a/kernel/exec_domain.c b/kernel/exec_domain.c
> > index 33f07c5f2515..f3682f4bf205 100644
> > --- a/kernel/exec_domain.c
> > +++ b/kernel/exec_domain.c
> > @@ -35,9 +35,21 @@ static int __init proc_execdomains_init(void)
> >  module_init(proc_execdomains_init);
> >  #endif
> >  
> > +int __weak arch_check_personality(unsigned int personality)
> > +{
> > +   return 0;
> > +}
> > +
> >  SYSCALL_DEFINE1(personality, unsigned int, personality)
> >  {
> > -   unsigned int old = current->personality;
> > +   int err;
> > +   unsigned int old;
> > +
> > +   err = arch_check_personality(personality);
> > +   if (err)
> > +   return err;
> > +
> > +   old = current->personality;
> 
> I'm surprised that the generic sys_personality() doesn't call
> ksys_personality() directly but rather duplicates the code.

It was the other way round, and the duplication is based on a
suggestion by Christoph Hellwig IIRC,
https://lore.kernel.org/lkml/20180514120756.ga11...@infradead.org/

Thanks,
Dominik

[GIT PULL] pcmcia updates for v5.8

[Dominik Brodowski]

Linus,

the following changes since b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce:

  Linux 5.7-rc6 (2020-05-17 16:48:37 -0700)

are available from

  https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git pcmcia-next

up to 46d0797906633d82bd50ef26780ee39fac5d27d6:

  pcmcia: make pccard_loop_tuple() static (2020-05-18 11:16:39 +0200)


Two minor PCMCIA odd fixes, one replacing zero-length arrays with a
flexible-array member, and one making a local function static.


Thanks,
Dominik


Dominik Brodowski (1):
  pcmcia: make pccard_loop_tuple() static

Gustavo A. R. Silva (1):
  pcmcia: Replace zero-length array with flexible-array

 drivers/pcmcia/cs_internal.h | 6 --
 drivers/pcmcia/pcmcia_cis.c  | 6 +++---
 include/pcmcia/cistpl.h  | 6 +++---
 3 files changed, 6 insertions(+), 12 deletions(-)



diff --git a/drivers/pcmcia/cs_internal.h b/drivers/pcmcia/cs_internal.h
index fb9b17fa0fb5..580369f3c0b0 100644
--- a/drivers/pcmcia/cs_internal.h
+++ b/drivers/pcmcia/cs_internal.h
@@ -164,12 +164,6 @@ int pcmcia_replace_cis(struct pcmcia_socket *s,
 int pccard_validate_cis(struct pcmcia_socket *s, unsigned int *count);
 int verify_cis_cache(struct pcmcia_socket *s);
 
-int pccard_loop_tuple(struct pcmcia_socket *s, unsigned int function,
- cisdata_t code, cisparse_t *parse, void *priv_data,
- int (*loop_tuple) (tuple_t *tuple,
-cisparse_t *parse,
-void *priv_data));
-
 int pccard_get_first_tuple(struct pcmcia_socket *s, unsigned int function,
tuple_t *tuple);
 
diff --git a/drivers/pcmcia/pcmcia_cis.c b/drivers/pcmcia/pcmcia_cis.c
index b553f7ab532f..e4c4daf92038 100644
--- a/drivers/pcmcia/pcmcia_cis.c
+++ b/drivers/pcmcia/pcmcia_cis.c
@@ -78,9 +78,9 @@ int pccard_read_tuple(struct pcmcia_socket *s, unsigned int 
function,
  * calls the @loop_tuple function for each entry. If the call to @loop_tuple
  * returns 0, the loop exits. Returns 0 on success or errorcode otherwise.
  */
-int pccard_loop_tuple(struct pcmcia_socket *s, unsigned int function,
- cisdata_t code, cisparse_t *parse, void *priv_data,
- int (*loop_tuple) (tuple_t *tuple,
+static int pccard_loop_tuple(struct pcmcia_socket *s, unsigned int function,
+cisdata_t code, cisparse_t *parse, void *priv_data,
+int (*loop_tuple) (tuple_t *tuple,
 cisparse_t *parse,
 void *priv_data))
 {
diff --git a/include/pcmcia/cistpl.h b/include/pcmcia/cistpl.h
index 59a011101e0e..749320cc9aba 100644
--- a/include/pcmcia/cistpl.h
+++ b/include/pcmcia/cistpl.h
@@ -161,7 +161,7 @@ typedef struct cistpl_funcid_t {
 
 typedef struct cistpl_funce_t {
 u_char type;
-u_char data[0];
+u_char data[];
 } cistpl_funce_t;
 
 /*==
@@ -255,7 +255,7 @@ typedef struct cistpl_data_serv_t {
 u_char escape;
 u_char encrypt;
 u_char misc_features;
-u_char ccitt_code[0];
+u_char ccitt_code[];
 } cistpl_data_serv_t;
 
 typedef struct cistpl_fax_serv_t {
@@ -265,7 +265,7 @@ typedef struct cistpl_fax_serv_t {
 u_char encrypt;
 u_char features_0;
 u_char features_1;
-u_char ccitt_code[0];
+u_char ccitt_code[];
 } cistpl_fax_serv_t;
 
 typedef struct cistpl_voice_serv_t {


signature.asc
Description: PGP signature

Re: [PATCH] pcmcia: Replace zero-length array with flexible-array

[Dominik Brodowski]

On Thu, May 07, 2020 at 02:05:49PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
> 
> struct foo {
> int stuff;
> struct boo array[];
> };
> 
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
> 
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
> 
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
> 
> sizeof(flexible-array-member) triggers a warning because flexible array
> members have incomplete type[1]. There are some instances of code in
> which the sizeof operator is being incorrectly/erroneously applied to
> zero-length arrays and the result is zero. Such instances may be hiding
> some bugs. So, this work (flexible-array member conversions) will also
> help to get completely rid of those sorts of issues.
> 
> This issue was found with the help of Coccinelle.
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied to pcmcia-next.

Thanks,
Dominik

Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Dominik Brodowski]

On Tue, Oct 22, 2019 at 05:17:12AM +1100, Michael . wrote:
> Thank you Dominik for looking at this for us and passing it on.
> 
> Good morning Bjorn, thank you also for looking into this for us and
> thank you for CCing us into this as non of us are on the mailing list.
> One question how do we apply this patch or is this for Dominik to try?

That's for you and/or other users of this hardware; I cannot test this
myself, sorry. As to how to apply the patch: you'd need to apply the patch
for the linux kernel sources, and then build a custom kernel. Some hints on
that (details depend on the distribtion):

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System
https://kernelnewbies.org/KernelBuild

Best,
Dominik

PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]

[Dominik Brodowski]

On the basis of the additional information (thanks), there might be a
more specific path to investigate: It is that the PCI code does not
enumerate the second cardbus bridge PCI function in the more recent 4.19
kernel compared to the anvient (and working) 2.6 kernel.

Namely, only one CardBus bridge is recognized

...
06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
06:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 11)
06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] 
Network Connection (rev 05)
...

instead of the two which really should be present:

...
06:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
06:01.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8b)
06:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 11)
06:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] 
Network Connection (rev 05)
...

To the PCI folks: any idea on what may cause the second cardbus bridge PCI
device function to be missed? Are there any command line options the users
who reported this issue[*] may try?

As this isn't really a PCMCIA (16bit) issue, but a PCI enumeration issue,
this issue is outside my area of expertise.

Thanks,
Dominik

[*] For more information, see this thread:

https://lore.kernel.org/lkml/cafjuqni+knsb9wvqoahcvfyxsiqoggwom7z1aqdbebnzp_-...@mail.gmail.com/

Re: PCMCIA not working on Panasonic Toughbook CF-29

[Dominik Brodowski]

On Tue, Oct 15, 2019 at 05:04:28PM +1100, Michael . wrote:
> Good afternoon kernel developers
> Please accept my apology for contacting you directly about this. A
> small group of friends, some of whom are CCed here, have come together
> to try and find a solution to a problem that originated with the
> demise of kernel 2.6:32. First some background to the issue. We are
> all users of Panasonic Toughbook CF-29 models (ranging from Mark 1
> through to Mark 5). These Toughbooks have 2 PCMCIA card slots which
> are used by a variety of people for different purposes. On the CF-29
> Mark 1 through to Mark 3 these slots work without problem. On the
> CF-29 Mark 4 and Mark 5 the last known kernel the top slot worked with
> was 2.6:32. This has been confirmed all all major distros by most of
> the small group of friends I mentioned earlier.
> 
> Thinking it was just a kernel config issue I did some comparisons
> between Debian 6 (Squeeze), Debian 7 (Wheezy), Ubuntu 10.04, and
> Ubuntu 10.10. On all machines both slots functioned as they should
> with Debian 6 and Ubuntu 10.04 but the top slot stopped working on
> Mark 4 and Mark 5 machines on the next release with the next kernel. I
> also tested Ubuntu 10.04 and 10.10 with the 2.6:32 and 2.6:35 kernel
> and both slots worked with the 2.6:32 kernel but not the 2.6:35
> kernel.With my comparisons I merged the config from 2.6:32 into the
> current kernel for Debian 4.19 and rebuilt the kernel, no matter what
> configuration changes I made the top slot still doesn't function on
> Mark 4 and Mark 5 machines.
> 
> This issue, and its apparent start, has been confirmed on all major
> distro family groups. So this brings me, actually the small group of
> dedicated Linux users who own Panasonic Toughbook CF-29s, to contact
> you to ask for help in resolving this issue. I have some questions,
> and I realise the 2.6:32 kernel is long gone now but I'm hoping this
> is not a lost cause, what changes would have occurred between 2.6:32
> and 2.6:33 that would have stopped the hardware working on Mark 4 and
> Mark 5 CF-29 Toughbooks but not Mark 1 through to Mark 3? Would it be
> possible to correct the problem so that the hardware on our machines
> works as it should. While we are not kernel devs or even programmers
> we are enthusiasts who love Linux and our machines and we are hoping
> that together with you and the kernel dev group we can fix this issue
> together.
> 
> I have attached various tar.gz files with ls* outputs so you can see
> the information we have so far. Thank you for taking the time to read
> this.

Is this with 16-bit PCMCIA cards, or with 32-bit CardBus cards? Either case,
please provide the output of

dmesg

lspci -vvv

and

lspcmcia -v -v

(ideally all for a working and non-working configuration).

Thanks,
Dominik

[PATCH] random: inform about bootloader-provided randomness

[Dominik Brodowski]

Inform how many bits of randomness were provided by the bootloader,
and whether we trust that input.

Signed-off-by: Dominik Brodowski 
Cc: Ard Biesheuvel 
Cc: Hsin-Yi Wang 
Cc: Stephen Boyd 
Cc: Rob Herring 
Cc: Theodore Ts'o 
Cc: Will Deacon 

diff --git a/drivers/char/random.c b/drivers/char/random.c
index de434feb873a..673375e05c0d 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2515,6 +2515,10 @@ EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
  */
 void add_bootloader_randomness(const void *buf, unsigned int size)
 {
+   pr_notice("random: adding %u bits of %sbootloader-provided randomness",
+   size * 8,
+   IS_ENABLED(CONFIG_RANDOM_TRUST_BOOTLOADER) ? "trusted " : "");
+
if (IS_ENABLED(CONFIG_RANDOM_TRUST_BOOTLOADER))
add_hwgenerator_randomness(buf, size, size * 8);
else

lockdep warning on thunderbolt docking

[Dominik Brodowski]

When connecting a thunderbolt-enabled docking station to my work laptop,
the following lockdep warning is reported on v5.3.0-rc6+ as of Thursday
morning (can look up the exact git id if so required):


thunderbolt 0-1: new device found, vendor=0xd4 device=0xb070
thunderbolt 0-1: Dell WD19TB Thunderbolt Dock

==
WARNING: possible circular locking dependency detected
5.3.0-rc6+ #1 Tainted: GT
--
pool-/usr/lib/b/1258 is trying to acquire lock:
5ab0ad43 (pci_rescan_remove_lock){+.+.}, at: authorized_store+0xe8/0x210

but task is already holding lock:
bfb796b5 (>lock){+.+.}, at: authorized_store+0x7c/0x210

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (>lock){+.+.}:
   __mutex_lock+0xac/0x9a0
   tb_domain_add+0x2d/0x130
   nhi_probe+0x1dd/0x330
   pci_device_probe+0xd2/0x150
   really_probe+0xee/0x280
   driver_probe_device+0x50/0xc0
   bus_for_each_drv+0x84/0xd0
   __device_attach+0xe4/0x150
   pci_bus_add_device+0x4e/0x70
   pci_bus_add_devices+0x2e/0x66
   pci_bus_add_devices+0x59/0x66
   pci_bus_add_devices+0x59/0x66
   enable_slot+0x344/0x450
   acpiphp_check_bridge.part.0+0x119/0x150
   acpiphp_hotplug_notify+0xaa/0x140
   acpi_device_hotplug+0xa2/0x3f0
   acpi_hotplug_work_fn+0x1a/0x30
   process_one_work+0x234/0x580
   worker_thread+0x50/0x3b0
   kthread+0x10a/0x140
   ret_from_fork+0x3a/0x50

-> #0 (pci_rescan_remove_lock){+.+.}:
   __lock_acquire+0xe54/0x1ac0
   lock_acquire+0xb8/0x1b0
   __mutex_lock+0xac/0x9a0
   authorized_store+0xe8/0x210
   kernfs_fop_write+0x125/0x1b0
   vfs_write+0xc2/0x1d0
   ksys_write+0x6c/0xf0
   do_syscall_64+0x50/0x180
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

other info that might help us debug this:
 Possible unsafe locking scenario:
   CPU0CPU1
   
  lock(>lock);
   lock(pci_rescan_remove_lock);
   lock(>lock);
  lock(pci_rescan_remove_lock);

 *** DEADLOCK ***
5 locks held by pool-/usr/lib/b/1258:
 #0: 3df1a1ad (>f_pos_lock){+.+.}, at: __fdget_pos+0x4d/0x60
 #1: 95a40b02 (sb_writers#6){.+.+}, at: vfs_write+0x185/0x1d0
 #2: 17a7d714 (>mutex){+.+.}, at: kernfs_fop_write+0xf2/0x1b0
 #3: 4f262981 (kn->count#208){.+.+}, at: kernfs_fop_write+0xfa/0x1b0
 #4: bfb796b5 (>lock){+.+.}, at: authorized_store+0x7c/0x210

stack backtrace:
CPU: 0 PID: 1258 Comm: pool-/usr/lib/b Tainted: GT 5.3.0-rc6+ #1


Thanks,
Dominik

Re: [PATCH v2 19/35] pcmcia: Use kmemdup rather than duplicating its implementation

[Dominik Brodowski]

On Thu, Jul 04, 2019 at 12:29:43AM +0800, Fuqian Huang wrote:
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code and also reduce the chances of mistakes.
> Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy.
> 
> Signed-off-by: Fuqian Huang 
Acked-by: Dominik Brodowski 

Thanks,
Dominik

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

[Dominik Brodowski]

On Sun, May 12, 2019 at 03:18:16AM -0700, h...@zytor.com wrote:
> > Couldn't this parsing of the .xattr-list file and the setting of the xattrs
> > be done equivalently by the initramfs' /init? Why is kernel involvement
> > actually required here?
> 
> There are a lot of things that could/should be done that way...

Indeed... so why not try to avoid adding more such "things", and keeping
them in userspace (or in a fork_usermode_blob)?


On Sun, May 12, 2019 at 08:52:47AM -0400, Mimi Zohar wrote:
> It's too late.  The /init itself should be signed and verified.

Could you elaborate a bit more about the threat model, and why deferring
this to the initramfs is too late?

Thanks,
Dominik

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

[Dominik Brodowski]

On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
> This proposal consists in marshaling pathnames and xattrs in a file called
> .xattr-list. They are unmarshaled by the CPIO parser after all files have
> been extracted.

Couldn't this parsing of the .xattr-list file and the setting of the xattrs
be done equivalently by the initramfs' /init? Why is kernel involvement
actually required here?

Thanks,
Dominik

Re: [PATCH] drivers: pcmcia: This patch fix the following checkpatch warning.

[Dominik Brodowski]

On Tue, Apr 16, 2019 at 08:45:44PM +0300, Mohan Kumar wrote:
> Switch hardcoded function name with a reference to __func__ making the
> code more maintainable

Thanks for your patch. Are there any other patches pending to this driver?

As noted in Kconfig, the TCIC host briges "are only found on a handful of
old systems". Therefore, I am a bit reluctant to apply this patch,
especially as the much more in this file does not adhere to current kernel
CodingStyle practices.

Thanks,
Dominik

Re: fs_context-related oops in mainline

[Dominik Brodowski]

On Fri, Mar 15, 2019 at 12:18:13PM +, Al Viro wrote:
> On Fri, Mar 15, 2019 at 12:50:02PM +0100, Dominik Brodowski wrote:
> > On Fri, Mar 15, 2019 at 11:44:45AM +, David Howells wrote:
> > > Dominik Brodowski  wrote:
> > > 
> > > > [0.839322] RIP: 0010:sysfs_init_fs_context+0x82/0xd0
> > > 
> > > Could you load your kernel into gdb and then do:
> > > 
> > >   i li *sysfs_init_fs_context+0x82
> > 
> > Doesn't seem necessary as per my mail to Al a few seconds ago:
> > kobj_ns_grab_current(KOBJ_NS_TYPE_NET) returns NULL, so
> > 
> > fc->user_ns = get_user_ns(netns->user_ns);
> > 
> > will try to dereference a null pointer.
> > 
> > Thanks,
> > Dominik
> > 
> 
> Charming...  It's netns being turned off, and the thing we'd missed
> is that kobj_ns_current_may_mount() becomes constant true in that
> setup.  IOW, ns_capable(..., CAP_SYS_ADMIN) is suppressed entirely
> in that case (well, aside of what may_mount() has done in
> do_mount/sys_fsmount).
> 
> So what we need is making that "change fc->user_ns" conditional
> on netns != NULL, as in
> 
> diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
> index 4cb21b558a85..1b56686ab178 100644
> --- a/fs/sysfs/mount.c
> +++ b/fs/sysfs/mount.c
> @@ -71,9 +71,11 @@ static int sysfs_init_fs_context(struct fs_context *fc)
>   kfc->magic = SYSFS_MAGIC;
>   fc->fs_private = kfc;
>   fc->ops = _fs_context_ops;
> - if (fc->user_ns)
> - put_user_ns(fc->user_ns);
> - fc->user_ns = get_user_ns(netns->user_ns);
> + if (netns) {
> + if (fc->user_ns)
> + put_user_ns(fc->user_ns);
> + fc->user_ns = get_user_ns(netns->user_ns);
> + }
>   fc->global = true;
>   return 0;
>  }

That fixes the issue at hand, thanks (verified both on top of the
problematic commit and on top of mainline).

Thanks,
Dominik

Re: fs_context-related oops in mainline

[Dominik Brodowski]

On Fri, Mar 15, 2019 at 11:44:45AM +, David Howells wrote:
> Dominik Brodowski  wrote:
> 
> > [0.839322] RIP: 0010:sysfs_init_fs_context+0x82/0xd0
> 
> Could you load your kernel into gdb and then do:
> 
>   i li *sysfs_init_fs_context+0x82

Doesn't seem necessary as per my mail to Al a few seconds ago:
kobj_ns_grab_current(KOBJ_NS_TYPE_NET) returns NULL, so

fc->user_ns = get_user_ns(netns->user_ns);

will try to dereference a null pointer.

Thanks,
Dominik

Re: fs_context-related oops in mainline

[Dominik Brodowski]

On Fri, Mar 15, 2019 at 11:34:47AM +, Al Viro wrote:
> On Fri, Mar 15, 2019 at 08:43:07AM +0100, Dominik Brodowski wrote:
> > David, Al,
> > 
> > commit 23bf1b6be9c2 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
> > seems to have introduced a bug; at least that's the commit I bisected the
> > following oops down to:

As additional information: In sysfs_init_fs_context, we have

kfc->ns_tag = netns = kobj_ns_grab_current(KOBJ_NS_TYPE_NET);
...
fc->user_ns = get_user_ns(netns->user_ns);

With my config, kobj_ns_grab_current() returns NULL here, which obviously
causes a null pointer dereference when trying to set fs->user_ns.

Probably the most important line of the .config (attached):

# CONFIG_NET is not set

Thanks,
Dominik
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 5.0.0-rc2 Kernel Configuration
#

#
# Compiler: gcc (GCC) 8.2.1 20181127
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=80201
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_PSI is not set
# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=13
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
# CONFIG_EXPERT is not set
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENT

fs_context-related oops in mainline

[Dominik Brodowski]

David, Al,

commit 23bf1b6be9c2 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
seems to have introduced a bug; at least that's the commit I bisected the
following oops down to:

[0.827317] BUG: unable to handle kernel NULL pointer dereference at 
0220
[0.829771] #PF error: [normal kernel read fault]
[0.831141] PGD 80007f927067 P4D 80007f927067 PUD 7f928067 PMD 0 
[0.833116] Oops:  [#1] PREEMPT SMP PTI
[0.834330] CPU: 1 PID: 46 Comm: mount Tainted: GT 
5.0.0-rc2+ #38
[0.836478] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.12.0-20181126_142135-anatol 04/01/2014
[0.839322] RIP: 0010:sysfs_init_fs_context+0x82/0xd0
[0.840777] Code: 15 fb ef af 01 48 89 45 08 48 c7 45 10 72 65 65 62 48 c7 
03 60 66 22 8f 48 85 ff 48 89 55 00 74 09 f0 ff 8f 5
[0.846170] RSP: 0018:a55e8041bdb8 EFLAGS: 00010202
[0.847693] RAX:  RBX: 949bbc0fee00 RCX: 
[0.850013] RDX: 949bbc878d00 RSI:  RDI: 8f645c40
[0.852134] RBP: 949bbc0ff400 R08: 0001 R09: 001ef140
[0.854211] R10: 000136a1068e R11: 0001 R12: 
[0.856225] R13:  R14:  R15: 8000
[0.858350] FS:  0050b558() GS:949bbce0() 
knlGS:
[0.860738] CS:  0010 DS:  ES:  CR0: 80050033
[0.862391] CR2: 0220 CR3: 7c1f0004 CR4: 003606e0
[0.864463] Call Trace:
[0.865200]  alloc_fs_context+0xfa/0x170
[0.866349]  do_mount+0x8fa/0xf50
[0.867310]  ? memdup_user+0x4b/0x70
[0.868350]  ksys_mount+0xba/0xd0
[0.869291]  __x64_sys_mount+0x21/0x30
[0.870390]  do_syscall_64+0x6a/0x3f4
[0.871465]  ? lockdep_hardirqs_off+0x79/0xd0
[0.872744]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[0.874106]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[0.875584] RIP: 0033:0x4bf02f
[0.876496] Code: e8 06 21 f4 ff 5a c3 48 63 ff 50 48 63 d2 b8 67 00 00 00 
0f 05 48 89 c7 e8 ee 20 f4 ff 5a c3 49 89 ca 50 b8 8
[0.882329] RSP: 002b:7ffc1befbd80 EFLAGS: 0212 ORIG_RAX: 
00a5
[0.884110] RAX: ffda RBX: 7ffc1befc058 RCX: 004bf02f
[0.885871] RDX: 7ffc1befdf84 RSI: 7ffc1befdf90 RDI: 7ffc1befdf8a
[0.888102] RBP: 7ffc1befdf8a R08:  R09: 8080808080808080
[0.890154] R10: 8000 R11: 0212 R12: 7ffc1befdf90
[0.892107] R13: 7ffc1befdf84 R14: 8000 R15: 
[0.893537] CR2: 0220
[0.894467] ---[ end trace 0a9affd2a96301a9 ]---
[0.896230] RIP: 0010:sysfs_init_fs_context+0x82/0xd0
[0.897494] Code: 15 fb ef af 01 48 89 45 08 48 c7 45 10 72 65 65 62 48 c7 
03 60 66 22 8f 48 85 ff 48 89 55 00 74 09 f0 ff 8f 5
[0.903017] RSP: 0018:a55e8041bdb8 EFLAGS: 00010202
[0.904315] RAX:  RBX: 949bbc0fee00 RCX: 
[0.905857] RDX: 949bbc878d00 RSI:  RDI: 8f645c40
[0.907444] RBP: 949bbc0ff400 R08: 0001 R09: 001ef140
[0.909973] R10: 000136a1068e R11: 0001 R12: 
[0.911415] R13:  R14:  R15: 8000
[0.913726] FS:  0050b558() GS:949bbce0() 
knlGS:
[0.916710] CS:  0010 DS:  ES:  CR0: 80050033
[0.918129] CR2: 0220 CR3: 7c1f0004 CR4: 003606e0

This occurs while trying to mount sysfs in initramfs

mount -n -t sysfs sysfs /sys

All this obviously runs in qemu; config and further information are available 
upon request.

Thanks,
Dominik

Re: [PATCH] x86/asm: Pin sensitive CR4 bits

[Dominik Brodowski]

On Tue, Feb 19, 2019 at 04:54:49PM -0800, Kees Cook wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index cb28e98a0659..7e0ea4470f8e 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -312,10 +312,16 @@ static __init int setup_disable_smep(char *arg)
>  }
>  __setup("nosmep", setup_disable_smep);
>  
> +volatile unsigned long cr4_pin __ro_after_init;
> +EXPORT_SYMBOL_GPL(cr4_pin);

Where is this export needed?

Thanks,
Dominik

Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max

[Dominik Brodowski]

On Thu, Jan 10, 2019 at 03:50:05PM +0100, Christian Brauner wrote:
> On Tue, Jan 08, 2019 at 08:01:10AM +0100, Dominik Brodowski wrote:
> > On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote:
> > > @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec_minmax(void *data, 
> > > struct ctl_table *table, int
> > >   break;
> > >   if (neg)
> > >   continue;
> > > + if ((max && val > *max) || (min && val < *min)) {
> > > + err = -EINVAL;
> > > + break;
> > > + }
> > >   val = convmul * val / convdiv;
> > >   if ((min && val < *min) || (max && val > *max))
> > >   continue;
> > 
> > This is a generic change which affects all users of
> > do_proc_doulongvec_minmax() that have extra1 or extra2 set. In sysctl.c, I
> > do not see another user of proc_doulongvec_minmax() that has extra1 or
> > extra2 set. However, have you verified whether your patch changes the
> > behaviour for other files that make use of proc_doulongvec_minmax() or
> > proc_doulongvec_ms_jiffies_minmax(), and not only of the file-max sysctl?
> 
> Sorry for the delayed reply. I did look at the callers. The functions
> that are of interest afaict are:
> 
> proc_doulongvec_ms_jiffies_minmax
> proc_doulongvec_minmax
> 
> So this could be visible when users write values that would overflow the
> type used in the kernel.
>
> I guess your point is whether we are venturing into userspace break
> territory. Hm... We should probably make sure that we're not regressing
> anyone else! What do you think if instead of the above patch we did:

Hm, I prefer the original patch -- as the same (valid) reasons which apply
for the file-max sysctl might also apply to other users of this function
where extra1 and/or2 extra2 are set.

If there are no other users of this function where extra1 or extra2 are set,
just add a comment in the commit message:

While this changes the behaviour of __do_proc_doulongvec_minmax(),
no other existing users in the kernel are affected by this change.

If there are other users of this function where extra1 or extra2 are set,
you would need to generalize the commit message overall.

Thanks,
Dominik

Re: [RESEND PATCH v3 2/2] sysctl: handle overflow for file-max

[Dominik Brodowski]

On Mon, Jan 07, 2019 at 11:27:00PM +0100, Christian Brauner wrote:
> @@ -2833,6 +2836,10 @@ static int __do_proc_doulongvec_minmax(void *data, 
> struct ctl_table *table, int
>   break;
>   if (neg)
>   continue;
> + if ((max && val > *max) || (min && val < *min)) {
> + err = -EINVAL;
> + break;
> + }
>   val = convmul * val / convdiv;
>   if ((min && val < *min) || (max && val > *max))
>   continue;

This is a generic change which affects all users of
do_proc_doulongvec_minmax() that have extra1 or extra2 set. In sysctl.c, I
do not see another user of proc_doulongvec_minmax() that has extra1 or
extra2 set. However, have you verified whether your patch changes the
behaviour for other files that make use of proc_doulongvec_minmax() or
proc_doulongvec_ms_jiffies_minmax(), and not only of the file-max sysctl?

Thanks,
Dominik

Re: *powersave* governor shown despite disabled in configuration

[Dominik Brodowski]

On Mon, Dec 10, 2018 at 04:30:05PM +0100, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> With Linux 4.14.76, the scaling governor *powersave* is shown as
> being available despite being disabled in the configuration.

Which cpufreq driver do you use? Presumably intel_pstate? That driver
exposes internal policies / "governors" named "performance" and "powersave",
which are unrelated to CONFIG_CPU_FREQ_GOV_POWERSAVE.

Thanks,
Dominik

Re: [PATCH] pcmcia: remove per-arch PCMCIA config entry

[Dominik Brodowski]

On Mon, Nov 26, 2018 at 05:15:41PM +0900, Masahiro Yamada wrote:
> Now that all architectures include drivers/pcmcia/Kconfig where
> the PCMCIA config is defined, the PCMCIA config entries in per-arch
> Kconfig files are redundant.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> I will queue this up to my kbuild tree
> along with Christoph's clean-up patch set.

Acked-by: Dominik Brodowski 

Thanks,
Dominik

Re: [PATCH] pcmcia: remove per-arch PCMCIA config entry

[Dominik Brodowski]

On Mon, Nov 26, 2018 at 05:15:41PM +0900, Masahiro Yamada wrote:
> Now that all architectures include drivers/pcmcia/Kconfig where
> the PCMCIA config is defined, the PCMCIA config entries in per-arch
> Kconfig files are redundant.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> I will queue this up to my kbuild tree
> along with Christoph's clean-up patch set.

Acked-by: Dominik Brodowski 

Thanks,
Dominik

Re: [patch V2 26/28] x86/speculation: Enable prctl mode for spectre_v2_user

[Dominik Brodowski]

On Sun, Nov 25, 2018 at 07:33:54PM +0100, Thomas Gleixner wrote:
> + prctl   - Indirect branch speculation is enabled,
> +   but mitigation can be enabled via prctl

s/can be/is only/ or "must be".

Thanks,
Dominik

Re: [patch V2 26/28] x86/speculation: Enable prctl mode for spectre_v2_user

[Dominik Brodowski]

On Sun, Nov 25, 2018 at 07:33:54PM +0100, Thomas Gleixner wrote:
> + prctl   - Indirect branch speculation is enabled,
> +   but mitigation can be enabled via prctl

s/can be/is only/ or "must be".

Thanks,
Dominik

Re: Linux 4.19.0 Build Error when CONFIG_ACPI not set.

[Dominik Brodowski]

On Mon, Oct 29, 2018 at 11:53:38AM +0100, Thomas-Mich Richter wrote:
> When I compile the 4.19.0 Linux kernel, I get this build error:
> 
> [root@f28 linux]# fgrep -r CONFIG_ACPI .config
> # CONFIG_ACPI is not set
> [root@f28 linux]#
> 
> [root@f28 linux]# make
>   CALLscripts/checksyscalls.sh
>   DESCEND  objtool
>   CHK include/generated/compile.h
>   CC  drivers/cpufreq/intel_pstate.o
> drivers/cpufreq/intel_pstate.c: In function ‘show_base_frequency’:
> drivers/cpufreq/intel_pstate.c:726:10: error: implicit declaration of
> function ‘intel_pstate_get_cppc_guranteed’;
> did you mean ‘intel_pstate_get_epp’?
> [-Werror=implicit-function-declaration]
> ratio = intel_pstate_get_cppc_guranteed(policy->cpu);
> ^~~
> intel_pstate_get_epp
> cc1: some warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:306: drivers/cpufreq/intel_pstate.o]
> Error 1
> make[1]: *** [scripts/Makefile.build:546: drivers/cpufreq] Error 2
> make: *** [Makefile:1052: drivers] Error 2
> [root@f28 linux]# 
> 
> I am building on a virtual machine.
> 
> This was introduced with
> commit 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
> 
> The function intel_pstate_get_cppc_guranteed() is called but the function
> definition is within #ifdef CONFIG_ACPI/#endif conditional compile.
> 
> Any ideas how to fix this?

This isn't in 4.19.0, but in current mainline, and can be fixed by this
patch which is already on its way upstream.

https://patchwork.kernel.org/patch/10653593/

Thanks,
Dominik


Date: Tue, 23 Oct 2018 21:54:03 +0200
From: Dominik Brodowski 
Subject: [PATCH v2] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

While at it, add a few comments which config options #ifdef
and #else statements refer to.

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Signed-off-by: Dominik Brodowski 

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 49c0abf2d48f..9578312e43f2 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -386,16 +386,11 @@ static int intel_pstate_get_cppc_guranteed(int cpu)
return cppc_perf.guaranteed_perf;
 }
 
-#else
+#else /* CONFIG_ACPI_CPPC_LIB */
 static void intel_pstate_set_itmt_prio(int cpu)
 {
 }
-
-static int intel_pstate_get_cppc_guranteed(int cpu)
-{
-   return -ENOTSUPP;
-}
-#endif
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
 {
@@ -477,7 +472,7 @@ static void intel_pstate_exit_perf_limits(struct 
cpufreq_policy *policy)
 
acpi_processor_unregister_performance(policy->cpu);
 }
-#else
+#else /* CONFIG_ACPI */
 static inline void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy 
*policy)
 {
 }
@@ -490,7 +485,14 @@ static inline bool 
intel_pstate_acpi_pm_profile_server(void)
 {
return false;
 }
-#endif
+#endif /* CONFIG_ACPI */
+
+#ifndef CONFIG_ACPI_CPPC_LIB
+static int intel_pstate_get_cppc_guranteed(int cpu)
+{
+   return -ENOTSUPP;
+}
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static inline void update_turbo_state(void)
 {

Re: Linux 4.19.0 Build Error when CONFIG_ACPI not set.

[Dominik Brodowski]

On Mon, Oct 29, 2018 at 11:53:38AM +0100, Thomas-Mich Richter wrote:
> When I compile the 4.19.0 Linux kernel, I get this build error:
> 
> [root@f28 linux]# fgrep -r CONFIG_ACPI .config
> # CONFIG_ACPI is not set
> [root@f28 linux]#
> 
> [root@f28 linux]# make
>   CALLscripts/checksyscalls.sh
>   DESCEND  objtool
>   CHK include/generated/compile.h
>   CC  drivers/cpufreq/intel_pstate.o
> drivers/cpufreq/intel_pstate.c: In function ‘show_base_frequency’:
> drivers/cpufreq/intel_pstate.c:726:10: error: implicit declaration of
> function ‘intel_pstate_get_cppc_guranteed’;
> did you mean ‘intel_pstate_get_epp’?
> [-Werror=implicit-function-declaration]
> ratio = intel_pstate_get_cppc_guranteed(policy->cpu);
> ^~~
> intel_pstate_get_epp
> cc1: some warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:306: drivers/cpufreq/intel_pstate.o]
> Error 1
> make[1]: *** [scripts/Makefile.build:546: drivers/cpufreq] Error 2
> make: *** [Makefile:1052: drivers] Error 2
> [root@f28 linux]# 
> 
> I am building on a virtual machine.
> 
> This was introduced with
> commit 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
> 
> The function intel_pstate_get_cppc_guranteed() is called but the function
> definition is within #ifdef CONFIG_ACPI/#endif conditional compile.
> 
> Any ideas how to fix this?

This isn't in 4.19.0, but in current mainline, and can be fixed by this
patch which is already on its way upstream.

https://patchwork.kernel.org/patch/10653593/

Thanks,
Dominik


Date: Tue, 23 Oct 2018 21:54:03 +0200
From: Dominik Brodowski 
Subject: [PATCH v2] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

While at it, add a few comments which config options #ifdef
and #else statements refer to.

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Signed-off-by: Dominik Brodowski 

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 49c0abf2d48f..9578312e43f2 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -386,16 +386,11 @@ static int intel_pstate_get_cppc_guranteed(int cpu)
return cppc_perf.guaranteed_perf;
 }
 
-#else
+#else /* CONFIG_ACPI_CPPC_LIB */
 static void intel_pstate_set_itmt_prio(int cpu)
 {
 }
-
-static int intel_pstate_get_cppc_guranteed(int cpu)
-{
-   return -ENOTSUPP;
-}
-#endif
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
 {
@@ -477,7 +472,7 @@ static void intel_pstate_exit_perf_limits(struct 
cpufreq_policy *policy)
 
acpi_processor_unregister_performance(policy->cpu);
 }
-#else
+#else /* CONFIG_ACPI */
 static inline void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy 
*policy)
 {
 }
@@ -490,7 +485,14 @@ static inline bool 
intel_pstate_acpi_pm_profile_server(void)
 {
return false;
 }
-#endif
+#endif /* CONFIG_ACPI */
+
+#ifndef CONFIG_ACPI_CPPC_LIB
+static int intel_pstate_get_cppc_guranteed(int cpu)
+{
+   return -ENOTSUPP;
+}
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static inline void update_turbo_state(void)
 {

[PATCH v2] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

[Dominik Brodowski]

While at it, add a few comments which config options #ifdef
and #else statements refer to.

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Signed-off-by: Dominik Brodowski 

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 49c0abf2d48f..9578312e43f2 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -386,16 +386,11 @@ static int intel_pstate_get_cppc_guranteed(int cpu)
return cppc_perf.guaranteed_perf;
 }
 
-#else
+#else /* CONFIG_ACPI_CPPC_LIB */
 static void intel_pstate_set_itmt_prio(int cpu)
 {
 }
-
-static int intel_pstate_get_cppc_guranteed(int cpu)
-{
-   return -ENOTSUPP;
-}
-#endif
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
 {
@@ -477,7 +472,7 @@ static void intel_pstate_exit_perf_limits(struct 
cpufreq_policy *policy)
 
acpi_processor_unregister_performance(policy->cpu);
 }
-#else
+#else /* CONFIG_ACPI */
 static inline void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy 
*policy)
 {
 }
@@ -490,7 +485,14 @@ static inline bool 
intel_pstate_acpi_pm_profile_server(void)
 {
return false;
 }
-#endif
+#endif /* CONFIG_ACPI */
+
+#ifndef CONFIG_ACPI_CPPC_LIB
+static int intel_pstate_get_cppc_guranteed(int cpu)
+{
+   return -ENOTSUPP;
+}
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static inline void update_turbo_state(void)
 {

[PATCH v2] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

[Dominik Brodowski]

While at it, add a few comments which config options #ifdef
and #else statements refer to.

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Signed-off-by: Dominik Brodowski 

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 49c0abf2d48f..9578312e43f2 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -386,16 +386,11 @@ static int intel_pstate_get_cppc_guranteed(int cpu)
return cppc_perf.guaranteed_perf;
 }
 
-#else
+#else /* CONFIG_ACPI_CPPC_LIB */
 static void intel_pstate_set_itmt_prio(int cpu)
 {
 }
-
-static int intel_pstate_get_cppc_guranteed(int cpu)
-{
-   return -ENOTSUPP;
-}
-#endif
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
 {
@@ -477,7 +472,7 @@ static void intel_pstate_exit_perf_limits(struct 
cpufreq_policy *policy)
 
acpi_processor_unregister_performance(policy->cpu);
 }
-#else
+#else /* CONFIG_ACPI */
 static inline void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy 
*policy)
 {
 }
@@ -490,7 +485,14 @@ static inline bool 
intel_pstate_acpi_pm_profile_server(void)
 {
return false;
 }
-#endif
+#endif /* CONFIG_ACPI */
+
+#ifndef CONFIG_ACPI_CPPC_LIB
+static int intel_pstate_get_cppc_guranteed(int cpu)
+{
+   return -ENOTSUPP;
+}
+#endif /* CONFIG_ACPI_CPPC_LIB */
 
 static inline void update_turbo_state(void)
 {

Re: [PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

[Dominik Brodowski]

On Tue, Oct 23, 2018 at 12:17:28PM -0700, Srinivas Pandruvada wrote:
> On Tue, 2018-10-23 at 20:54 +0200, Dominik Brodowski wrote:
> > Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency
> > attribute")
> Thanks for the fix.
> 
> > Cc: Srinivas Pandruvada 
> > Cc: Rafael J. Wysocki 
> > Cc: Len Brown 
> > Signed-off-by: Dominik Brodowski 
> > 
> > diff --git a/drivers/cpufreq/intel_pstate.c
> > b/drivers/cpufreq/intel_pstate.c
> > index 49c0abf2d48f..50c5699970c5 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -390,11 +390,6 @@ static int intel_pstate_get_cppc_guranteed(int
> > cpu)
> >  static void intel_pstate_set_itmt_prio(int cpu)
> >  {
> >  }
> > -
> > -static int intel_pstate_get_cppc_guranteed(int cpu)
> > -{
> > -   return -ENOTSUPP;
> > -}
> What is ACPI is defined but SCHED_MC_PRIO is not defined?
> Based on
> "select ACPI_CPPC_LIB if X86_64 && ACPI && SCHED_MC_PRIO"
> 
> So the above is still required. correct?

Seems so, yes. Though that leads to either complicated #ifdefs or code
duplications.

In any case, I'd suggest marking at least nested #else and #endif lines
with comments denoting which #ifdef they relate to, e.g.

#else   /* CONFIG_ACPI */
#endif  /* CONFIG_ACPI */

Thanks,
Dominik

Re: [PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

[Dominik Brodowski]

On Tue, Oct 23, 2018 at 12:17:28PM -0700, Srinivas Pandruvada wrote:
> On Tue, 2018-10-23 at 20:54 +0200, Dominik Brodowski wrote:
> > Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency
> > attribute")
> Thanks for the fix.
> 
> > Cc: Srinivas Pandruvada 
> > Cc: Rafael J. Wysocki 
> > Cc: Len Brown 
> > Signed-off-by: Dominik Brodowski 
> > 
> > diff --git a/drivers/cpufreq/intel_pstate.c
> > b/drivers/cpufreq/intel_pstate.c
> > index 49c0abf2d48f..50c5699970c5 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -390,11 +390,6 @@ static int intel_pstate_get_cppc_guranteed(int
> > cpu)
> >  static void intel_pstate_set_itmt_prio(int cpu)
> >  {
> >  }
> > -
> > -static int intel_pstate_get_cppc_guranteed(int cpu)
> > -{
> > -   return -ENOTSUPP;
> > -}
> What is ACPI is defined but SCHED_MC_PRIO is not defined?
> Based on
> "select ACPI_CPPC_LIB if X86_64 && ACPI && SCHED_MC_PRIO"
> 
> So the above is still required. correct?

Seems so, yes. Though that leads to either complicated #ifdefs or code
duplications.

In any case, I'd suggest marking at least nested #else and #endif lines
with comments denoting which #ifdef they relate to, e.g.

#else   /* CONFIG_ACPI */
#endif  /* CONFIG_ACPI */

Thanks,
Dominik

[PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

[Dominik Brodowski]

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Cc: Len Brown 
Signed-off-by: Dominik Brodowski 

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 49c0abf2d48f..50c5699970c5 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -390,11 +390,6 @@ static int intel_pstate_get_cppc_guranteed(int cpu)
 static void intel_pstate_set_itmt_prio(int cpu)
 {
 }
-
-static int intel_pstate_get_cppc_guranteed(int cpu)
-{
-   return -ENOTSUPP;
-}
 #endif
 
 static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
@@ -490,6 +485,11 @@ static inline bool 
intel_pstate_acpi_pm_profile_server(void)
 {
return false;
 }
+
+static int intel_pstate_get_cppc_guranteed(int cpu)
+{
+   return -ENOTSUPP;
+}
 #endif
 
 static inline void update_turbo_state(void)

[PATCH] cpufreq: intel_pstate: Fix compilation for !CONFIG_ACPI

[Dominik Brodowski]

Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute")
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Cc: Len Brown 
Signed-off-by: Dominik Brodowski 

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 49c0abf2d48f..50c5699970c5 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -390,11 +390,6 @@ static int intel_pstate_get_cppc_guranteed(int cpu)
 static void intel_pstate_set_itmt_prio(int cpu)
 {
 }
-
-static int intel_pstate_get_cppc_guranteed(int cpu)
-{
-   return -ENOTSUPP;
-}
 #endif
 
 static void intel_pstate_init_acpi_perf_limits(struct cpufreq_policy *policy)
@@ -490,6 +485,11 @@ static inline bool 
intel_pstate_acpi_pm_profile_server(void)
 {
return false;
 }
+
+static int intel_pstate_get_cppc_guranteed(int cpu)
+{
+   return -ENOTSUPP;
+}
 #endif
 
 static inline void update_turbo_state(void)

Re: [PATCH] char: pcmcia: cm4000_cs: Replace mdelay with usleep_range in set_protocol

[Dominik Brodowski]

On Sun, Mar 18, 2018 at 04:12:10PM +0100, Harald Welte wrote:
> Hi Jia-Ju Bai,
> 
> On Sun, Mar 18, 2018 at 10:49:57PM +0800, Jia-Ju Bai wrote:
> > This is found by a static analysis tool named DCNS written by myself.
> 
> nice catch!
> 
> > Signed-off-by: Jia-Ju Bai 
> 
> Acked-by: Harald Welte 

Applied to pcmcia-next.

Thanks,
Dominik

Re: [PATCH] char: pcmcia: cm4000_cs: Replace mdelay with usleep_range in set_protocol

[Dominik Brodowski]

On Sun, Mar 18, 2018 at 04:12:10PM +0100, Harald Welte wrote:
> Hi Jia-Ju Bai,
> 
> On Sun, Mar 18, 2018 at 10:49:57PM +0800, Jia-Ju Bai wrote:
> > This is found by a static analysis tool named DCNS written by myself.
> 
> nice catch!
> 
> > Signed-off-by: Jia-Ju Bai 
> 
> Acked-by: Harald Welte 

Applied to pcmcia-next.

Thanks,
Dominik

Re: [PATCH] pcmcia: pcmcia_resource: Replace mdelay() with msleep()

[Dominik Brodowski]

On Mon, Jul 30, 2018 at 09:42:56PM +0800, Jia-Ju Bai wrote:
> pcmcia_fixup_iowidth() and pcmcia_enable_device() are 
> never called in atomic context.
> They call mdelay() to busily wait, which is not necessary.
> mdelay() can be replaced with msleep().
> 
> This is found by a static analysis tool named DCNS written by myself.
> 
> Signed-off-by: Jia-Ju Bai 

Applied to pcmcia-next, thanks.

Dominik

Re: [PATCH] pcmcia: pcmcia_resource: Replace mdelay() with msleep()

[Dominik Brodowski]

On Mon, Jul 30, 2018 at 09:42:56PM +0800, Jia-Ju Bai wrote:
> pcmcia_fixup_iowidth() and pcmcia_enable_device() are 
> never called in atomic context.
> They call mdelay() to busily wait, which is not necessary.
> mdelay() can be replaced with msleep().
> 
> This is found by a static analysis tool named DCNS written by myself.
> 
> Signed-off-by: Jia-Ju Bai 

Applied to pcmcia-next, thanks.

Dominik

Re: [PATCH] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges

[Dominik Brodowski]

On Sun, Sep 09, 2018 at 01:21:06AM +0200, Maciej S. Szmigiero wrote:
> Currently, "disable_clkrun" yenta_socket module parameter is only
> implemented for TI CardBus bridges.
> Add also an implementation for Ricoh bridges that have the necessary
> setting documented in publicly available datasheets.
> 
> Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
> correctly unless the CLKRUN protocol is disabled.
> 
> Let's also make it clear in its description that the "disable_clkrun"
> module parameter only works on these two previously mentioned brands of
> CardBus bridges.
> 
> Signed-off-by: Maciej S. Szmigiero 

Applied to pcmcia-next. Thanks!

Dominik

Re: [PATCH] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges

[Dominik Brodowski]

On Sun, Sep 09, 2018 at 01:21:06AM +0200, Maciej S. Szmigiero wrote:
> Currently, "disable_clkrun" yenta_socket module parameter is only
> implemented for TI CardBus bridges.
> Add also an implementation for Ricoh bridges that have the necessary
> setting documented in publicly available datasheets.
> 
> Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
> correctly unless the CLKRUN protocol is disabled.
> 
> Let's also make it clear in its description that the "disable_clkrun"
> module parameter only works on these two previously mentioned brands of
> CardBus bridges.
> 
> Signed-off-by: Maciej S. Szmigiero 

Applied to pcmcia-next. Thanks!

Dominik

[tip:x86/pti] x86/speculation: Simplify the CPU bug detection logic

[tip-bot for Dominik Brodowski]

Commit-ID:  8ecc4979b1bd9c94168e6fc92960033b7a951336
Gitweb: https://git.kernel.org/tip/8ecc4979b1bd9c94168e6fc92960033b7a951336
Author: Dominik Brodowski <li...@dominikbrodowski.net>
AuthorDate: Tue, 22 May 2018 11:05:39 +0200
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Wed, 23 May 2018 10:55:52 +0200

x86/speculation: Simplify the CPU bug detection logic

Only CPUs which speculate can speculate. Therefore, it seems prudent
to test for cpu_no_speculation first and only then determine whether
a specific speculating CPU is susceptible to store bypass speculation.
This is underlined by all CPUs currently listed in cpu_no_speculation
were present in cpu_no_spec_store_bypass as well.

Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: b...@suse.de
Cc: konrad.w...@oracle.com
Link: 
https://lkml.kernel.org/r/20180522090539.ga24...@light.dominikbrodowski.net

---
 arch/x86/kernel/cpu/common.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 78decc3e3067..38276f58d3bf 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -942,12 +942,8 @@ static const __initconst struct x86_cpu_id 
cpu_no_meltdown[] = {
{}
 };
 
+/* Only list CPUs which speculate but are non susceptible to SSB */
 static const __initconst struct x86_cpu_id cpu_no_spec_store_bypass[] = {
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PINEVIEW},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_LINCROFT},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PENWELL },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CLOVERVIEW  },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CEDARVIEW   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT1 },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_AIRMONT },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT2 },
@@ -955,14 +951,10 @@ static const __initconst struct x86_cpu_id 
cpu_no_spec_store_bypass[] = {
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_CORE_YONAH   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNL },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNM },
-   { X86_VENDOR_CENTAUR,   5,  },
-   { X86_VENDOR_INTEL, 5,  },
-   { X86_VENDOR_NSC,   5,  },
{ X86_VENDOR_AMD,   0x12,   },
{ X86_VENDOR_AMD,   0x11,   },
{ X86_VENDOR_AMD,   0x10,   },
{ X86_VENDOR_AMD,   0xf,},
-   { X86_VENDOR_ANY,   4,  },
{}
 };
 
@@ -970,6 +962,12 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 {
u64 ia32_cap = 0;
 
+   if (x86_match_cpu(cpu_no_speculation))
+   return;
+
+   setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
+   setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
+
if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
 
@@ -977,12 +975,6 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
   !(ia32_cap & ARCH_CAP_SSB_NO))
setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
 
-   if (x86_match_cpu(cpu_no_speculation))
-   return;
-
-   setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
-   setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
-
if (x86_match_cpu(cpu_no_meltdown))
return;
 

[tip:x86/pti] x86/speculation: Simplify the CPU bug detection logic

[tip-bot for Dominik Brodowski]

Commit-ID:  8ecc4979b1bd9c94168e6fc92960033b7a951336
Gitweb: https://git.kernel.org/tip/8ecc4979b1bd9c94168e6fc92960033b7a951336
Author: Dominik Brodowski 
AuthorDate: Tue, 22 May 2018 11:05:39 +0200
Committer:  Thomas Gleixner 
CommitDate: Wed, 23 May 2018 10:55:52 +0200

x86/speculation: Simplify the CPU bug detection logic

Only CPUs which speculate can speculate. Therefore, it seems prudent
to test for cpu_no_speculation first and only then determine whether
a specific speculating CPU is susceptible to store bypass speculation.
This is underlined by all CPUs currently listed in cpu_no_speculation
were present in cpu_no_spec_store_bypass as well.

Signed-off-by: Dominik Brodowski 
Signed-off-by: Thomas Gleixner 
Cc: b...@suse.de
Cc: konrad.w...@oracle.com
Link: 
https://lkml.kernel.org/r/20180522090539.ga24...@light.dominikbrodowski.net

---
 arch/x86/kernel/cpu/common.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 78decc3e3067..38276f58d3bf 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -942,12 +942,8 @@ static const __initconst struct x86_cpu_id 
cpu_no_meltdown[] = {
{}
 };
 
+/* Only list CPUs which speculate but are non susceptible to SSB */
 static const __initconst struct x86_cpu_id cpu_no_spec_store_bypass[] = {
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PINEVIEW},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_LINCROFT},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PENWELL },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CLOVERVIEW  },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CEDARVIEW   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT1 },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_AIRMONT },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT2 },
@@ -955,14 +951,10 @@ static const __initconst struct x86_cpu_id 
cpu_no_spec_store_bypass[] = {
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_CORE_YONAH   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNL },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNM },
-   { X86_VENDOR_CENTAUR,   5,  },
-   { X86_VENDOR_INTEL, 5,  },
-   { X86_VENDOR_NSC,   5,  },
{ X86_VENDOR_AMD,   0x12,   },
{ X86_VENDOR_AMD,   0x11,   },
{ X86_VENDOR_AMD,   0x10,   },
{ X86_VENDOR_AMD,   0xf,},
-   { X86_VENDOR_ANY,   4,  },
{}
 };
 
@@ -970,6 +962,12 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 {
u64 ia32_cap = 0;
 
+   if (x86_match_cpu(cpu_no_speculation))
+   return;
+
+   setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
+   setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
+
if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
 
@@ -977,12 +975,6 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
   !(ia32_cap & ARCH_CAP_SSB_NO))
setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
 
-   if (x86_match_cpu(cpu_no_speculation))
-   return;
-
-   setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
-   setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
-
if (x86_match_cpu(cpu_no_meltdown))
return;
 

Re: [PATCH 10/14] arm64: ssbd: Add prctl interface for per-thread mitigation

[Dominik Brodowski]

On Tue, May 22, 2018 at 04:06:44PM +0100, Marc Zyngier wrote:
> If running on a system that performs dynamic SSBD mitigation, allow
> userspace to request the mitigation for itself. This is implemented
> as a prctl call, allowing the mitigation to be enabled or disabled at
> will for this particular thread.
> 
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/kernel/Makefile |   1 +
>  arch/arm64/kernel/ssbd.c   | 107 
> +
>  2 files changed, 108 insertions(+)
>  create mode 100644 arch/arm64/kernel/ssbd.c
> 
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index bf825f38d206..0025f8691046 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -54,6 +54,7 @@ arm64-obj-$(CONFIG_ARM64_RELOC_TEST)+= 
> arm64-reloc-test.o
>  arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
>  arm64-obj-$(CONFIG_CRASH_DUMP)   += crash_dump.o
>  arm64-obj-$(CONFIG_ARM_SDE_INTERFACE)+= sdei.o
> +arm64-obj-$(CONFIG_ARM64_SSBD)   += ssbd.o
>  
>  obj-y+= $(arm64-obj-y) vdso/ probes/
>  obj-m+= $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/ssbd.c b/arch/arm64/kernel/ssbd.c
> new file mode 100644
> index ..34e3c430176b
> --- /dev/null
> +++ b/arch/arm64/kernel/ssbd.c
> @@ -0,0 +1,107 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 ARM Ltd, All Rights Reserved.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +/*
> + * prctl interface for SSBD
> + * FIXME: Drop the below ifdefery once the common interface has been merged.
> + */
> +#ifdef PR_SPEC_STORE_BYPASS

That FIXME wants to be looked at.

Thanks,
Dominik

Re: [PATCH 10/14] arm64: ssbd: Add prctl interface for per-thread mitigation

[Dominik Brodowski]

On Tue, May 22, 2018 at 04:06:44PM +0100, Marc Zyngier wrote:
> If running on a system that performs dynamic SSBD mitigation, allow
> userspace to request the mitigation for itself. This is implemented
> as a prctl call, allowing the mitigation to be enabled or disabled at
> will for this particular thread.
> 
> Signed-off-by: Marc Zyngier 
> ---
>  arch/arm64/kernel/Makefile |   1 +
>  arch/arm64/kernel/ssbd.c   | 107 
> +
>  2 files changed, 108 insertions(+)
>  create mode 100644 arch/arm64/kernel/ssbd.c
> 
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index bf825f38d206..0025f8691046 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -54,6 +54,7 @@ arm64-obj-$(CONFIG_ARM64_RELOC_TEST)+= 
> arm64-reloc-test.o
>  arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
>  arm64-obj-$(CONFIG_CRASH_DUMP)   += crash_dump.o
>  arm64-obj-$(CONFIG_ARM_SDE_INTERFACE)+= sdei.o
> +arm64-obj-$(CONFIG_ARM64_SSBD)   += ssbd.o
>  
>  obj-y+= $(arm64-obj-y) vdso/ probes/
>  obj-m+= $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/ssbd.c b/arch/arm64/kernel/ssbd.c
> new file mode 100644
> index ..34e3c430176b
> --- /dev/null
> +++ b/arch/arm64/kernel/ssbd.c
> @@ -0,0 +1,107 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 ARM Ltd, All Rights Reserved.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +/*
> + * prctl interface for SSBD
> + * FIXME: Drop the below ifdefery once the common interface has been merged.
> + */
> +#ifdef PR_SPEC_STORE_BYPASS

That FIXME wants to be looked at.

Thanks,
Dominik

[PATCH] x86/speculation: Simplify the CPU bug detection logic

[Dominik Brodowski]

Only CPUs which speculate can speculate. Therefore, it seems prudent
to test for cpu_no_speculation first and only then determine whether
a specific speculating CPU is susceptible to store bypass speculation.
This is underlined by all CPUs currently listed in cpu_no_speculation
were present in cpu_no_spec_store_bypass as well.

Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
---
 arch/x86/kernel/cpu/common.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 78decc3e3067..2fcc1fbf11b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -942,12 +942,8 @@ static const __initconst struct x86_cpu_id 
cpu_no_meltdown[] = {
{}
 };
 
+/* Only list CPUs which speculate but are non susceptible to SSB */
 static const __initconst struct x86_cpu_id cpu_no_spec_store_bypass[] = {
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PINEVIEW},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_LINCROFT},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PENWELL },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CLOVERVIEW  },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CEDARVIEW   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT1 },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_AIRMONT },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT2 },
@@ -955,14 +951,10 @@ static const __initconst struct x86_cpu_id 
cpu_no_spec_store_bypass[] = {
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_CORE_YONAH   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNL },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNM },
-   { X86_VENDOR_CENTAUR,   5,  },
-   { X86_VENDOR_INTEL, 5,  },
-   { X86_VENDOR_NSC,   5,  },
{ X86_VENDOR_AMD,   0x12,   },
{ X86_VENDOR_AMD,   0x11,   },
{ X86_VENDOR_AMD,   0x10,   },
{ X86_VENDOR_AMD,   0xf,},
-   { X86_VENDOR_ANY,   4,  },
{}
 };
 
@@ -973,16 +965,16 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
 
-   if (!x86_match_cpu(cpu_no_spec_store_bypass) &&
-  !(ia32_cap & ARCH_CAP_SSB_NO))
-   setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
-
if (x86_match_cpu(cpu_no_speculation))
return;
 
setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
 
+   if (!x86_match_cpu(cpu_no_spec_store_bypass) &&
+  !(ia32_cap & ARCH_CAP_SSB_NO))
+   setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
+
if (x86_match_cpu(cpu_no_meltdown))
return;
 
-- 
2.17.0

[PATCH] x86/speculation: Simplify the CPU bug detection logic

[Dominik Brodowski]

Only CPUs which speculate can speculate. Therefore, it seems prudent
to test for cpu_no_speculation first and only then determine whether
a specific speculating CPU is susceptible to store bypass speculation.
This is underlined by all CPUs currently listed in cpu_no_speculation
were present in cpu_no_spec_store_bypass as well.

Signed-off-by: Dominik Brodowski 
---
 arch/x86/kernel/cpu/common.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 78decc3e3067..2fcc1fbf11b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -942,12 +942,8 @@ static const __initconst struct x86_cpu_id 
cpu_no_meltdown[] = {
{}
 };
 
+/* Only list CPUs which speculate but are non susceptible to SSB */
 static const __initconst struct x86_cpu_id cpu_no_spec_store_bypass[] = {
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PINEVIEW},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_LINCROFT},
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_PENWELL },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CLOVERVIEW  },
-   { X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_CEDARVIEW   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT1 },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_AIRMONT },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_ATOM_SILVERMONT2 },
@@ -955,14 +951,10 @@ static const __initconst struct x86_cpu_id 
cpu_no_spec_store_bypass[] = {
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_CORE_YONAH   },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNL },
{ X86_VENDOR_INTEL, 6,  INTEL_FAM6_XEON_PHI_KNM },
-   { X86_VENDOR_CENTAUR,   5,  },
-   { X86_VENDOR_INTEL, 5,  },
-   { X86_VENDOR_NSC,   5,  },
{ X86_VENDOR_AMD,   0x12,   },
{ X86_VENDOR_AMD,   0x11,   },
{ X86_VENDOR_AMD,   0x10,   },
{ X86_VENDOR_AMD,   0xf,},
-   { X86_VENDOR_ANY,   4,  },
{}
 };
 
@@ -973,16 +965,16 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
 
-   if (!x86_match_cpu(cpu_no_spec_store_bypass) &&
-  !(ia32_cap & ARCH_CAP_SSB_NO))
-   setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
-
if (x86_match_cpu(cpu_no_speculation))
return;
 
setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
 
+   if (!x86_match_cpu(cpu_no_spec_store_bypass) &&
+  !(ia32_cap & ARCH_CAP_SSB_NO))
+   setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
+
if (x86_match_cpu(cpu_no_meltdown))
return;
 
-- 
2.17.0

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

[Dominik Brodowski]

On Tue, May 15, 2018 at 09:22:23AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:24:45PM +0200, Dominik Brodowski wrote:
> > On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> > > I agree it would be nicer if it had a wrapper that took a pt_regs, even
> > > if it does nothing with it.
> > > 
> > > We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> > > need a ksys_ni_syscall() for our traps.c logic, and adding this
> > > uniformly would involve some arch-specific rework for x86, too, so I
> > > decided it was not worth the effort.
> > 
> > Couldn't you just open-code the "return -ENOSYS;" in traps.c?
> 
> I guess so. I was just worried that debug logic might be added to the generic
> ni_syscall() in future, and wanted to avoid potential divergence.
> 
> > Error injection has no reasonable stable ABI/API expectations, so that's not
> > a show-stopper either.
> 
> If people are happy with using SYSCALL_DEFINE0() for ni_syscall, I'm happy to
> do that -- it's just that we'll need a fixup for x86 as that will change the
> symbol name.

For me, it's less about using SYSCALL_DEFINE0() for ni_syscall, but more
about keeping the syscall invokation easy. Therefore, we do pass a pointer
struct pt_regs to sys_ni_syscall() on x86, even though it does not expect
it.

/* this is a lie, but it does not hurt as sys_ni_syscall just returns 
-EINVAL */
extern asmlinkage long sys_ni_syscall(const struct pt_regs *);

Thanks,
Dominik

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

[Dominik Brodowski]

On Tue, May 15, 2018 at 09:22:23AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:24:45PM +0200, Dominik Brodowski wrote:
> > On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> > > I agree it would be nicer if it had a wrapper that took a pt_regs, even
> > > if it does nothing with it.
> > > 
> > > We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> > > need a ksys_ni_syscall() for our traps.c logic, and adding this
> > > uniformly would involve some arch-specific rework for x86, too, so I
> > > decided it was not worth the effort.
> > 
> > Couldn't you just open-code the "return -ENOSYS;" in traps.c?
> 
> I guess so. I was just worried that debug logic might be added to the generic
> ni_syscall() in future, and wanted to avoid potential divergence.
> 
> > Error injection has no reasonable stable ABI/API expectations, so that's not
> > a show-stopper either.
> 
> If people are happy with using SYSCALL_DEFINE0() for ni_syscall, I'm happy to
> do that -- it's just that we'll need a fixup for x86 as that will change the
> symbol name.

For me, it's less about using SYSCALL_DEFINE0() for ni_syscall, but more
about keeping the syscall invokation easy. Therefore, we do pass a pointer
struct pt_regs to sys_ni_syscall() on x86, even though it does not expect
it.

/* this is a lie, but it does not hurt as sys_ni_syscall just returns 
-EINVAL */
extern asmlinkage long sys_ni_syscall(const struct pt_regs *);

Thanks,
Dominik

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

[Dominik Brodowski]

On Tue, May 15, 2018 at 10:53:51AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:34:14PM +0200, Dominik Brodowski wrote:
> > On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote:
> > > On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> > > > +#ifdef CONFIG_COMPAT
> > > > +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t 
> > > > sz,
> > > > +struct compat_statfs64 __user * buf);
> > > > +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> > > > + struct compat_statfs64 __user * buf);
> > > > +#endif
> > > 
> > > I've moved these to , so that they live with the rest of
> > > the compat syscall stuff. That should avoid build failures the kbuild
> > > test robot picked up where compat_size_t wasn't dfined.
> > 
> > Please add a comment there, similar to what is in syscalls.h:
> > 
> > /*
> >  * Kernel code should not call syscalls (i.e., sys_xyzyyz()) directly.
> >  * Instead, use one of the functions which work equivalently, such as
> >  * the ksys_xyzyyz() functions prototyped below.
> >  */
> 
> To make the kcompat_sys_* naming scheme clearer, I've added compat references 
> to
> the above, i.e.
> 
> /*
>  * Kernel code should not call compat syscalls (i.e., compat_sys_xyzyyz())
>  * directly. Instead, use one of the functions which work equivalently, such
>  * as the kcompat_sys_xyzyyz() functions prototyped below.
>  */

That's what I meant ;)

> > Once you have done so, feel free to add my
> > 
> > Reviewed-by: Dominik Brodowski <li...@dominikbrodowski.net>
> 
> I hope that this still stands with the changes above?

It does. Thanks!

Dominik

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

[Dominik Brodowski]

On Tue, May 15, 2018 at 10:53:51AM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:34:14PM +0200, Dominik Brodowski wrote:
> > On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote:
> > > On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> > > > +#ifdef CONFIG_COMPAT
> > > > +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t 
> > > > sz,
> > > > +struct compat_statfs64 __user * buf);
> > > > +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> > > > + struct compat_statfs64 __user * buf);
> > > > +#endif
> > > 
> > > I've moved these to , so that they live with the rest of
> > > the compat syscall stuff. That should avoid build failures the kbuild
> > > test robot picked up where compat_size_t wasn't dfined.
> > 
> > Please add a comment there, similar to what is in syscalls.h:
> > 
> > /*
> >  * Kernel code should not call syscalls (i.e., sys_xyzyyz()) directly.
> >  * Instead, use one of the functions which work equivalently, such as
> >  * the ksys_xyzyyz() functions prototyped below.
> >  */
> 
> To make the kcompat_sys_* naming scheme clearer, I've added compat references 
> to
> the above, i.e.
> 
> /*
>  * Kernel code should not call compat syscalls (i.e., compat_sys_xyzyyz())
>  * directly. Instead, use one of the functions which work equivalently, such
>  * as the kcompat_sys_xyzyyz() functions prototyped below.
>  */

That's what I meant ;)

> > Once you have done so, feel free to add my
> > 
> > Reviewed-by: Dominik Brodowski 
> 
> I hope that this still stands with the changes above?

It does. Thanks!

Dominik

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

[Dominik Brodowski]

On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> I agree it would be nicer if it had a wrapper that took a pt_regs, even
> if it does nothing with it.
> 
> We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> need a ksys_ni_syscall() for our traps.c logic, and adding this
> uniformly would involve some arch-specific rework for x86, too, so I
> decided it was not worth the effort.

Couldn't you just open-code the "return -ENOSYS;" in traps.c? Error
injection has no reasonable stable ABI/API expectations, so that's not a
show-stopper either.

Thanks,
Dominik

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

[Dominik Brodowski]

On Mon, May 14, 2018 at 12:41:10PM +0100, Mark Rutland wrote:
> I agree it would be nicer if it had a wrapper that took a pt_regs, even
> if it does nothing with it.
> 
> We can't use SYSCALL_DEFINE0() due to the fault injection muck, we'd
> need a ksys_ni_syscall() for our traps.c logic, and adding this
> uniformly would involve some arch-specific rework for x86, too, so I
> decided it was not worth the effort.

Couldn't you just open-code the "return -ENOSYS;" in traps.c? Error
injection has no reasonable stable ABI/API expectations, so that's not a
show-stopper either.

Thanks,
Dominik

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

[Dominik Brodowski]

On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> > Using this helper allows us to avoid the in-kernel calls to the
> > compat_sys_{f,}statfs64() sycalls, as are necessary for parameter
> > mangling in arm64's compat handling.
> > 
> > Following the example of ksys_* functions, kcompat_sys_* functions are
> > intended to be a drop-in replacement for their compat_sys_*
> > counterparts, with the same calling convention.
> > 
> > This is necessary to enable conversion of arm64's syscall handling to
> > use pt_regs wrappers.
> 
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 6723ea51ec99..e0bf3e4bb897 100644
> > --- a/include/linux/syscalls.h
> > +++ b/include/linux/syscalls.h
> > @@ -59,6 +59,7 @@ struct tms;
> >  struct utimbuf;
> >  struct mq_attr;
> >  struct compat_stat;
> > +struct compat_statfs64;
> >  struct compat_timeval;
> >  struct robust_list_head;
> >  struct getcpu_cache;
> > @@ -1150,6 +1151,13 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, 
> > unsigned long len,
> >  ssize_t ksys_readahead(int fd, loff_t offset, size_t count);
> >  unsigned int ksys_personality(unsigned int personality);
> >  
> > +#ifdef CONFIG_COMPAT
> > +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz,
> > +struct compat_statfs64 __user * buf);
> > +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> > + struct compat_statfs64 __user * buf);
> > +#endif
> 
> I've moved these to , so that they live with the rest of
> the compat syscall stuff. That should avoid build failures the kbuild
> test robot picked up where compat_size_t wasn't dfined.

Please add a comment there, similar to what is in syscalls.h:

/*
 * Kernel code should not call syscalls (i.e., sys_xyzyyz()) directly.
 * Instead, use one of the functions which work equivalently, such as
 * the ksys_xyzyyz() functions prototyped below.
 */

Once you have done so, feel free to add my

Reviewed-by: Dominik Brodowski <li...@dominikbrodowski.net>

tag to this patch.

Thanks,
Dominik

Re: [PATCH 13/18] kernel: add kcompat_sys_{f,}statfs64()

[Dominik Brodowski]

On Mon, May 14, 2018 at 06:14:28PM +0100, Mark Rutland wrote:
> On Mon, May 14, 2018 at 10:46:35AM +0100, Mark Rutland wrote:
> > Using this helper allows us to avoid the in-kernel calls to the
> > compat_sys_{f,}statfs64() sycalls, as are necessary for parameter
> > mangling in arm64's compat handling.
> > 
> > Following the example of ksys_* functions, kcompat_sys_* functions are
> > intended to be a drop-in replacement for their compat_sys_*
> > counterparts, with the same calling convention.
> > 
> > This is necessary to enable conversion of arm64's syscall handling to
> > use pt_regs wrappers.
> 
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 6723ea51ec99..e0bf3e4bb897 100644
> > --- a/include/linux/syscalls.h
> > +++ b/include/linux/syscalls.h
> > @@ -59,6 +59,7 @@ struct tms;
> >  struct utimbuf;
> >  struct mq_attr;
> >  struct compat_stat;
> > +struct compat_statfs64;
> >  struct compat_timeval;
> >  struct robust_list_head;
> >  struct getcpu_cache;
> > @@ -1150,6 +1151,13 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, 
> > unsigned long len,
> >  ssize_t ksys_readahead(int fd, loff_t offset, size_t count);
> >  unsigned int ksys_personality(unsigned int personality);
> >  
> > +#ifdef CONFIG_COMPAT
> > +int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz,
> > +struct compat_statfs64 __user * buf);
> > +int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
> > + struct compat_statfs64 __user * buf);
> > +#endif
> 
> I've moved these to , so that they live with the rest of
> the compat syscall stuff. That should avoid build failures the kbuild
> test robot picked up where compat_size_t wasn't dfined.

Please add a comment there, similar to what is in syscalls.h:

/*
 * Kernel code should not call syscalls (i.e., sys_xyzyyz()) directly.
 * Instead, use one of the functions which work equivalently, such as
 * the ksys_xyzyyz() functions prototyped below.
 */

Once you have done so, feel free to add my

Reviewed-by: Dominik Brodowski 

tag to this patch.

Thanks,
Dominik

Re: [PATCH 18/18] arm64: implement syscall wrappers

[Dominik Brodowski]

On Mon, May 14, 2018 at 10:46:40AM +0100, Mark Rutland wrote:
> Note that we play games with sys_ni_syscall(). It can't be defined with
> SYSCALL_DEFINE0() because we must avoid the possibility of error
> injection. Additionally, there are a couple of locations where we need
> to call it from C code, and we don't (currently) have a
> ksys_ni_syscall().  While it has no wrapper, passing in a redundant
> pt_regs pointer is benign per the AAPCS.
> 
> When ARCH_HAS_SYSCALL_WRAPPER is selected, no prototype is define for
> sys_ni_syscall(). Since we need to treat it differently for in-kernel
> calls and the syscall tables, the prototype is defined as-required.

> Largely the wrappers are largely the same as their x86 counterparts, but

That's one "Largely" too much.

> simplified as we don't have a variety of compat calling conventions that
> require separate stubs. Unlike x86, we have some zero-argument compat
> syscalls, and must define COMPAT_SYSCALL_DEFINE0().

... for consistent naming, or is there another reason for that?

This patch looks good in any case.

Thanks,
Dominik

Re: [PATCH 18/18] arm64: implement syscall wrappers

[Dominik Brodowski]

On Mon, May 14, 2018 at 10:46:40AM +0100, Mark Rutland wrote:
> Note that we play games with sys_ni_syscall(). It can't be defined with
> SYSCALL_DEFINE0() because we must avoid the possibility of error
> injection. Additionally, there are a couple of locations where we need
> to call it from C code, and we don't (currently) have a
> ksys_ni_syscall().  While it has no wrapper, passing in a redundant
> pt_regs pointer is benign per the AAPCS.
> 
> When ARCH_HAS_SYSCALL_WRAPPER is selected, no prototype is define for
> sys_ni_syscall(). Since we need to treat it differently for in-kernel
> calls and the syscall tables, the prototype is defined as-required.

> Largely the wrappers are largely the same as their x86 counterparts, but

That's one "Largely" too much.

> simplified as we don't have a variety of compat calling conventions that
> require separate stubs. Unlike x86, we have some zero-argument compat
> syscalls, and must define COMPAT_SYSCALL_DEFINE0().

... for consistent naming, or is there another reason for that?

This patch looks good in any case.

Thanks,
Dominik

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

[Dominik Brodowski]

> +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
> +{
> + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1],
> +regs->regs[2], regs->regs[3],
> +regs->regs[4], regs->regs[5]);
> +}

Any specific reason to have this in a separate function? This seems to be
called only from one instance, namely

> +asmlinkage void invoke_syscall(struct pt_regs *regs, int scno, int sc_nr,
> +syscall_fn_t syscall_table[])
> +{
> + if (scno < sc_nr) {
> + syscall_fn_t syscall_fn;
> + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> + __invoke_syscall(regs, syscall_fn);
> + } else {
> + regs->regs[0] = do_ni_syscall(regs);
> + }
> +}

and result in a one-liner in the last patch of the series.

Thanks,
Dominik

Re: [PATCH 08/18] arm64: convert raw syscall invocation to C

[Dominik Brodowski]

> +static void __invoke_syscall(struct pt_regs *regs, syscall_fn_t syscall_fn)
> +{
> + regs->regs[0] = syscall_fn(regs->regs[0], regs->regs[1],
> +regs->regs[2], regs->regs[3],
> +regs->regs[4], regs->regs[5]);
> +}

Any specific reason to have this in a separate function? This seems to be
called only from one instance, namely

> +asmlinkage void invoke_syscall(struct pt_regs *regs, int scno, int sc_nr,
> +syscall_fn_t syscall_table[])
> +{
> + if (scno < sc_nr) {
> + syscall_fn_t syscall_fn;
> + syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> + __invoke_syscall(regs, syscall_fn);
> + } else {
> + regs->regs[0] = do_ni_syscall(regs);
> + }
> +}

and result in a one-liner in the last patch of the series.

Thanks,
Dominik

[PATCH] perf: update to new syscall stub naming convention

[Dominik Brodowski]

For v4.17-rc1, the naming of syscall stubs changed. Update the
perf scripts/utils/tests which need to be aware of the syscall
stub naming accordingly.

Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 53d83d7e6a09..9a970e334cea 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -32,10 +32,10 @@ int arch__choose_best_symbol(struct symbol *syma,
if (*sym == '.')
sym++;
 
-   /* Avoid "SyS" kernel syscall aliases */
-   if (strlen(sym) >= 3 && !strncmp(sym, "SyS", 3))
+   /* Avoid "__se_sys" kernel syscall aliases */
+   if (strlen(sym) >= 8 && !strncmp(sym,  "__se_sys", 8))
return SYMBOL_B;
-   if (strlen(sym) >= 10 && !strncmp(sym, "compat_SyS", 10))
+   if (strlen(sym) >= 15 && !strncmp(sym, "__se_compat_sys", 15))
return SYMBOL_B;
 
return SYMBOL_A;
diff --git a/tools/perf/tests/bpf-script-example.c 
b/tools/perf/tests/bpf-script-example.c
index e4123c1b0e88..5839baa3d766 100644
--- a/tools/perf/tests/bpf-script-example.c
+++ b/tools/perf/tests/bpf-script-example.c
@@ -31,8 +31,8 @@ struct bpf_map_def SEC("maps") flip_table = {
.max_entries = 1,
 };
 
-SEC("func=SyS_epoll_pwait")
-int bpf_func__SyS_epoll_pwait(void *ctx)
+SEC("func=__se_sys_epoll_pwait")
+int bpf_funcse_sys_epoll_pwait(void *ctx)
 {
int ind =0;
int *flag = bpf_map_lookup_elem(_table, );
diff --git a/tools/perf/util/c++/clang-test.cpp 
b/tools/perf/util/c++/clang-test.cpp
index 7b042a5ebc68..67a39ac8626d 100644
--- a/tools/perf/util/c++/clang-test.cpp
+++ b/tools/perf/util/c++/clang-test.cpp
@@ -41,7 +41,7 @@ int test__clang_to_IR(void)
if (!M)
return -1;
for (llvm::Function& F : *M)
-   if (F.getName() == "bpf_func__SyS_epoll_pwait")
+   if (F.getName() == "bpf_funcse_sys_epoll_pwait")
return 0;
return -1;
 }
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 62b2dd2253eb..32e156992dfc 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -113,10 +113,11 @@ int __weak arch__compare_symbol_names_n(const char 
*namea, const char *nameb,
 int __weak arch__choose_best_symbol(struct symbol *syma,
struct symbol *symb __maybe_unused)
 {
-   /* Avoid "SyS" kernel syscall aliases */
-   if (strlen(syma->name) >= 3 && !strncmp(syma->name, "SyS", 3))
+   /* Avoid "__se_sys" kernel syscall aliases */
+   if (strlen(syma->name) >= 8 && !strncmp(syma->name,  "__se_sys", 8))
return SYMBOL_B;
-   if (strlen(syma->name) >= 10 && !strncmp(syma->name, "compat_SyS", 10))
+   if (strlen(syma->name) >= 15 &&
+   !strncmp(syma->name, "__se_compat_sys", 15))
return SYMBOL_B;
 
return SYMBOL_A;

[PATCH] Documentation: updates for new syscall stub naming convention

[Dominik Brodowski]

For v4.17-rc1, the naming of syscall stubs changed. Update stack
traces and similar instances in the documentation to avoid sources
for confusion.

Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>

diff --git a/Documentation/admin-guide/bug-hunting.rst 
b/Documentation/admin-guide/bug-hunting.rst
index f278b289e260..cebff8e5c59f 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -30,7 +30,7 @@ Kernel bug reports often come with a stack dump like the one 
below::
 [] ? driver_detach+0x87/0x90
 [] ? bus_remove_driver+0x38/0x90
 [] ? usb_deregister+0x58/0xb0
-[] ? SyS_delete_module+0x130/0x1f0
+[] ? __se_sys_delete_module+0x130/0x1f0
 [] ? task_work_run+0x64/0x80
 [] ? exit_to_usermode_loop+0x85/0x90
 [] ? do_fast_syscall_32+0x80/0x130
diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index f7a18f274357..0fe231401ae9 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -60,7 +60,7 @@ A typical out of bounds access report looks like this::
  init_module+0x9/0x47 [test_kasan]
  do_one_initcall+0x99/0x200
  load_module+0x2cb3/0x3b20
- SyS_finit_module+0x76/0x80
+ __se_sys_finit_module+0x76/0x80
  system_call_fastpath+0x12/0x17
 INFO: Slab 0xea0001a4ef00 objects=17 used=7 fp=0x8800693bd728 
flags=0x1004080
 INFO: Object 0x8800693bc558 @offset=1368 fp=0x8800693bc720
@@ -101,7 +101,7 @@ A typical out of bounds access report looks like this::
  [] ? __vunmap+0xec/0x160
  [] load_module+0x2cb3/0x3b20
  [] ? m_show+0x240/0x240
- [] SyS_finit_module+0x76/0x80
+ [] __se_sys_finit_module+0x76/0x80
  [] system_call_fastpath+0x12/0x17
 Memory state around the buggy address:
  8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst
index c2f6452e38ed..df3f4016137a 100644
--- a/Documentation/dev-tools/kcov.rst
+++ b/Documentation/dev-tools/kcov.rst
@@ -103,7 +103,7 @@ program using kcov:
 
 After piping through addr2line output of the program looks as follows::
 
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 __fdget_pos
 fs/file.c:774
@@ -115,7 +115,7 @@ After piping through addr2line output of the program looks 
as follows::
 fs/file.c:760
 __fdget_pos
 fs/file.c:784
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 
 If a program needs to collect coverage from several threads (independently),
diff --git a/Documentation/locking/lockstat.txt 
b/Documentation/locking/lockstat.txt
index 5786ad2cd5e6..346a67e72671 100644
--- a/Documentation/locking/lockstat.txt
+++ b/Documentation/locking/lockstat.txt
@@ -96,7 +96,7 @@ Look at the current lock statistics:
 12   >mmap_sem 17  
[] vm_munmap+0x41/0x80
 13 ---
 14   >mmap_sem  1  
[] dup_mmap+0x2a/0x3f0
-15   >mmap_sem 60  
[] SyS_mprotect+0xe9/0x250
+15   >mmap_sem 60  
[] __se_sys_mprotect+0xe9/0x250
 16   >mmap_sem 41  
[] __do_page_fault+0x1d4/0x510
 17   >mmap_sem 68  
[] vm_mmap_pgoff+0x87/0xd0
 18
diff --git a/Documentation/trace/histogram.txt 
b/Documentation/trace/histogram.txt
index 6e05510afc28..f36784deae99 100644
--- a/Documentation/trace/histogram.txt
+++ b/Documentation/trace/histogram.txt
@@ -598,7 +598,7 @@
  apparmor_cred_prepare+0x1f/0x50
  security_prepare_creds+0x16/0x20
  prepare_creds+0xdf/0x1a0
- SyS_capset+0xb5/0x200
+ __se_sys_capset+0xb5/0x200
  system_call_fastpath+0x12/0x6a
 } hitcount:  1  bytes_req: 32  bytes_alloc: 32
 .
@@ -609,7 +609,7 @@
  i915_gem_execbuffer2+0x6c/0x2c0 [i915]
  drm_ioctl+0x349/0x670 [drm]
  do_vfs_ioctl+0x2f0/0x4f0
- SyS_ioctl+0x81/0xa0
+ __se_sys_ioctl+0x81/0xa0
  system_call_fastpath+0x12/0x6a
 } hitcount:  17726  bytes_req:   13944120  bytes_alloc:   19593808
 { stacktrace:
@@ -618,7 +618,7 @@
  load_elf_binary+0x102/0x1650
  search_binary_handler+0x97/0x1d0
  do_execveat_common.isra.34+0x551/0x6e0
- SyS_execve+0x3a/0x50
+ __se_sys_execve+0x3a/0x50
  return_from_execve+0x0/0x23
 } hitcount:  33348  bytes_req:   17152128  bytes_alloc:   20226048
 { stacktrace:
@@ -629,7 +629,7 @@
  path_openat+0x31/0x5f0
  do_filp_open+0x3a/0x90
  do_sys_open+0x128/0x220
- SyS_open+0x1e/0x20
+ __se_sys_open+0x1e/0x20
  system_call_fastpath+0x12/0x6a
 } hitcoun

[PATCH] Documentation: updates for new syscall stub naming convention

[Dominik Brodowski]

For v4.17-rc1, the naming of syscall stubs changed. Update stack
traces and similar instances in the documentation to avoid sources
for confusion.

Signed-off-by: Dominik Brodowski 

diff --git a/Documentation/admin-guide/bug-hunting.rst 
b/Documentation/admin-guide/bug-hunting.rst
index f278b289e260..cebff8e5c59f 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -30,7 +30,7 @@ Kernel bug reports often come with a stack dump like the one 
below::
 [] ? driver_detach+0x87/0x90
 [] ? bus_remove_driver+0x38/0x90
 [] ? usb_deregister+0x58/0xb0
-[] ? SyS_delete_module+0x130/0x1f0
+[] ? __se_sys_delete_module+0x130/0x1f0
 [] ? task_work_run+0x64/0x80
 [] ? exit_to_usermode_loop+0x85/0x90
 [] ? do_fast_syscall_32+0x80/0x130
diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index f7a18f274357..0fe231401ae9 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -60,7 +60,7 @@ A typical out of bounds access report looks like this::
  init_module+0x9/0x47 [test_kasan]
  do_one_initcall+0x99/0x200
  load_module+0x2cb3/0x3b20
- SyS_finit_module+0x76/0x80
+ __se_sys_finit_module+0x76/0x80
  system_call_fastpath+0x12/0x17
 INFO: Slab 0xea0001a4ef00 objects=17 used=7 fp=0x8800693bd728 
flags=0x1004080
 INFO: Object 0x8800693bc558 @offset=1368 fp=0x8800693bc720
@@ -101,7 +101,7 @@ A typical out of bounds access report looks like this::
  [] ? __vunmap+0xec/0x160
  [] load_module+0x2cb3/0x3b20
  [] ? m_show+0x240/0x240
- [] SyS_finit_module+0x76/0x80
+ [] __se_sys_finit_module+0x76/0x80
  [] system_call_fastpath+0x12/0x17
 Memory state around the buggy address:
  8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst
index c2f6452e38ed..df3f4016137a 100644
--- a/Documentation/dev-tools/kcov.rst
+++ b/Documentation/dev-tools/kcov.rst
@@ -103,7 +103,7 @@ program using kcov:
 
 After piping through addr2line output of the program looks as follows::
 
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 __fdget_pos
 fs/file.c:774
@@ -115,7 +115,7 @@ After piping through addr2line output of the program looks 
as follows::
 fs/file.c:760
 __fdget_pos
 fs/file.c:784
-SyS_read
+__se_sys_read
 fs/read_write.c:562
 
 If a program needs to collect coverage from several threads (independently),
diff --git a/Documentation/locking/lockstat.txt 
b/Documentation/locking/lockstat.txt
index 5786ad2cd5e6..346a67e72671 100644
--- a/Documentation/locking/lockstat.txt
+++ b/Documentation/locking/lockstat.txt
@@ -96,7 +96,7 @@ Look at the current lock statistics:
 12   >mmap_sem 17  
[] vm_munmap+0x41/0x80
 13 ---
 14   >mmap_sem  1  
[] dup_mmap+0x2a/0x3f0
-15   >mmap_sem 60  
[] SyS_mprotect+0xe9/0x250
+15   >mmap_sem 60  
[] __se_sys_mprotect+0xe9/0x250
 16   >mmap_sem 41  
[] __do_page_fault+0x1d4/0x510
 17   >mmap_sem 68  
[] vm_mmap_pgoff+0x87/0xd0
 18
diff --git a/Documentation/trace/histogram.txt 
b/Documentation/trace/histogram.txt
index 6e05510afc28..f36784deae99 100644
--- a/Documentation/trace/histogram.txt
+++ b/Documentation/trace/histogram.txt
@@ -598,7 +598,7 @@
  apparmor_cred_prepare+0x1f/0x50
  security_prepare_creds+0x16/0x20
  prepare_creds+0xdf/0x1a0
- SyS_capset+0xb5/0x200
+ __se_sys_capset+0xb5/0x200
  system_call_fastpath+0x12/0x6a
 } hitcount:  1  bytes_req: 32  bytes_alloc: 32
 .
@@ -609,7 +609,7 @@
  i915_gem_execbuffer2+0x6c/0x2c0 [i915]
  drm_ioctl+0x349/0x670 [drm]
  do_vfs_ioctl+0x2f0/0x4f0
- SyS_ioctl+0x81/0xa0
+ __se_sys_ioctl+0x81/0xa0
  system_call_fastpath+0x12/0x6a
 } hitcount:  17726  bytes_req:   13944120  bytes_alloc:   19593808
 { stacktrace:
@@ -618,7 +618,7 @@
  load_elf_binary+0x102/0x1650
  search_binary_handler+0x97/0x1d0
  do_execveat_common.isra.34+0x551/0x6e0
- SyS_execve+0x3a/0x50
+ __se_sys_execve+0x3a/0x50
  return_from_execve+0x0/0x23
 } hitcount:  33348  bytes_req:   17152128  bytes_alloc:   20226048
 { stacktrace:
@@ -629,7 +629,7 @@
  path_openat+0x31/0x5f0
  do_filp_open+0x3a/0x90
  do_sys_open+0x128/0x220
- SyS_open+0x1e/0x20
+ __se_sys_open+0x1e/0x20
  system_call_fastpath+0x12/0x6a
 } hitcount:4766422  bytes_req:95

[PATCH] perf: update to new syscall stub naming convention

[Dominik Brodowski]

For v4.17-rc1, the naming of syscall stubs changed. Update the
perf scripts/utils/tests which need to be aware of the syscall
stub naming accordingly.

Signed-off-by: Dominik Brodowski 

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 53d83d7e6a09..9a970e334cea 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -32,10 +32,10 @@ int arch__choose_best_symbol(struct symbol *syma,
if (*sym == '.')
sym++;
 
-   /* Avoid "SyS" kernel syscall aliases */
-   if (strlen(sym) >= 3 && !strncmp(sym, "SyS", 3))
+   /* Avoid "__se_sys" kernel syscall aliases */
+   if (strlen(sym) >= 8 && !strncmp(sym,  "__se_sys", 8))
return SYMBOL_B;
-   if (strlen(sym) >= 10 && !strncmp(sym, "compat_SyS", 10))
+   if (strlen(sym) >= 15 && !strncmp(sym, "__se_compat_sys", 15))
return SYMBOL_B;
 
return SYMBOL_A;
diff --git a/tools/perf/tests/bpf-script-example.c 
b/tools/perf/tests/bpf-script-example.c
index e4123c1b0e88..5839baa3d766 100644
--- a/tools/perf/tests/bpf-script-example.c
+++ b/tools/perf/tests/bpf-script-example.c
@@ -31,8 +31,8 @@ struct bpf_map_def SEC("maps") flip_table = {
.max_entries = 1,
 };
 
-SEC("func=SyS_epoll_pwait")
-int bpf_func__SyS_epoll_pwait(void *ctx)
+SEC("func=__se_sys_epoll_pwait")
+int bpf_funcse_sys_epoll_pwait(void *ctx)
 {
int ind =0;
int *flag = bpf_map_lookup_elem(_table, );
diff --git a/tools/perf/util/c++/clang-test.cpp 
b/tools/perf/util/c++/clang-test.cpp
index 7b042a5ebc68..67a39ac8626d 100644
--- a/tools/perf/util/c++/clang-test.cpp
+++ b/tools/perf/util/c++/clang-test.cpp
@@ -41,7 +41,7 @@ int test__clang_to_IR(void)
if (!M)
return -1;
for (llvm::Function& F : *M)
-   if (F.getName() == "bpf_func__SyS_epoll_pwait")
+   if (F.getName() == "bpf_funcse_sys_epoll_pwait")
return 0;
return -1;
 }
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 62b2dd2253eb..32e156992dfc 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -113,10 +113,11 @@ int __weak arch__compare_symbol_names_n(const char 
*namea, const char *nameb,
 int __weak arch__choose_best_symbol(struct symbol *syma,
struct symbol *symb __maybe_unused)
 {
-   /* Avoid "SyS" kernel syscall aliases */
-   if (strlen(syma->name) >= 3 && !strncmp(syma->name, "SyS", 3))
+   /* Avoid "__se_sys" kernel syscall aliases */
+   if (strlen(syma->name) >= 8 && !strncmp(syma->name,  "__se_sys", 8))
return SYMBOL_B;
-   if (strlen(syma->name) >= 10 && !strncmp(syma->name, "compat_SyS", 10))
+   if (strlen(syma->name) >= 15 &&
+   !strncmp(syma->name, "__se_compat_sys", 15))
return SYMBOL_B;
 
return SYMBOL_A;

Re: [PATCH v3] tracing/x86: Update syscall trace events to handle new prefixed syscall func names

[Dominik Brodowski]

On Wed, Apr 18, 2018 at 11:45:09AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rost...@goodmis.org>
> 
> Arnaldo noticed that the latest kernel is missing the syscall event system
> directory in x86. I bisected it down to d5a00528b58c ("syscalls/core,
> syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()").
> 
> The system call trace events are special, as there is only one trace event
> for all system calls (the raw_syscalls). But a macro that wraps the system
> calls creates meta data for them that copies the name to find the system
> call that maps to the system call table (the number). At boot up, it does a
> kallsyms lookup of the system call table to find the function that maps to
> the meta data of the system call. If it does not find a function, then that
> system call is ignored.
> 
> Because the x86 system calls had "__x64_", or "__ia32_" prefixed to the
> "sys" for the names, they do not match the default compare algorithm. As
> this was a problem for power pc, the algorithm can be overwritten by the
> architecture. The solution is to have x86 have its own algorithm to do the
> compare and this brings back the system call trace events.
> 
> Link: http://lkml.kernel.org/r/20180417174128.0f345...@gandalf.local.home
> 
> Reported-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> Tested-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> Fixes: d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct 
> pt_regs-based sys_*() to __x64_sys_*()")
> Signed-off-by: Steven Rostedt (VMware) <rost...@goodmis.org>

Acked-by: Dominik Brodowski <li...@dominikbrodowski.net>

Re: [PATCH v3] tracing/x86: Update syscall trace events to handle new prefixed syscall func names

[Dominik Brodowski]

On Wed, Apr 18, 2018 at 11:45:09AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> Arnaldo noticed that the latest kernel is missing the syscall event system
> directory in x86. I bisected it down to d5a00528b58c ("syscalls/core,
> syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()").
> 
> The system call trace events are special, as there is only one trace event
> for all system calls (the raw_syscalls). But a macro that wraps the system
> calls creates meta data for them that copies the name to find the system
> call that maps to the system call table (the number). At boot up, it does a
> kallsyms lookup of the system call table to find the function that maps to
> the meta data of the system call. If it does not find a function, then that
> system call is ignored.
> 
> Because the x86 system calls had "__x64_", or "__ia32_" prefixed to the
> "sys" for the names, they do not match the default compare algorithm. As
> this was a problem for power pc, the algorithm can be overwritten by the
> architecture. The solution is to have x86 have its own algorithm to do the
> compare and this brings back the system call trace events.
> 
> Link: http://lkml.kernel.org/r/20180417174128.0f345...@gandalf.local.home
> 
> Reported-by: Arnaldo Carvalho de Melo 
> Tested-by: Arnaldo Carvalho de Melo 
> Fixes: d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct 
> pt_regs-based sys_*() to __x64_sys_*()")
> Signed-off-by: Steven Rostedt (VMware) 

Acked-by: Dominik Brodowski 

Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Dominik Brodowski]

>   Added back original compare to not miss 32bit kernel syscalls

s/32bit/32bit and 0-parameter syscalls.

Looks good otherwise.

Thanks,
Dominik

Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Dominik Brodowski]

>   Added back original compare to not miss 32bit kernel syscalls

s/32bit/32bit and 0-parameter syscalls.

Looks good otherwise.

Thanks,
Dominik

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Dominik Brodowski]

On Tue, Apr 17, 2018 at 12:39:27PM -0400, Steven Rostedt wrote:
> > > names, they do not match the default compare algorithm. As this was a
> > > problem for power pc, the algorithm can be overwritten by the 
> > > architecture.
> > > The solution is to have x86 have its own algorithm to do the compare and
> > > this brings back the system call trace events.  
> > 
> > this lets me wonder *which* syscall "function" should be included in this
> > directory. Is it really the stub (__x64_sys_waitid, for example), or better
> > the sign-extending C function (__se_sys_waitid) which then calls an
> > internal helper (__do_sys_waitid). An additional advantage:
> > __se_sys_waitid would be available on x86 and, AFAICS, on all other archs.
> 
> It should include anything that uses the "SYSCALL_DEFINE#()" macros.

Well, that's not a 1:1, but a 1:several translation... SYSCALL_DEFINEx()
[SYSCALL_DEFINE0() is special] expands to

__do_sys_waitid # inlined helper doing actual work
__se_sys_waitid # C func calling inlined helper

on all architectures, with most (!= 64-bit x86) also having

 sys_waitid # alias to __se_sys_waitid()

On 64-bit x86, it does not only extend to the two functions mentioned above,
but also to one or two stubs (depending on the configuration), namely

  __x64_sys_waitid  # x64 64-bit-ptregs -> C stub
 __ia32_sys_waitid  # ia32 32-bit-ptregs -> C stub

Thanks,
Dominik

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Dominik Brodowski]

On Tue, Apr 17, 2018 at 12:39:27PM -0400, Steven Rostedt wrote:
> > > names, they do not match the default compare algorithm. As this was a
> > > problem for power pc, the algorithm can be overwritten by the 
> > > architecture.
> > > The solution is to have x86 have its own algorithm to do the compare and
> > > this brings back the system call trace events.  
> > 
> > this lets me wonder *which* syscall "function" should be included in this
> > directory. Is it really the stub (__x64_sys_waitid, for example), or better
> > the sign-extending C function (__se_sys_waitid) which then calls an
> > internal helper (__do_sys_waitid). An additional advantage:
> > __se_sys_waitid would be available on x86 and, AFAICS, on all other archs.
> 
> It should include anything that uses the "SYSCALL_DEFINE#()" macros.

Well, that's not a 1:1, but a 1:several translation... SYSCALL_DEFINEx()
[SYSCALL_DEFINE0() is special] expands to

__do_sys_waitid # inlined helper doing actual work
__se_sys_waitid # C func calling inlined helper

on all architectures, with most (!= 64-bit x86) also having

 sys_waitid # alias to __se_sys_waitid()

On 64-bit x86, it does not only extend to the two functions mentioned above,
but also to one or two stubs (depending on the configuration), namely

  __x64_sys_waitid  # x64 64-bit-ptregs -> C stub
 __ia32_sys_waitid  # ia32 32-bit-ptregs -> C stub

Thanks,
Dominik

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Dominik Brodowski]

Steven,

On Tue, Apr 17, 2018 at 11:54:40AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> Arnaldo noticed that the latest kernel is missing the syscall event system
> directory in x86. I bisected it down to d5a00528b58c ("syscalls/core,
> syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()").
> 
> The system call trace events are special, as there is only one trace event
> for all system calls (the raw_syscalls). But a macro that wraps the system
> calls creates meta data for them that copies the name to find the system
> call that maps to the system call table (the number). At boot up, it does a
> kallsyms lookup for this mapping. If it does not find a function, then that
> system call is ignored.
> 
> Because the x86 system calls had "__x86_" appended to the "sys" for the

__x64 actually.

> names, they do not match the default compare algorithm. As this was a
> problem for power pc, the algorithm can be overwritten by the architecture.
> The solution is to have x86 have its own algorithm to do the compare and
> this brings back the system call trace events.

this lets me wonder *which* syscall "function" should be included in this
directory. Is it really the stub (__x64_sys_waitid, for example), or better
the sign-extending C function (__se_sys_waitid) which then calls an
internal helper (__do_sys_waitid). An additional advantage:
__se_sys_waitid would be available on x86 and, AFAICS, on all other archs.

> Reported-by: Arnaldo Carvalho de Melo 
> Fixes: d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct 
> pt_regs-based sys_*() to __x64_sys_*()")
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  arch/x86/include/asm/ftrace.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index 09ad88572746..c30b3fac20ae 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
> @@ -31,6 +31,16 @@ static inline unsigned long ftrace_call_adjust(unsigned 
> long addr)
>   return addr;
>  }
>  
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +static inline bool arch_syscall_match_sym_name(const char *sym, const char 
> *name)
> +{
> + /*
> +  * Compare the symbol name with the system call name. Skip the
> +  * "__x64_sys" prefix.
> +  */
> + return !strcmp(sym + 9, name + 3);
> +}

What are the first three chars you skip for *name?

Thanks,
Dominik

Re: [PATCH] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Dominik Brodowski]

Steven,

On Tue, Apr 17, 2018 at 11:54:40AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> Arnaldo noticed that the latest kernel is missing the syscall event system
> directory in x86. I bisected it down to d5a00528b58c ("syscalls/core,
> syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()").
> 
> The system call trace events are special, as there is only one trace event
> for all system calls (the raw_syscalls). But a macro that wraps the system
> calls creates meta data for them that copies the name to find the system
> call that maps to the system call table (the number). At boot up, it does a
> kallsyms lookup for this mapping. If it does not find a function, then that
> system call is ignored.
> 
> Because the x86 system calls had "__x86_" appended to the "sys" for the

__x64 actually.

> names, they do not match the default compare algorithm. As this was a
> problem for power pc, the algorithm can be overwritten by the architecture.
> The solution is to have x86 have its own algorithm to do the compare and
> this brings back the system call trace events.

this lets me wonder *which* syscall "function" should be included in this
directory. Is it really the stub (__x64_sys_waitid, for example), or better
the sign-extending C function (__se_sys_waitid) which then calls an
internal helper (__do_sys_waitid). An additional advantage:
__se_sys_waitid would be available on x86 and, AFAICS, on all other archs.

> Reported-by: Arnaldo Carvalho de Melo 
> Fixes: d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct 
> pt_regs-based sys_*() to __x64_sys_*()")
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  arch/x86/include/asm/ftrace.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index 09ad88572746..c30b3fac20ae 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
> @@ -31,6 +31,16 @@ static inline unsigned long ftrace_call_adjust(unsigned 
> long addr)
>   return addr;
>  }
>  
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +static inline bool arch_syscall_match_sym_name(const char *sym, const char 
> *name)
> +{
> + /*
> +  * Compare the symbol name with the system call name. Skip the
> +  * "__x64_sys" prefix.
> +  */
> + return !strcmp(sym + 9, name + 3);
> +}

What are the first three chars you skip for *name?

Thanks,
Dominik

Re: Linux 4.17-rc1

[Dominik Brodowski]

On Mon, Apr 16, 2018 at 11:01:57AM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 16, 2018 at 3:55 AM, Linus Torvalds
>  wrote:
> > We actually have a fair amount of other removal and cleanups too. I
> > was somewhat pleasantly surprised by the number of pull requests that
> > actually ended up removing a lot of lines. Some of it was staging
> > drivers that finally gave up the ghost (like irda), but we also got
> > rid of some copyright language boiler-plate in favor of just the spdx
> > lines. And some pre-shipped lexer/parser files are no more, we're
> > better off just generating them.
> >
> > End result: we actually removed more lines than we added:
> >
> >  13538 files changed, 627723 insertions(+), 818855 deletions(-)
> >
> > which is probably a first. Ever. In the history of the universe. Or at
> > least kernel releases.
> >
> > I'd call it momentous, but I think the arch removal was most of it,
> > and I'm sure people will quickly rectify that momentary glitch of
> > actually shrinking the kernel source code.
> 
> For the first time ever(?), we also had a kernel size reduction, according
> to bloat-o-meter (for an m68k atari_defconfig kernel):
> 
> add/remove: 341/440 grow/shrink: 445/359 up/down: 60125/-133422 (-73297)
> 
> which brings us (size-wise) back to v4.13-and-a-half.
> This is mostly attributed to the removal of lots of SyS_* functions.

Please note that the SyS_* stubs were renamed to __se_sys_* () [__se for
sign-extending], which bloat-o-meter does not handle well.

Thanks,
Dominik

Re: Linux 4.17-rc1

[Dominik Brodowski]

On Mon, Apr 16, 2018 at 11:01:57AM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 16, 2018 at 3:55 AM, Linus Torvalds
>  wrote:
> > We actually have a fair amount of other removal and cleanups too. I
> > was somewhat pleasantly surprised by the number of pull requests that
> > actually ended up removing a lot of lines. Some of it was staging
> > drivers that finally gave up the ghost (like irda), but we also got
> > rid of some copyright language boiler-plate in favor of just the spdx
> > lines. And some pre-shipped lexer/parser files are no more, we're
> > better off just generating them.
> >
> > End result: we actually removed more lines than we added:
> >
> >  13538 files changed, 627723 insertions(+), 818855 deletions(-)
> >
> > which is probably a first. Ever. In the history of the universe. Or at
> > least kernel releases.
> >
> > I'd call it momentous, but I think the arch removal was most of it,
> > and I'm sure people will quickly rectify that momentary glitch of
> > actually shrinking the kernel source code.
> 
> For the first time ever(?), we also had a kernel size reduction, according
> to bloat-o-meter (for an m68k atari_defconfig kernel):
> 
> add/remove: 341/440 grow/shrink: 445/359 up/down: 60125/-133422 (-73297)
> 
> which brings us (size-wise) back to v4.13-and-a-half.
> This is mostly attributed to the removal of lots of SyS_* functions.

Please note that the SyS_* stubs were renamed to __se_sys_* () [__se for
sign-extending], which bloat-o-meter does not handle well.

Thanks,
Dominik

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up syscall stub naming convention

[tip-bot for Dominik Brodowski]

Commit-ID:  e145242ea0df6b7d28fd7186e61d6840fa4bb06e
Gitweb: https://git.kernel.org/tip/e145242ea0df6b7d28fd7186e61d6840fa4bb06e
Author: Dominik Brodowski <li...@dominikbrodowski.net>
AuthorDate: Mon, 9 Apr 2018 12:51:42 +0200
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Mon, 9 Apr 2018 16:47:27 +0200

syscalls/core, syscalls/x86: Clean up syscall stub naming convention

Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the SYSCALL_DEFINEx() macro.

For the generic case, this means (0x prefix removed):

 810f08d0 t kernel_waitid   # common C function (see kernel/exit.c)

  __do_sys_waitid   # inlined helper doing the actual work
# (takes original parameters as declared)

 810f1aa0 T   __se_sys_waitid   # sign-extending C function calling inlined
# helper (takes parameters of type long;
# casts them to the declared type)

 810f1aa0 Tsys_waitid   # alias to __se_sys_waitid() (taking
# parameters as declared), to be included
# in syscall table

For x86, the naming is as follows:

 810efc70 t kernel_waitid   # common C function (see kernel/exit.c)

  __do_sys_waitid   # inlined helper doing the actual work
# (takes original parameters as declared)

 810efd60 t   __se_sys_waitid   # sign-extending C function calling inlined
# helper (takes parameters of type long;
# casts them to the declared type)

 810f1140 T __ia32_sys_waitid   # IA32_EMULATION 32-bit-ptregs -> C stub,
# calls __se_sys_waitid(); to be included
# in syscall table

 810f1110 Tsys_waitid   # x86 64-bit-ptregs -> C stub, calls
# __se_sys_waitid(); to be included in
# syscall table

For x86, sys_waitid() will be re-named to __x64_sys_waitid in a follow-up
patch.

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: http://lkml.kernel.org/r/20180409105145.5364-2-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/entry/syscalls/syscall_32.tbl | 424 -
 arch/x86/include/asm/syscall_wrapper.h |  35 +--
 include/linux/syscalls.h   |  17 +-
 scripts/bloat-o-meter  |   2 +-
 4 files changed, 242 insertions(+), 236 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 7f09a3da0b3d..539df8f6d0e1 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -4,7 +4,7 @@
 # The format is:
 # 
 #
-# The __sys_ia32 and __compat_sys_ia32 stubs are created on-the-fly for
+# The __ia32_sys and __compat_sys_ia32 stubs are created on-the-fly for
 # sys_*() system calls and compat_sys_*() compat system calls if
 # IA32_EMULATION is defined, and expect struct pt_regs *regs as their only
 # parameter.
@@ -12,284 +12,284 @@
 # The abi is always "i386" for this file.
 #
 0  i386restart_syscall sys_restart_syscall
-1  i386exitsys_exit
__sys_ia32_exit
+1  i386exitsys_exit
__ia32_sys_exit
 2  i386forksys_fork
-3  i386readsys_read
__sys_ia32_read
-4  i386write   sys_write   
__sys_ia32_write
+3  i386readsys_read
__ia32_sys_read
+4  i386write   sys_write   
__ia32_sys_write
 5  i386opensys_open
__compat_sys_ia32_open
-6  i386close   sys_close   
__sys_ia32_close
-7  i386waitpid sys_waitpid 
__sys_ia32_waitpid
-8  i386creat   sys_creat   
__sys_ia32_creat
-9  i386linksys_link
__s

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up syscall stub naming convention

[tip-bot for Dominik Brodowski]

Commit-ID:  e145242ea0df6b7d28fd7186e61d6840fa4bb06e
Gitweb: https://git.kernel.org/tip/e145242ea0df6b7d28fd7186e61d6840fa4bb06e
Author: Dominik Brodowski 
AuthorDate: Mon, 9 Apr 2018 12:51:42 +0200
Committer:  Ingo Molnar 
CommitDate: Mon, 9 Apr 2018 16:47:27 +0200

syscalls/core, syscalls/x86: Clean up syscall stub naming convention

Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the SYSCALL_DEFINEx() macro.

For the generic case, this means (0x prefix removed):

 810f08d0 t kernel_waitid   # common C function (see kernel/exit.c)

  __do_sys_waitid   # inlined helper doing the actual work
# (takes original parameters as declared)

 810f1aa0 T   __se_sys_waitid   # sign-extending C function calling inlined
# helper (takes parameters of type long;
# casts them to the declared type)

 810f1aa0 Tsys_waitid   # alias to __se_sys_waitid() (taking
# parameters as declared), to be included
# in syscall table

For x86, the naming is as follows:

 810efc70 t kernel_waitid   # common C function (see kernel/exit.c)

  __do_sys_waitid   # inlined helper doing the actual work
# (takes original parameters as declared)

 810efd60 t   __se_sys_waitid   # sign-extending C function calling inlined
# helper (takes parameters of type long;
# casts them to the declared type)

 810f1140 T __ia32_sys_waitid   # IA32_EMULATION 32-bit-ptregs -> C stub,
# calls __se_sys_waitid(); to be included
# in syscall table

 810f1110 Tsys_waitid   # x86 64-bit-ptregs -> C stub, calls
# __se_sys_waitid(); to be included in
# syscall table

For x86, sys_waitid() will be re-named to __x64_sys_waitid in a follow-up
patch.

Suggested-by: Ingo Molnar 
Signed-off-by: Dominik Brodowski 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180409105145.5364-2-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/syscalls/syscall_32.tbl | 424 -
 arch/x86/include/asm/syscall_wrapper.h |  35 +--
 include/linux/syscalls.h   |  17 +-
 scripts/bloat-o-meter  |   2 +-
 4 files changed, 242 insertions(+), 236 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 7f09a3da0b3d..539df8f6d0e1 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -4,7 +4,7 @@
 # The format is:
 # 
 #
-# The __sys_ia32 and __compat_sys_ia32 stubs are created on-the-fly for
+# The __ia32_sys and __compat_sys_ia32 stubs are created on-the-fly for
 # sys_*() system calls and compat_sys_*() compat system calls if
 # IA32_EMULATION is defined, and expect struct pt_regs *regs as their only
 # parameter.
@@ -12,284 +12,284 @@
 # The abi is always "i386" for this file.
 #
 0  i386restart_syscall sys_restart_syscall
-1  i386exitsys_exit
__sys_ia32_exit
+1  i386exitsys_exit
__ia32_sys_exit
 2  i386forksys_fork
-3  i386readsys_read
__sys_ia32_read
-4  i386write   sys_write   
__sys_ia32_write
+3  i386readsys_read
__ia32_sys_read
+4  i386write   sys_write   
__ia32_sys_write
 5  i386opensys_open
__compat_sys_ia32_open
-6  i386close   sys_close   
__sys_ia32_close
-7  i386waitpid sys_waitpid 
__sys_ia32_waitpid
-8  i386creat   sys_creat   
__sys_ia32_creat
-9  i386linksys_link
__sys_ia32_link
-10 i386unlink  sys_unlink  
__sys_ia32_unlink
+6  i386close   sys_close   
__ia32_sys_close
+7  i386waitpid sys_waitpid 
__ia32_sys_waitpid
+8  i386creat   sys_creat   
__ia32_sys_creat
+9  i386link

[tip:x86/asm] syscalls/x86: Adapt syscall_wrapper.h to the new syscall stub naming convention

[tip-bot for Dominik Brodowski]

Commit-ID:  c76fc98260751e71c884dc1a18a07e427ef033b5
Gitweb: https://git.kernel.org/tip/c76fc98260751e71c884dc1a18a07e427ef033b5
Author: Dominik Brodowski <li...@dominikbrodowski.net>
AuthorDate: Mon, 9 Apr 2018 12:51:45 +0200
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Mon, 9 Apr 2018 16:47:28 +0200

syscalls/x86: Adapt syscall_wrapper.h to the new syscall stub naming convention

Make the code in syscall_wrapper.h more readable by naming the stub macros
similar to the stub they provide. While at it, fix a stray newline at the
end of the __IA32_COMPAT_SYS_STUBx macro.

Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: http://lkml.kernel.org/r/20180409105145.5364-5-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/include/asm/syscall_wrapper.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/syscall_wrapper.h 
b/arch/x86/include/asm/syscall_wrapper.h
index a598013e08e9..e046a405743d 100644
--- a/arch/x86/include/asm/syscall_wrapper.h
+++ b/arch/x86/include/asm/syscall_wrapper.h
@@ -28,7 +28,7 @@
  * kernel/sys_ni.c and SYS_NI in kernel/time/posix-stubs.c to cover this
  * case as well.
  */
-#define COMPAT_SC_IA32_STUBx(x, name, ...) \
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__ia32_compat_sys##name, ERRNO);  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs)\
@@ -36,7 +36,7 @@
return 
__se_compat_sys##name(SC_IA32_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
 
-#define SC_IA32_WRAPPERx(x, name, ...) \
+#define __IA32_SYS_STUBx(x, name, ...) \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs);   \
ALLOW_ERROR_INJECTION(__ia32_sys##name, ERRNO); \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs)\
@@ -64,8 +64,8 @@
SYSCALL_ALIAS(__ia32_sys_##name, sys_ni_posix_timers)
 
 #else /* CONFIG_IA32_EMULATION */
-#define COMPAT_SC_IA32_STUBx(x, name, ...)
-#define SC_IA32_WRAPPERx(x, fullname, name, ...)
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)
+#define __IA32_SYS_STUBx(x, fullname, name, ...)
 #endif /* CONFIG_IA32_EMULATION */
 
 
@@ -75,7 +75,7 @@
  * of the x86-64-style parameter ordering of x32 syscalls. The syscalls common
  * with x86_64 obviously do not need such care.
  */
-#define COMPAT_SC_X32_STUBx(x, name, ...)  \
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__x32_compat_sys##name, ERRNO);   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs)\
@@ -84,7 +84,7 @@
}   \
 
 #else /* CONFIG_X86_X32 */
-#define COMPAT_SC_X32_STUBx(x, name, ...)
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)
 #endif /* CONFIG_X86_X32 */
 
 
@@ -97,8 +97,8 @@
 #define COMPAT_SYSCALL_DEFINEx(x, name, ...)   
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));  
\
static inline long 
__do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
-   COMPAT_SC_IA32_STUBx(x, name, __VA_ARGS__)  
\
-   COMPAT_SC_X32_STUBx(x, name, __VA_ARGS__)   
\
+   __IA32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)   
\
+   __X32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))   
\
{   
\
return 
__do_compat_sys##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__));\
@@ -163,7 +163,7 @@
{   \
return __se_sys##name(SC_X86_64_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
-   SC_IA32_WRAPPERx(x, name, __VA_ARGS__)  \
+   __IA32_SYS_STUBx(x, name, __VA_ARG

[tip:x86/asm] syscalls/x86: Adapt syscall_wrapper.h to the new syscall stub naming convention

[tip-bot for Dominik Brodowski]

Commit-ID:  c76fc98260751e71c884dc1a18a07e427ef033b5
Gitweb: https://git.kernel.org/tip/c76fc98260751e71c884dc1a18a07e427ef033b5
Author: Dominik Brodowski 
AuthorDate: Mon, 9 Apr 2018 12:51:45 +0200
Committer:  Ingo Molnar 
CommitDate: Mon, 9 Apr 2018 16:47:28 +0200

syscalls/x86: Adapt syscall_wrapper.h to the new syscall stub naming convention

Make the code in syscall_wrapper.h more readable by naming the stub macros
similar to the stub they provide. While at it, fix a stray newline at the
end of the __IA32_COMPAT_SYS_STUBx macro.

Signed-off-by: Dominik Brodowski 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180409105145.5364-5-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/syscall_wrapper.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/syscall_wrapper.h 
b/arch/x86/include/asm/syscall_wrapper.h
index a598013e08e9..e046a405743d 100644
--- a/arch/x86/include/asm/syscall_wrapper.h
+++ b/arch/x86/include/asm/syscall_wrapper.h
@@ -28,7 +28,7 @@
  * kernel/sys_ni.c and SYS_NI in kernel/time/posix-stubs.c to cover this
  * case as well.
  */
-#define COMPAT_SC_IA32_STUBx(x, name, ...) \
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__ia32_compat_sys##name, ERRNO);  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs)\
@@ -36,7 +36,7 @@
return 
__se_compat_sys##name(SC_IA32_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
 
-#define SC_IA32_WRAPPERx(x, name, ...) \
+#define __IA32_SYS_STUBx(x, name, ...) \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs);   \
ALLOW_ERROR_INJECTION(__ia32_sys##name, ERRNO); \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs)\
@@ -64,8 +64,8 @@
SYSCALL_ALIAS(__ia32_sys_##name, sys_ni_posix_timers)
 
 #else /* CONFIG_IA32_EMULATION */
-#define COMPAT_SC_IA32_STUBx(x, name, ...)
-#define SC_IA32_WRAPPERx(x, fullname, name, ...)
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)
+#define __IA32_SYS_STUBx(x, fullname, name, ...)
 #endif /* CONFIG_IA32_EMULATION */
 
 
@@ -75,7 +75,7 @@
  * of the x86-64-style parameter ordering of x32 syscalls. The syscalls common
  * with x86_64 obviously do not need such care.
  */
-#define COMPAT_SC_X32_STUBx(x, name, ...)  \
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__x32_compat_sys##name, ERRNO);   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs)\
@@ -84,7 +84,7 @@
}   \
 
 #else /* CONFIG_X86_X32 */
-#define COMPAT_SC_X32_STUBx(x, name, ...)
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)
 #endif /* CONFIG_X86_X32 */
 
 
@@ -97,8 +97,8 @@
 #define COMPAT_SYSCALL_DEFINEx(x, name, ...)   
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));  
\
static inline long 
__do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
-   COMPAT_SC_IA32_STUBx(x, name, __VA_ARGS__)  
\
-   COMPAT_SC_X32_STUBx(x, name, __VA_ARGS__)   
\
+   __IA32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)   
\
+   __X32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))   
\
{   
\
return 
__do_compat_sys##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__));\
@@ -163,7 +163,7 @@
{   \
return __se_sys##name(SC_X86_64_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
-   SC_IA32_WRAPPERx(x, name, __VA_ARGS__)  \
+   __IA32_SYS_STUBx(x, name, __VA_ARGS__)  \
static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))  \
{   \
long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\

[tip:x86/asm] syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()

[tip-bot for Dominik Brodowski]

Commit-ID:  d5a00528b58cdb2c71206e18bd021e34c4eab878
Gitweb: https://git.kernel.org/tip/d5a00528b58cdb2c71206e18bd021e34c4eab878
Author: Dominik Brodowski <li...@dominikbrodowski.net>
AuthorDate: Mon, 9 Apr 2018 12:51:44 +0200
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Mon, 9 Apr 2018 16:47:28 +0200

syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to 
__x64_sys_*()

This rename allows us to have a coherent syscall stub naming convention on
64-bit x86 (0x prefix removed):

 810f0af0 tkernel_waitid# common (32/64) kernel helper

 __do_sys_waitid# inlined helper doing actual work
 810f0be0 t  __se_sys_waitid# C func calling inlined helper

  __do_compat_sys_waitid# inlined helper doing actual work
 810f0d80 t   __se_compat_sys_waitid# compat C func calling inlined helper

 810f2080 T __x64_sys_waitid# x64 64-bit-ptregs -> C stub
 810f20b0 T__ia32_sys_waitid# ia32 32-bit-ptregs -> C stub[*]
 810f2470 T __ia32_compat_sys_waitid# ia32 32-bit-ptregs -> compat C stub
 810f2490 T  __x32_compat_sys_waitid# x32 64-bit-ptregs -> compat C stub

[*] This stub is unused, as the syscall table links
__ia32_compat_sys_waitid instead of __ia32_sys_waitid as we need
a compat variant here.

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: http://lkml.kernel.org/r/20180409105145.5364-4-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/entry/syscalls/syscall_32.tbl |  46 +--
 arch/x86/entry/syscalls/syscall_64.tbl | 638 +
 arch/x86/entry/syscalls/syscalltbl.sh  |  14 +-
 arch/x86/entry/vsyscall/vsyscall_64.c  |   6 +-
 arch/x86/include/asm/syscall_wrapper.h |  63 +++-
 5 files changed, 405 insertions(+), 362 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 0e6cb1335db2..d6b27dab1b30 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -11,9 +11,9 @@
 #
 # The abi is always "i386" for this file.
 #
-0  i386restart_syscall sys_restart_syscall
+0  i386restart_syscall sys_restart_syscall 
__ia32_sys_restart_syscall
 1  i386exitsys_exit
__ia32_sys_exit
-2  i386forksys_fork
+2  i386forksys_fork
__ia32_sys_fork
 3  i386readsys_read
__ia32_sys_read
 4  i386write   sys_write   
__ia32_sys_write
 5  i386opensys_open
__ia32_compat_sys_open
@@ -31,23 +31,23 @@
 17 i386break
 18 i386oldstat sys_stat
__ia32_sys_stat
 19 i386lseek   sys_lseek   
__ia32_compat_sys_lseek
-20 i386getpid  sys_getpid
+20 i386getpid  sys_getpid  
__ia32_sys_getpid
 21 i386mount   sys_mount   
__ia32_compat_sys_mount
 22 i386umount  sys_oldumount   
__ia32_sys_oldumount
 23 i386setuid  sys_setuid16
__ia32_sys_setuid16
-24 i386getuid  sys_getuid16
+24 i386getuid  sys_getuid16
__ia32_sys_getuid16
 25 i386stime   sys_stime   
__ia32_compat_sys_stime
 26 i386ptrace  sys_ptrace  
__ia32_compat_sys_ptrace
 27 i386alarm   sys_alarm   
__ia32_sys_alarm
 28 i386oldfstatsys_fstat   
__ia32_sys_fstat
-29 i386pause   sys_pause
+29 i386pause   sys_pause   
__ia32_sys_pause
 30 i386utime   sys_utime   
__ia32_compat_sys_utime
 31 i386stty
 32 i386gtty
 33 i386access  sys_access  
__ia32_sys_access
 34 i386nicesys_nice

[tip:x86/asm] syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()

[tip-bot for Dominik Brodowski]

Commit-ID:  d5a00528b58cdb2c71206e18bd021e34c4eab878
Gitweb: https://git.kernel.org/tip/d5a00528b58cdb2c71206e18bd021e34c4eab878
Author: Dominik Brodowski 
AuthorDate: Mon, 9 Apr 2018 12:51:44 +0200
Committer:  Ingo Molnar 
CommitDate: Mon, 9 Apr 2018 16:47:28 +0200

syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to 
__x64_sys_*()

This rename allows us to have a coherent syscall stub naming convention on
64-bit x86 (0x prefix removed):

 810f0af0 tkernel_waitid# common (32/64) kernel helper

 __do_sys_waitid# inlined helper doing actual work
 810f0be0 t  __se_sys_waitid# C func calling inlined helper

  __do_compat_sys_waitid# inlined helper doing actual work
 810f0d80 t   __se_compat_sys_waitid# compat C func calling inlined helper

 810f2080 T __x64_sys_waitid# x64 64-bit-ptregs -> C stub
 810f20b0 T__ia32_sys_waitid# ia32 32-bit-ptregs -> C stub[*]
 810f2470 T __ia32_compat_sys_waitid# ia32 32-bit-ptregs -> compat C stub
 810f2490 T  __x32_compat_sys_waitid# x32 64-bit-ptregs -> compat C stub

[*] This stub is unused, as the syscall table links
__ia32_compat_sys_waitid instead of __ia32_sys_waitid as we need
a compat variant here.

Suggested-by: Ingo Molnar 
Signed-off-by: Dominik Brodowski 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180409105145.5364-4-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/syscalls/syscall_32.tbl |  46 +--
 arch/x86/entry/syscalls/syscall_64.tbl | 638 +
 arch/x86/entry/syscalls/syscalltbl.sh  |  14 +-
 arch/x86/entry/vsyscall/vsyscall_64.c  |   6 +-
 arch/x86/include/asm/syscall_wrapper.h |  63 +++-
 5 files changed, 405 insertions(+), 362 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 0e6cb1335db2..d6b27dab1b30 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -11,9 +11,9 @@
 #
 # The abi is always "i386" for this file.
 #
-0  i386restart_syscall sys_restart_syscall
+0  i386restart_syscall sys_restart_syscall 
__ia32_sys_restart_syscall
 1  i386exitsys_exit
__ia32_sys_exit
-2  i386forksys_fork
+2  i386forksys_fork
__ia32_sys_fork
 3  i386readsys_read
__ia32_sys_read
 4  i386write   sys_write   
__ia32_sys_write
 5  i386opensys_open
__ia32_compat_sys_open
@@ -31,23 +31,23 @@
 17 i386break
 18 i386oldstat sys_stat
__ia32_sys_stat
 19 i386lseek   sys_lseek   
__ia32_compat_sys_lseek
-20 i386getpid  sys_getpid
+20 i386getpid  sys_getpid  
__ia32_sys_getpid
 21 i386mount   sys_mount   
__ia32_compat_sys_mount
 22 i386umount  sys_oldumount   
__ia32_sys_oldumount
 23 i386setuid  sys_setuid16
__ia32_sys_setuid16
-24 i386getuid  sys_getuid16
+24 i386getuid  sys_getuid16
__ia32_sys_getuid16
 25 i386stime   sys_stime   
__ia32_compat_sys_stime
 26 i386ptrace  sys_ptrace  
__ia32_compat_sys_ptrace
 27 i386alarm   sys_alarm   
__ia32_sys_alarm
 28 i386oldfstatsys_fstat   
__ia32_sys_fstat
-29 i386pause   sys_pause
+29 i386pause   sys_pause   
__ia32_sys_pause
 30 i386utime   sys_utime   
__ia32_compat_sys_utime
 31 i386stty
 32 i386gtty
 33 i386access  sys_access  
__ia32_sys_access
 34 i386nicesys_nice
__ia32_sys_nice
 35 i386ftime
-36 i386syncsys_sync
+36 i386syncsys_sync
__ia32_sys_sync
 37 i386killsys_kill
__ia32_sys_kill
 38 i386rename  sys_rename  
__ia32_sys_rename
 39 i386mkdir  

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention

[tip-bot for Dominik Brodowski]

Commit-ID:  5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92
Gitweb: https://git.kernel.org/tip/5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92
Author: Dominik Brodowski <li...@dominikbrodowski.net>
AuthorDate: Mon, 9 Apr 2018 12:51:43 +0200
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Mon, 9 Apr 2018 16:47:28 +0200

syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention

Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the COMPAT_SYSCALL_DEFINEx()
macro.

For the generic case, this means:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

T   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

Tcompat_sys_waitid  # alias to __se_compat_sys_waitid()
# (taking parameters as declared), to
# be included in syscall table

For x86, the naming is as follows:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

t   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

T __ia32_compat_sys_waitid  # IA32_EMULATION 32-bit-ptregs -> C stub,
# calls __se_compat_sys_waitid(); to be
# included in syscall table

T  __x32_compat_sys_waitid  # x32 64-bit-ptregs -> C stub, calls
# __se_compat_sys_waitid(); to be included
# in syscall table

If only one of IA32_EMULATION and x32 is enabled, __se_compat_sys_waitid()
may be inlined into the stub __{ia32,x32}_compat_sys_waitid().

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: http://lkml.kernel.org/r/20180409105145.5364-3-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 Documentation/process/adding-syscalls.rst |   4 +-
 arch/x86/entry/syscalls/syscall_32.tbl| 252 +++---
 arch/x86/entry/syscalls/syscall_64.tbl|  72 -
 arch/x86/include/asm/syscall_wrapper.h|  44 +++---
 arch/x86/include/asm/syscalls.h   |   2 +-
 include/linux/compat.h|  29 ++--
 scripts/bloat-o-meter |   2 +-
 7 files changed, 205 insertions(+), 200 deletions(-)

diff --git a/Documentation/process/adding-syscalls.rst 
b/Documentation/process/adding-syscalls.rst
index 314c8bf6f2a2..0d4f29bc798b 100644
--- a/Documentation/process/adding-syscalls.rst
+++ b/Documentation/process/adding-syscalls.rst
@@ -360,7 +360,7 @@ First, the entry in 
``arch/x86/entry/syscalls/syscall_32.tbl`` gets an extra
 column to indicate that a 32-bit userspace program running on a 64-bit kernel
 should hit the compat entry point::
 
-380   i386 xyzzy sys_xyzzycompat_sys_xyzzy
+380   i386 xyzzy sys_xyzzy__ia32_compat_sys_xyzzy
 
 Second, you need to figure out what should happen for the x32 ABI version of
 the new system call.  There's a choice here: the layout of the arguments
@@ -373,7 +373,7 @@ the compatibility wrapper::
 
 333   64   xyzzy sys_xyzzy
 ...
-555   x32  xyzzy compat_sys_xyzzy
+555   x32  xyzzy __x32_compat_sys_xyzzy
 
 If no pointers are involved, then it is preferable to re-use the 64-bit system
 call for the x32 ABI (and consequently the entry in
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 539df8f6d0e1..0e6cb1335db2 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -4,7 +4,7 @@
 # The format is:
 # 
 #
-# The __ia32_sys and 

[tip:x86/asm] syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention

[tip-bot for Dominik Brodowski]

Commit-ID:  5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92
Gitweb: https://git.kernel.org/tip/5ac9efa3c50d7caff9f3933bb8a3ad1139d92d92
Author: Dominik Brodowski 
AuthorDate: Mon, 9 Apr 2018 12:51:43 +0200
Committer:  Ingo Molnar 
CommitDate: Mon, 9 Apr 2018 16:47:28 +0200

syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention

Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the COMPAT_SYSCALL_DEFINEx()
macro.

For the generic case, this means:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

T   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

Tcompat_sys_waitid  # alias to __se_compat_sys_waitid()
# (taking parameters as declared), to
# be included in syscall table

For x86, the naming is as follows:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

t   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

T __ia32_compat_sys_waitid  # IA32_EMULATION 32-bit-ptregs -> C stub,
# calls __se_compat_sys_waitid(); to be
# included in syscall table

T  __x32_compat_sys_waitid  # x32 64-bit-ptregs -> C stub, calls
# __se_compat_sys_waitid(); to be included
# in syscall table

If only one of IA32_EMULATION and x32 is enabled, __se_compat_sys_waitid()
may be inlined into the stub __{ia32,x32}_compat_sys_waitid().

Suggested-by: Ingo Molnar 
Signed-off-by: Dominik Brodowski 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180409105145.5364-3-li...@dominikbrodowski.net
Signed-off-by: Ingo Molnar 
---
 Documentation/process/adding-syscalls.rst |   4 +-
 arch/x86/entry/syscalls/syscall_32.tbl| 252 +++---
 arch/x86/entry/syscalls/syscall_64.tbl|  72 -
 arch/x86/include/asm/syscall_wrapper.h|  44 +++---
 arch/x86/include/asm/syscalls.h   |   2 +-
 include/linux/compat.h|  29 ++--
 scripts/bloat-o-meter |   2 +-
 7 files changed, 205 insertions(+), 200 deletions(-)

diff --git a/Documentation/process/adding-syscalls.rst 
b/Documentation/process/adding-syscalls.rst
index 314c8bf6f2a2..0d4f29bc798b 100644
--- a/Documentation/process/adding-syscalls.rst
+++ b/Documentation/process/adding-syscalls.rst
@@ -360,7 +360,7 @@ First, the entry in 
``arch/x86/entry/syscalls/syscall_32.tbl`` gets an extra
 column to indicate that a 32-bit userspace program running on a 64-bit kernel
 should hit the compat entry point::
 
-380   i386 xyzzy sys_xyzzycompat_sys_xyzzy
+380   i386 xyzzy sys_xyzzy__ia32_compat_sys_xyzzy
 
 Second, you need to figure out what should happen for the x32 ABI version of
 the new system call.  There's a choice here: the layout of the arguments
@@ -373,7 +373,7 @@ the compatibility wrapper::
 
 333   64   xyzzy sys_xyzzy
 ...
-555   x32  xyzzy compat_sys_xyzzy
+555   x32  xyzzy __x32_compat_sys_xyzzy
 
 If no pointers are involved, then it is preferable to re-use the 64-bit system
 call for the x32 ABI (and consequently the entry in
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 539df8f6d0e1..0e6cb1335db2 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -4,7 +4,7 @@
 # The format is:
 # 
 #
-# The __ia32_sys and __compat_sys_ia32 stubs are created on-the-fly for
+# The __ia32_sys and __ia32_compat_sys stubs are created on-the-fly for
 # sys_*() system calls and compat_sys_*() compat system calls if
 # IA32_EMULATION is defined, and expect struct pt_regs *regs as their only
 # parameter.
@@ -16,32 +16,32 @@
 2  i386forksys_fork
 3  i386readsy

[PATCHv2 4/4] syscalls/x86: adapt syscall_wrapper.h to the new syscall stub naming convention

[Dominik Brodowski]

Make the code in syscall_wrapper.h more readable by naming the stub macros
similar to the stub they provide. While at it, fix a stray newline at the
end of the __IA32_COMPAT_SYS_STUBx macro.

Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
---
 arch/x86/include/asm/syscall_wrapper.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/syscall_wrapper.h 
b/arch/x86/include/asm/syscall_wrapper.h
index a598013e08e9..e046a405743d 100644
--- a/arch/x86/include/asm/syscall_wrapper.h
+++ b/arch/x86/include/asm/syscall_wrapper.h
@@ -28,7 +28,7 @@
  * kernel/sys_ni.c and SYS_NI in kernel/time/posix-stubs.c to cover this
  * case as well.
  */
-#define COMPAT_SC_IA32_STUBx(x, name, ...) \
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__ia32_compat_sys##name, ERRNO);  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs)\
@@ -36,7 +36,7 @@
return 
__se_compat_sys##name(SC_IA32_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
 
-#define SC_IA32_WRAPPERx(x, name, ...) \
+#define __IA32_SYS_STUBx(x, name, ...) \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs);   \
ALLOW_ERROR_INJECTION(__ia32_sys##name, ERRNO); \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs)\
@@ -64,8 +64,8 @@
SYSCALL_ALIAS(__ia32_sys_##name, sys_ni_posix_timers)
 
 #else /* CONFIG_IA32_EMULATION */
-#define COMPAT_SC_IA32_STUBx(x, name, ...)
-#define SC_IA32_WRAPPERx(x, fullname, name, ...)
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)
+#define __IA32_SYS_STUBx(x, fullname, name, ...)
 #endif /* CONFIG_IA32_EMULATION */
 
 
@@ -75,7 +75,7 @@
  * of the x86-64-style parameter ordering of x32 syscalls. The syscalls common
  * with x86_64 obviously do not need such care.
  */
-#define COMPAT_SC_X32_STUBx(x, name, ...)  \
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__x32_compat_sys##name, ERRNO);   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs)\
@@ -84,7 +84,7 @@
}   \
 
 #else /* CONFIG_X86_X32 */
-#define COMPAT_SC_X32_STUBx(x, name, ...)
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)
 #endif /* CONFIG_X86_X32 */
 
 
@@ -97,8 +97,8 @@
 #define COMPAT_SYSCALL_DEFINEx(x, name, ...)   
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));  
\
static inline long 
__do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
-   COMPAT_SC_IA32_STUBx(x, name, __VA_ARGS__)  
\
-   COMPAT_SC_X32_STUBx(x, name, __VA_ARGS__)   
\
+   __IA32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)   
\
+   __X32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))   
\
{   
\
return 
__do_compat_sys##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__));\
@@ -163,7 +163,7 @@
{   \
return __se_sys##name(SC_X86_64_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
-   SC_IA32_WRAPPERx(x, name, __VA_ARGS__)  \
+   __IA32_SYS_STUBx(x, name, __VA_ARGS__)  \
static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))  \
{   \
long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\
-- 
2.17.0

[PATCHv2 4/4] syscalls/x86: adapt syscall_wrapper.h to the new syscall stub naming convention

[Dominik Brodowski]

Make the code in syscall_wrapper.h more readable by naming the stub macros
similar to the stub they provide. While at it, fix a stray newline at the
end of the __IA32_COMPAT_SYS_STUBx macro.

Cc: Linus Torvalds 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Dominik Brodowski 
---
 arch/x86/include/asm/syscall_wrapper.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/syscall_wrapper.h 
b/arch/x86/include/asm/syscall_wrapper.h
index a598013e08e9..e046a405743d 100644
--- a/arch/x86/include/asm/syscall_wrapper.h
+++ b/arch/x86/include/asm/syscall_wrapper.h
@@ -28,7 +28,7 @@
  * kernel/sys_ni.c and SYS_NI in kernel/time/posix-stubs.c to cover this
  * case as well.
  */
-#define COMPAT_SC_IA32_STUBx(x, name, ...) \
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__ia32_compat_sys##name, ERRNO);  \
asmlinkage long __ia32_compat_sys##name(const struct pt_regs *regs)\
@@ -36,7 +36,7 @@
return 
__se_compat_sys##name(SC_IA32_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
 
-#define SC_IA32_WRAPPERx(x, name, ...) \
+#define __IA32_SYS_STUBx(x, name, ...) \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs);   \
ALLOW_ERROR_INJECTION(__ia32_sys##name, ERRNO); \
asmlinkage long __ia32_sys##name(const struct pt_regs *regs)\
@@ -64,8 +64,8 @@
SYSCALL_ALIAS(__ia32_sys_##name, sys_ni_posix_timers)
 
 #else /* CONFIG_IA32_EMULATION */
-#define COMPAT_SC_IA32_STUBx(x, name, ...)
-#define SC_IA32_WRAPPERx(x, fullname, name, ...)
+#define __IA32_COMPAT_SYS_STUBx(x, name, ...)
+#define __IA32_SYS_STUBx(x, fullname, name, ...)
 #endif /* CONFIG_IA32_EMULATION */
 
 
@@ -75,7 +75,7 @@
  * of the x86-64-style parameter ordering of x32 syscalls. The syscalls common
  * with x86_64 obviously do not need such care.
  */
-#define COMPAT_SC_X32_STUBx(x, name, ...)  \
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs);\
ALLOW_ERROR_INJECTION(__x32_compat_sys##name, ERRNO);   \
asmlinkage long __x32_compat_sys##name(const struct pt_regs *regs)\
@@ -84,7 +84,7 @@
}   \
 
 #else /* CONFIG_X86_X32 */
-#define COMPAT_SC_X32_STUBx(x, name, ...)
+#define __X32_COMPAT_SYS_STUBx(x, name, ...)
 #endif /* CONFIG_X86_X32 */
 
 
@@ -97,8 +97,8 @@
 #define COMPAT_SYSCALL_DEFINEx(x, name, ...)   
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));  
\
static inline long 
__do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
-   COMPAT_SC_IA32_STUBx(x, name, __VA_ARGS__)  
\
-   COMPAT_SC_X32_STUBx(x, name, __VA_ARGS__)   
\
+   __IA32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)   
\
+   __X32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)
\
static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))   
\
{   
\
return 
__do_compat_sys##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__));\
@@ -163,7 +163,7 @@
{   \
return __se_sys##name(SC_X86_64_REGS_TO_ARGS(x,__VA_ARGS__));\
}   \
-   SC_IA32_WRAPPERx(x, name, __VA_ARGS__)  \
+   __IA32_SYS_STUBx(x, name, __VA_ARGS__)  \
static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))  \
{   \
long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\
-- 
2.17.0

[PATCHv2 2/4] syscalls: clean up compat syscall stub naming convention

[Dominik Brodowski]

Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the COMPAT_SYSCALL_DEFINEx()
macro.

For the generic case, this means:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

T   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

Tcompat_sys_waitid  # alias to __se_compat_sys_waitid()
# (taking parameters as declared), to
# be included in syscall table

For x86, the naming is as follows:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

t   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

T __ia32_compat_sys_waitid  # IA32_EMULATION 32-bit-ptregs -> C stub,
# calls __se_compat_sys_waitid(); to be
# included in syscall table

T  __x32_compat_sys_waitid  # x32 64-bit-ptregs -> C stub, calls
# __se_compat_sys_waitid(); to be included
# in syscall table

If only one of IA32_EMULATION and x32 is enabled, __se_compat_sys_waitid()
may be inlined into the stub __{ia32,x32}_compat_sys_waitid().

Suggested-by: Ingo Molnar <mi...@kernel.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
---
 Documentation/process/adding-syscalls.rst |   4 +-
 arch/x86/entry/syscalls/syscall_32.tbl| 252 +++---
 arch/x86/entry/syscalls/syscall_64.tbl|  72 +++
 arch/x86/include/asm/syscall_wrapper.h|  44 ++--
 arch/x86/include/asm/syscalls.h   |   2 +-
 include/linux/compat.h|  29 +--
 scripts/bloat-o-meter |   2 +-
 7 files changed, 205 insertions(+), 200 deletions(-)

diff --git a/Documentation/process/adding-syscalls.rst 
b/Documentation/process/adding-syscalls.rst
index 314c8bf6f2a2..0d4f29bc798b 100644
--- a/Documentation/process/adding-syscalls.rst
+++ b/Documentation/process/adding-syscalls.rst
@@ -360,7 +360,7 @@ First, the entry in 
``arch/x86/entry/syscalls/syscall_32.tbl`` gets an extra
 column to indicate that a 32-bit userspace program running on a 64-bit kernel
 should hit the compat entry point::
 
-380   i386 xyzzy sys_xyzzycompat_sys_xyzzy
+380   i386 xyzzy sys_xyzzy__ia32_compat_sys_xyzzy
 
 Second, you need to figure out what should happen for the x32 ABI version of
 the new system call.  There's a choice here: the layout of the arguments
@@ -373,7 +373,7 @@ the compatibility wrapper::
 
 333   64   xyzzy sys_xyzzy
 ...
-555   x32  xyzzy compat_sys_xyzzy
+555   x32  xyzzy __x32_compat_sys_xyzzy
 
 If no pointers are involved, then it is preferable to re-use the 64-bit system
 call for the x32 ABI (and consequently the entry in
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 539df8f6d0e1..0e6cb1335db2 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -4,7 +4,7 @@
 # The format is:
 # 
 #
-# The __ia32_sys and __compat_sys_ia32 stubs are created on-the-fly for
+# The __ia32_sys and __ia32_compat_sys stubs are created on-the-fly for
 # sys_*() system calls and compat_sys_*() compat system calls if
 # IA32_EMULATION is defined, and expect struct pt_regs *regs as their only
 # parameter.
@@ -16,32 +16,32 @@
 2  i386forksys_fork
 3  i386readsys_read
__ia32_sys_read
 4  i386write   sys_write 

[PATCHv2 2/4] syscalls: clean up compat syscall stub naming convention

[Dominik Brodowski]

Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the COMPAT_SYSCALL_DEFINEx()
macro.

For the generic case, this means:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

T   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

Tcompat_sys_waitid  # alias to __se_compat_sys_waitid()
# (taking parameters as declared), to
# be included in syscall table

For x86, the naming is as follows:

tkernel_waitid  # common C function (see kernel/exit.c)

__do_compat_sys_waitid  # inlined helper doing the actual work
# (takes original parameters as declared)

t   __se_compat_sys_waitid  # sign-extending C function calling inlined
# helper (takes parameters of type long,
# casts them to unsigned long and then to
# the declared type)

T __ia32_compat_sys_waitid  # IA32_EMULATION 32-bit-ptregs -> C stub,
# calls __se_compat_sys_waitid(); to be
# included in syscall table

T  __x32_compat_sys_waitid  # x32 64-bit-ptregs -> C stub, calls
# __se_compat_sys_waitid(); to be included
# in syscall table

If only one of IA32_EMULATION and x32 is enabled, __se_compat_sys_waitid()
may be inlined into the stub __{ia32,x32}_compat_sys_waitid().

Suggested-by: Ingo Molnar 
Cc: Linus Torvalds 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Dominik Brodowski 
---
 Documentation/process/adding-syscalls.rst |   4 +-
 arch/x86/entry/syscalls/syscall_32.tbl| 252 +++---
 arch/x86/entry/syscalls/syscall_64.tbl|  72 +++
 arch/x86/include/asm/syscall_wrapper.h|  44 ++--
 arch/x86/include/asm/syscalls.h   |   2 +-
 include/linux/compat.h|  29 +--
 scripts/bloat-o-meter |   2 +-
 7 files changed, 205 insertions(+), 200 deletions(-)

diff --git a/Documentation/process/adding-syscalls.rst 
b/Documentation/process/adding-syscalls.rst
index 314c8bf6f2a2..0d4f29bc798b 100644
--- a/Documentation/process/adding-syscalls.rst
+++ b/Documentation/process/adding-syscalls.rst
@@ -360,7 +360,7 @@ First, the entry in 
``arch/x86/entry/syscalls/syscall_32.tbl`` gets an extra
 column to indicate that a 32-bit userspace program running on a 64-bit kernel
 should hit the compat entry point::
 
-380   i386 xyzzy sys_xyzzycompat_sys_xyzzy
+380   i386 xyzzy sys_xyzzy__ia32_compat_sys_xyzzy
 
 Second, you need to figure out what should happen for the x32 ABI version of
 the new system call.  There's a choice here: the layout of the arguments
@@ -373,7 +373,7 @@ the compatibility wrapper::
 
 333   64   xyzzy sys_xyzzy
 ...
-555   x32  xyzzy compat_sys_xyzzy
+555   x32  xyzzy __x32_compat_sys_xyzzy
 
 If no pointers are involved, then it is preferable to re-use the 64-bit system
 call for the x32 ABI (and consequently the entry in
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 539df8f6d0e1..0e6cb1335db2 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -4,7 +4,7 @@
 # The format is:
 # 
 #
-# The __ia32_sys and __compat_sys_ia32 stubs are created on-the-fly for
+# The __ia32_sys and __ia32_compat_sys stubs are created on-the-fly for
 # sys_*() system calls and compat_sys_*() compat system calls if
 # IA32_EMULATION is defined, and expect struct pt_regs *regs as their only
 # parameter.
@@ -16,32 +16,32 @@
 2  i386forksys_fork
 3  i386readsys_read
__ia32_sys_read
 4  i386write   sys_write   
__ia32_sys_write
-5  i386opensys_open
__compat_sys_ia32_open
+5  i386opensys_open
__ia32_compat_sys_open
 6  i386close   sys_close   
__ia32_sys_close
 7  i386waitpid sys_w

[PATCHv2 1/4] syscalls: clean up syscall stub naming convention

[Dominik Brodowski]

Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the SYSCALL_DEFINEx() macro.

For the generic case, this means (0x prefix removed):

810f08d0 t kernel_waitid# common C function (see kernel/exit.c)

 __do_sys_waitid# inlined helper doing the actual work
# (takes original parameters as declared)

810f1aa0 T   __se_sys_waitid# sign-extending C function calling inlined
# helper (takes parameters of type long;
# casts them to the declared type)

810f1aa0 Tsys_waitid# alias to __se_sys_waitid() (taking
# parameters as declared), to be included
# in syscall table

For x86, the naming is as follows:

810efc70 t kernel_waitid# common C function (see kernel/exit.c)

 __do_sys_waitid# inlined helper doing the actual work
# (takes original parameters as declared)

810efd60 t   __se_sys_waitid# sign-extending C function calling inlined
# helper (takes parameters of type long;
# casts them to the declared type)

810f1140 T __ia32_sys_waitid# IA32_EMULATION 32-bit-ptregs -> C stub,
# calls __se_sys_waitid(); to be included
# in syscall table

810f1110 Tsys_waitid# x86 64-bit-ptregs -> C stub, calls
# __se_sys_waitid(); to be included in
# syscall table

For x86, sys_waitid() will be re-named to __x64_sys_waitid in a follow-up
patch.

Suggested-by: Ingo Molnar <mi...@kernel.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net>
---
 arch/x86/entry/syscalls/syscall_32.tbl | 424 -
 arch/x86/include/asm/syscall_wrapper.h |  35 +-
 include/linux/syscalls.h   |  17 +-
 scripts/bloat-o-meter  |   2 +-
 4 files changed, 242 insertions(+), 236 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 7f09a3da0b3d..539df8f6d0e1 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -4,7 +4,7 @@
 # The format is:
 # 
 #
-# The __sys_ia32 and __compat_sys_ia32 stubs are created on-the-fly for
+# The __ia32_sys and __compat_sys_ia32 stubs are created on-the-fly for
 # sys_*() system calls and compat_sys_*() compat system calls if
 # IA32_EMULATION is defined, and expect struct pt_regs *regs as their only
 # parameter.
@@ -12,284 +12,284 @@
 # The abi is always "i386" for this file.
 #
 0  i386restart_syscall sys_restart_syscall
-1  i386exitsys_exit
__sys_ia32_exit
+1  i386exitsys_exit
__ia32_sys_exit
 2  i386forksys_fork
-3  i386readsys_read
__sys_ia32_read
-4  i386write   sys_write   
__sys_ia32_write
+3  i386readsys_read
__ia32_sys_read
+4  i386write   sys_write   
__ia32_sys_write
 5  i386opensys_open
__compat_sys_ia32_open
-6  i386close   sys_close   
__sys_ia32_close
-7  i386waitpid sys_waitpid 
__sys_ia32_waitpid
-8  i386creat   sys_creat   
__sys_ia32_creat
-9  i386linksys_link
__sys_ia32_link
-10 i386unlink  sys_unlink  
__sys_ia32_unlink
+6  i386close   sys_close   
__ia32_sys_close
+7  i386waitpid sys_waitpid 
__ia32_sys_waitpid
+8  i386creat   sys_creat   
__ia32_sys_creat
+9  i386linksys_link
__ia32_sys_link
+10 i386unl