* Re: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)
From: Florian Weimer @ 2015-07-21 8:01 UTC (permalink / raw)
To: Mathieu Desnoyers, Linus Torvalds
Cc: Andy Lutomirski, Ben Maurer, Ingo Molnar, libc-alpha,
Andrew Morton, linux-api, Ondřej Bílka, rostedt,
Paul E. McKenney, Josh Triplett, Paul Turner, Andrew Hunter,
Peter Zijlstra
In-Reply-To: <2010227315.699.1437438300542.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
On 07/21/2015 02:25 AM, Mathieu Desnoyers wrote:
> But I'm inclined to think that some aspect of the question eludes me,
> especially given the amount of interest generated by the gs-segment
> selector approach. What am I missing ?
%gs is not explicitly mentioned in the x86_64 psABI. This probably led
to the assumption that it's unused. I think that's not the right
conclusion to draw.
--
Florian Weimer / Red Hat Product Security
^ permalink raw reply
* Re: [PATCH v4 1/5] pagemap: check permissions and capabilities at open time
From: Naoya Horiguchi @ 2015-07-21 8:06 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: linux-mm@kvack.org, Andrew Morton, Kirill A. Shutemov,
Mark Williamson, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org
In-Reply-To: <20150714153735.29844.38428.stgit@buzz>
On Tue, Jul 14, 2015 at 06:37:35PM +0300, Konstantin Khlebnikov wrote:
> This patch moves permission checks from pagemap_read() into pagemap_open().
>
> Pointer to mm is saved in file->private_data. This reference pins only
> mm_struct itself. /proc/*/mem, maps, smaps already work in the same way.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Link: http://lkml.kernel.org/r/CA+55aFyKpWrt_Ajzh1rzp_GcwZ4=6Y=kOv8hBz172CFJp6L8Tg@mail.gmail.com
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 4/5] pagemap: hide physical addresses from non-privileged users
From: Naoya Horiguchi @ 2015-07-21 8:11 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: linux-mm@kvack.org, Andrew Morton, Kirill A. Shutemov,
Mark Williamson, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org
In-Reply-To: <20150714153747.29844.13543.stgit@buzz>
On Tue, Jul 14, 2015 at 06:37:47PM +0300, Konstantin Khlebnikov wrote:
> This patch makes pagemap readable for normal users and hides physical
> addresses from them. For some use-cases PFN isn't required at all.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Fixes: ab676b7d6fbf ("pagemap: do not leak physical addresses to non-privileged userspace")
> Link: http://lkml.kernel.org/r/1425935472-17949-1-git-send-email-kirill@shutemov.name
> ---
> fs/proc/task_mmu.c | 25 ++++++++++++++-----------
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 040721fa405a..3a5d338ea219 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -937,6 +937,7 @@ typedef struct {
> struct pagemapread {
> int pos, len; /* units: PM_ENTRY_BYTES, not bytes */
> pagemap_entry_t *buffer;
> + bool show_pfn;
> };
>
> #define PAGEMAP_WALK_SIZE (PMD_SIZE)
> @@ -1013,7 +1014,8 @@ static pagemap_entry_t pte_to_pagemap_entry(struct pagemapread *pm,
> struct page *page = NULL;
>
> if (pte_present(pte)) {
> - frame = pte_pfn(pte);
> + if (pm->show_pfn)
> + frame = pte_pfn(pte);
> flags |= PM_PRESENT;
> page = vm_normal_page(vma, addr, pte);
> if (pte_soft_dirty(pte))
Don't you need the same if (pm->show_pfn) check in is_swap_pte path, too?
(although I don't think that it can be exploited by row hammer attack ...)
Thanks,
Naoya Horiguchi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 5/5] pagemap: add mmap-exclusive bit for marking pages mapped only here
From: Naoya Horiguchi @ 2015-07-21 8:17 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Andrew Morton,
Kirill A. Shutemov, Mark Williamson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20150714153749.29844.81954.stgit@buzz>
On Tue, Jul 14, 2015 at 06:37:49PM +0300, Konstantin Khlebnikov wrote:
> This patch sets bit 56 in pagemap if this page is mapped only once.
> It allows to detect exclusively used pages without exposing PFN:
>
> present file exclusive state
> 0 0 0 non-present
> 1 1 0 file page mapped somewhere else
> 1 1 1 file page mapped only here
> 1 0 0 anon non-CoWed page (shared with parent/child)
> 1 0 1 anon CoWed page (or never forked)
>
> CoWed pages in (MAP_FILE | MAP_PRIVATE) areas are anon in this context.
>
> MMap-exclusive bit doesn't reflect potential page-sharing via swapcache:
> page could be mapped once but has several swap-ptes which point to it.
> Application could detect that by swap bit in pagemap entry and touch
> that pte via /proc/pid/mem to get real information.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org>
> Requested-by: Mark Williamson <mwilliamson-/4lU09Eg6ahx67MzidHQgQC/G2K4zDHf@public.gmane.org>
> Link: http://lkml.kernel.org/r/CAEVpBa+_RyACkhODZrRvQLs80iy0sqpdrd0AaP_-tgnX3Y9yNQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Reviewed-by: Naoya Horiguchi <n-horiguchi-PaJj6Psr51x8UrSeD/g0lQ@public.gmane.org>--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC ebeam PATCH 2/2] input: misc: New USB eBeam input driver
From: Oliver Neukum @ 2015-07-21 8:19 UTC (permalink / raw)
To: Yann Cantin
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w, jkosina-AlSwsSmVLrQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <1437426199-29866-3-git-send-email-yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org>
On Mon, 2015-07-20 at 23:03 +0200, Yann Cantin wrote:
> Signed-off-by: Yann Cantin <yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org>
> ---
> Documentation/ABI/testing/sysfs-driver-ebeam | 53 ++
> drivers/input/misc/Kconfig | 22 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/ebeam.c | 777 +++++++++++++++++++++++++++
> 4 files changed, 853 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam
> create mode 100644 drivers/input/misc/ebeam.c
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-ebeam b/Documentation/ABI/testing/sysfs-driver-ebeam
> new file mode 100644
> index 0000000..6873db5
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-ebeam
> @@ -0,0 +1,53 @@
> +What: /sys/class/input/inputXX/device/min_x
> + /sys/class/input/inputXX/device/min_y
> + /sys/class/input/inputXX/device/max_x
> + /sys/class/input/inputXX/device/max_y
> +Date: Jul 2015
> +Kernel Version: 4.1
> +Contact: yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org
> + linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description:
> + Reading from these files return the actually used range values of
> + the reported coordinates.
> + Writing to these files preset these range values.
> + See below for the calibration procedure.
> +
> +What: /sys/class/input/inputXX/device/h[1..9]
> +Date: Jul 2015
> +Kernel Version: 4.1
> +Contact: yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org
> + linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description:
> + Reading from these files return the 3x3 transformation matrix elements
> + actually used, in row-major.
> + Writing to these files preset these elements values.
> + See below for the calibration procedure.
> +
> +What: /sys/class/input/inputXX/device/calibrated
> +Date: Jul 2015
> +Kernel Version: 4.1
> +Contact: yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org
> + linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description:
> + Reading from this file :
> + - Return 0 if the driver is in "un-calibrated" mode : it actually send
> + raw coordinates in the device's internal coordinates system.
> + - Return 1 if the driver is in "calibrated" mode : it send computed coordinates
> + that (hopefully) matches the screen's coordinates system.
> + Writing 1 to this file enable the "calibrated" mode, 0 reset the driver in
> + "un-calibrated" mode.
> +
> +Calibration procedure :
> +
> +When loaded, the driver is in "un-calibrated" mode : it send device's raw coordinates
> +in the [0..65535]x[0..65535] range, the transformation matrix is the identity.
> +
> +A calibration program have to compute a homography transformation matrix that convert
> +the device's raw coordinates to the matching screen's ones.
> +It then write to the appropriate sysfs files the computed values, pre-setting the
> +driver's parameters : xy range, and the matrix's elements.
> +When all values are passed, it write 1 to the calibrated sysfs file to enable the "calibrated" mode.
> +
> +Warning : The parameters aren't used until 1 is writen to the calibrated sysfs file.
> +
> +Writing 0 to the calibrated sysfs file reset the driver in "un-calibrated" mode.
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index d4f0a81..22c46a4 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -103,6 +103,28 @@ config INPUT_E3X0_BUTTON
> To compile this driver as a module, choose M here: the
> module will be called e3x0_button.
>
> +config INPUT_EBEAM_USB
> + tristate "USB eBeam driver"
> + depends on USB_ARCH_HAS_HCD
> + select USB
> + help
> + Say Y here if you have a USB eBeam pointing device and want to
> + use it without any proprietary user space tools.
> +
> + Have a look at <http://ebeam.tuxfamily.org/> for
> + a usage description and the required user-space tools.
> +
> + Supported devices :
> + - Luidia eBeam Classic Projection and eBeam Edge Projection
> + - Nec NP01Wi1 & NP01Wi2 interactive solution
> +
> + Supposed working devices, need test, may lack functionality :
> + - Luidia eBeam Edge Whiteboard and eBeam Engage
> + - Hitachi Starboard FX-63, FX-77, FX-82, FX-77GII
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ebeam.
> +
> config INPUT_PCSPKR
> tristate "PC Speaker support"
> depends on PCSPKR_PLATFORM
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 53df07d..125f8a9 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
> obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063_onkey.o
> obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o
> obj-$(CONFIG_INPUT_E3X0_BUTTON) += e3x0-button.o
> +obj-$(CONFIG_INPUT_EBEAM_USB) += ebeam.o
> obj-$(CONFIG_INPUT_DRV260X_HAPTICS) += drv260x.o
> obj-$(CONFIG_INPUT_DRV2665_HAPTICS) += drv2665.o
> obj-$(CONFIG_INPUT_DRV2667_HAPTICS) += drv2667.o
> diff --git a/drivers/input/misc/ebeam.c b/drivers/input/misc/ebeam.c
> new file mode 100644
> index 0000000..79cac51
> --- /dev/null
> +++ b/drivers/input/misc/ebeam.c
> @@ -0,0 +1,777 @@
> +/******************************************************************************
> + *
> + * eBeam driver
> + *
> + * Copyright (C) 2012-2015 Yann Cantin (yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * based on
> + *
> + * usbtouchscreen.c by Daniel Ritz <daniel.ritz-OI3hZJvNYWs@public.gmane.org>
> + * aiptek.c (sysfs/settings) by Chris Atenasio <chris-v4AJ0sPprEc@public.gmane.org>
> + * Bryan W. Headley <bwheadley-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org>
> + *
> + *****************************************************************************/
> +
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/math64.h>
> +#include <linux/input.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/usb.h>
> +#include <linux/usb/input.h>
> +#include <asm/unaligned.h>
> +
> +#define DRIVER_AUTHOR "Yann Cantin <yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org>"
> +#define DRIVER_DESC "USB eBeam Driver"
> +
> +/* Common values for eBeam devices */
> +#define REPT_SIZE 8 /* packet size */
> +#define MIN_RAW_X 0 /* raw coordinates ranges */
> +#define MAX_RAW_X 0xFFFF
> +#define MIN_RAW_Y 0
> +#define MAX_RAW_Y 0xFFFF
> +
> +/* Electronics For Imaging, Inc */
> +#define USB_VENDOR_ID_EFI 0x2650
You are defining these IDs twice. That is not good.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] pagemap: update documentation
From: Naoya Horiguchi @ 2015-07-21 8:35 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: linux-mm@kvack.org, Andrew Morton, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20150716184742.8858.14639.stgit@buzz>
On Thu, Jul 16, 2015 at 09:47:42PM +0300, Konstantin Khlebnikov wrote:
> Notes about recent changes.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> ---
> Documentation/vm/pagemap.txt | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
> index 3cfbbb333ea1..aab39aa7dd8f 100644
> --- a/Documentation/vm/pagemap.txt
> +++ b/Documentation/vm/pagemap.txt
> @@ -16,12 +16,17 @@ There are three components to pagemap:
> * Bits 0-4 swap type if swapped
> * Bits 5-54 swap offset if swapped
> * Bit 55 pte is soft-dirty (see Documentation/vm/soft-dirty.txt)
> - * Bit 56 page exlusively mapped
> + * Bit 56 page exclusively mapped (since 4.2)
> * Bits 57-60 zero
> - * Bit 61 page is file-page or shared-anon
> + * Bit 61 page is file-page or shared-anon (since 3.5)
> * Bit 62 page swapped
> * Bit 63 page present
>
> + Since Linux 4.0 only users with the CAP_SYS_ADMIN capability can get PFNs:
> + for unprivileged users from 4.0 till 4.2 open fails with -EPERM, starting
I'm expecting that this patch will be merged before 4.2 is released, so if that's
right, stating "till 4.2" might be incorrect.
> + from from 4.2 PFN field is zeroed if user has no CAP_SYS_ADMIN capability.
"from" duplicates ...
Thanks,
Naoya Horiguchi
> + Reason: information about PFNs helps in exploiting Rowhammer vulnerability.
> +
> If the page is not present but in swap, then the PFN contains an
> encoding of the swap file number and the page's offset into the
> swap. Unmapped pages return a null PFN. This allows determining
> @@ -160,3 +165,8 @@ Other notes:
> Reading from any of the files will return -EINVAL if you are not starting
> the read on an 8-byte boundary (e.g., if you sought an odd number of bytes
> into the file), or if the size of the read is not a multiple of 8 bytes.
> +
> +Before Linux 3.11 pagemap bits 55-60 were used for "page-shift" (which is
> +always 12 at most architectures). Since Linux 3.11 their meaning changes
> +after first clear of soft-dirty bits. Since Linux 4.2 they are used for
> +flags unconditionally.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 4/5] pagemap: hide physical addresses from non-privileged users
From: Konstantin Khlebnikov @ 2015-07-21 8:39 UTC (permalink / raw)
To: Naoya Horiguchi
Cc: Konstantin Khlebnikov, linux-mm@kvack.org, Andrew Morton,
Kirill A. Shutemov, Mark Williamson, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org
In-Reply-To: <20150721081149.GC4490@hori1.linux.bs1.fc.nec.co.jp>
On Tue, Jul 21, 2015 at 11:11 AM, Naoya Horiguchi
<n-horiguchi@ah.jp.nec.com> wrote:
> On Tue, Jul 14, 2015 at 06:37:47PM +0300, Konstantin Khlebnikov wrote:
>> This patch makes pagemap readable for normal users and hides physical
>> addresses from them. For some use-cases PFN isn't required at all.
>>
>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>> Fixes: ab676b7d6fbf ("pagemap: do not leak physical addresses to non-privileged userspace")
>> Link: http://lkml.kernel.org/r/1425935472-17949-1-git-send-email-kirill@shutemov.name
>> ---
>> fs/proc/task_mmu.c | 25 ++++++++++++++-----------
>> 1 file changed, 14 insertions(+), 11 deletions(-)
>>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 040721fa405a..3a5d338ea219 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -937,6 +937,7 @@ typedef struct {
>> struct pagemapread {
>> int pos, len; /* units: PM_ENTRY_BYTES, not bytes */
>> pagemap_entry_t *buffer;
>> + bool show_pfn;
>> };
>>
>> #define PAGEMAP_WALK_SIZE (PMD_SIZE)
>> @@ -1013,7 +1014,8 @@ static pagemap_entry_t pte_to_pagemap_entry(struct pagemapread *pm,
>> struct page *page = NULL;
>>
>> if (pte_present(pte)) {
>> - frame = pte_pfn(pte);
>> + if (pm->show_pfn)
>> + frame = pte_pfn(pte);
>> flags |= PM_PRESENT;
>> page = vm_normal_page(vma, addr, pte);
>> if (pte_soft_dirty(pte))
>
> Don't you need the same if (pm->show_pfn) check in is_swap_pte path, too?
> (although I don't think that it can be exploited by row hammer attack ...)
Yeah, but I see no reason for that.
Probably except swap on ramdrive, but this too weird =)
>
> Thanks,
> Naoya Horiguchi
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a hrefmailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 3/5] pagemap: rework hugetlb and thp report
From: Konstantin Khlebnikov @ 2015-07-21 8:43 UTC (permalink / raw)
To: Naoya Horiguchi
Cc: Konstantin Khlebnikov, linux-mm@kvack.org, Andrew Morton,
Kirill A. Shutemov, Mark Williamson, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org
In-Reply-To: <20150721080046.GC2475@hori1.linux.bs1.fc.nec.co.jp>
On Tue, Jul 21, 2015 at 11:00 AM, Naoya Horiguchi
<n-horiguchi@ah.jp.nec.com> wrote:
> On Tue, Jul 14, 2015 at 06:37:39PM +0300, Konstantin Khlebnikov wrote:
>> This patch moves pmd dissection out of reporting loop: huge pages
>> are reported as bunch of normal pages with contiguous PFNs.
>>
>> Add missing "FILE" bit in hugetlb vmas.
>>
>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>
> With reflecting Kirill's comment about #ifdef, I'm OK for this patch.
That ifdef works most like documentation: "all thp magic happens here".
I'd like to keep it, if two redundant lines isn't a big deal.
>
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a hrefmailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH -mm v9 5/8] mmu-notifier: add clear_young callback
From: Vladimir Davydov @ 2015-07-21 8:51 UTC (permalink / raw)
To: Andres Lagar-Cavilla
Cc: Andrew Morton, Minchan Kim, Raghavendra K T, Johannes Weiner,
Michal Hocko, Greg Thelen, Michel Lespinasse, David Rientjes,
Pavel Emelyanov, Cyrill Gorcunov, Jonathan Corbet, linux-api,
linux-doc, linux-mm, cgroups, linux-kernel
In-Reply-To: <CAJu=L5_q=xWfANDBX2-Z3=uudof+ifKS56zEtAR372VqDWOj2Q@mail.gmail.com>
On Mon, Jul 20, 2015 at 11:34:21AM -0700, Andres Lagar-Cavilla wrote:
> On Sun, Jul 19, 2015 at 5:31 AM, Vladimir Davydov <vdavydov@parallels.com>
[...]
> > +static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
> > + struct mm_struct *mm,
> > + unsigned long start,
> > + unsigned long end)
> > +{
> > + struct kvm *kvm = mmu_notifier_to_kvm(mn);
> > + int young, idx;
> > +
> >
> If you need to cut out another version please add comments as to the two
> issues raised:
> - This doesn't proactively flush TLBs -- not obvious if it should.
> - This adversely affects performance in Pre_haswell Intel EPT.
Oops, I stopped reading your e-mail in reply to the previous version of
this patch as soon as I saw the Reviewed-by tag, so I missed your
request for the comment, sorry about that.
Here it goes (incremental):
---
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ff4173ce6924..e69a5cb99571 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -397,6 +397,19 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
idx = srcu_read_lock(&kvm->srcu);
spin_lock(&kvm->mmu_lock);
+ /*
+ * Even though we do not flush TLB, this will still adversely
+ * affect performance on pre-Haswell Intel EPT, where there is
+ * no EPT Access Bit to clear so that we have to tear down EPT
+ * tables instead. If we find this unacceptable, we can always
+ * add a parameter to kvm_age_hva so that it effectively doesn't
+ * do anything on clear_young.
+ *
+ * Also note that currently we never issue secondary TLB flushes
+ * from clear_young, leaving this job up to the regular system
+ * cadence. If we find this inaccurate, we might come up with a
+ * more sophisticated heuristic later.
+ */
young = kvm_age_hva(kvm, start, end);
spin_unlock(&kvm->mmu_lock);
srcu_read_unlock(&kvm->srcu, idx);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH v8 1/9] nvmem: Add a simple NVMEM framework for nvmem providers
From: Srinivas Kandagatla @ 2015-07-21 9:41 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, Greg Kroah-Hartman, Rob Herring, Mark Brown,
s.hauer, linux-api, linux-kernel, devicetree, linux-arm-msm, arnd,
pantelis.antoniou, mporter, stefan.wahren, wxt, Maxime Ripard
In-Reply-To: <55AD6412.9070205@codeaurora.org>
Thanks Stephen for review,
On 20/07/15 22:11, Stephen Boyd wrote:
> On 07/20/2015 07:43 AM, Srinivas Kandagatla wrote:
>> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
>> new file mode 100644
>> index 0000000..bde5528
>> --- /dev/null
>> +++ b/drivers/nvmem/core.c
>> @@ -0,0 +1,384 @@
>>
>> +
>> +static int nvmem_add_cells(struct nvmem_device *nvmem,
>> + const struct nvmem_config *cfg)
>> +{
>> + struct nvmem_cell **cells;
>> + const struct nvmem_cell_info *info = cfg->cells;
>> + int i, rval;
>> +
>> + cells = kzalloc(sizeof(*cells) * cfg->ncells, GFP_KERNEL);
>
> kcalloc?
Only reason for using kzalloc is to give the code more flexibility to
free any pointer in the array in case of errors.
>
>> + if (!cells)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < cfg->ncells; i++) {
>> + cells[i] = kzalloc(sizeof(**cells), GFP_KERNEL);
>> + if (!cells[i]) {
>> + rval = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + rval = nvmem_cell_info_to_nvmem_cell(nvmem, &info[i], cells[i]);
>> + if (IS_ERR_VALUE(rval)) {
>> + kfree(cells[i]);
>> + goto err;
>> + }
>> +
>> + nvmem_cell_add(cells[i]);
>> + }
>> +
>> + nvmem->ncells = cfg->ncells;
>> + /* remove tmp array */
>> + kfree(cells);
>> +
>> + return 0;
>> +err:
>> + while (--i)
>> + nvmem_cell_drop(cells[i]);
>> +
>> + return rval;
>> +}
>> +
>> +/**
>> + * nvmem_register() - Register a nvmem device for given nvmem_config.
>> + * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
>> + *
>> + * @config: nvmem device configuration with which nvmem device is
>> created.
>> + *
>> + * Return: Will be an ERR_PTR() on error or a valid pointer to
>> nvmem_device
>> + * on success.
>> + */
>> +
>
> Why the newline?
Yep, fixed it now.
>
>> +struct nvmem_device *nvmem_register(const struct nvmem_config *config)
>> +{
>> + struct nvmem_device *nvmem;
>> + struct device_node *np;
>> + struct regmap *rm;
>> + int rval;
>> +
>> + if (!config->dev)
>> + return ERR_PTR(-EINVAL);
>> +
>> + rm = dev_get_regmap(config->dev, NULL);
>> + if (!rm) {
>> + dev_err(config->dev, "Regmap not found\n");
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
>> + if (!nvmem)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + nvmem->id = ida_simple_get(&nvmem_ida, 0, 0, GFP_KERNEL);
>> + if (nvmem->id < 0) {
>> + kfree(nvmem);
>> + return ERR_PTR(nvmem->id);
>
> Oops, we already freed nvmem.
>
Oops, Fixed this one too.
>> + }
>> +
>> + nvmem->regmap = rm;
>> + nvmem->owner = config->owner;
>> + nvmem->stride = regmap_get_reg_stride(rm);
>> + nvmem->word_size = regmap_get_val_bytes(rm);
>> + nvmem->size = regmap_get_max_register(rm) + nvmem->stride;
>> + nvmem->dev.type = &nvmem_provider_type;
>> + nvmem->dev.bus = &nvmem_bus_type;
>> + nvmem->dev.parent = config->dev;
>> + np = config->dev->of_node;
>> + nvmem->dev.of_node = np;
>> + dev_set_name(&nvmem->dev, "%s%d",
>> + config->name ? : "nvmem", config->id);
>> +
>> + nvmem->read_only = np ? of_property_read_bool(np, "read-only") : 0;
>
> of_property_read_bool(NULL, ..) "does the right thing" and returns false
> already.
thanks, that should make this more simple.
>
>> +
>> + nvmem->read_only |= config->read_only;
>> +
>> + device_initialize(&nvmem->dev);
>> +
>> + dev_dbg(&nvmem->dev, "Registering nvmem device %s\n", config->name);
>> +
>> + rval = device_add(&nvmem->dev);
>> + if (rval) {
>> + ida_simple_remove(&nvmem_ida, nvmem->id);
>> + kfree(nvmem);
>> + return ERR_PTR(rval);
>> + }
>> +
>> + if (device_create_bin_file(&nvmem->dev,
>> + nvmem->read_only ? &bin_attr_ro_nvmem :
>> + &bin_attr_rw_nvmem))
>> + dev_warn(&nvmem->dev, "Failed to create sysfs binary file\n");
>
> Why can't we have device_add() add the binary file attribute too?
>
Yes we can set dev.groups directly before device_add, I did this change too.
>> +
>> + if (config->cells)
>> + nvmem_add_cells(nvmem, config);
>> +
>> + return nvmem;
>> +}
>> +EXPORT_SYMBOL_GPL(nvmem_register);
>> +
>> +/**
>> + * nvmem_unregister() - Unregister previously registered nvmem device
>> + *
>> + * @nvmem: Pointer to previously registered nvmem device.
>> + *
>> + * Return: Will be an negative on error or a zero on success.
>> + */
>> +int nvmem_unregister(struct nvmem_device *nvmem)
>> +{
>> + mutex_lock(&nvmem_mutex);
>> + if (nvmem->users) {
>> + mutex_unlock(&nvmem_mutex);
>> + return -EBUSY;
>> + }
>> + mutex_unlock(&nvmem_mutex);
>
> This lock doesn't seem to be doing anything in this patch? Perhaps it
> should be added in the second patch where consumers start making it useful?
Ok, make sense. I moved this too.
I have v9 ready will send it.
--srini
>
^ permalink raw reply
* Re: [PATCH v8 6/9] nvmem: qfprom: Add Qualcomm QFPROM support.
From: Srinivas Kandagatla @ 2015-07-21 9:42 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, Greg Kroah-Hartman, Rob Herring, Mark Brown,
s.hauer, linux-api, linux-kernel, devicetree, linux-arm-msm, arnd,
pantelis.antoniou, mporter, stefan.wahren, wxt
In-Reply-To: <55AD6636.4050302@codeaurora.org>
On 20/07/15 22:20, Stephen Boyd wrote:
> On 07/20/2015 07:44 AM, Srinivas Kandagatla wrote:
>> This patch adds QFPROM support driver which is used by other drivers
>> like thermal sensor and cpufreq.
>>
>> On MSM parts there are some efuses (called qfprom) these fuses store
>> things like calibration data, speed bins.. etc. Drivers like cpufreq,
>> thermal sensors would read out this data for configuring the driver.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> One comment below, otherwise
>
> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
>
Thanks for review, I will send v9 by removing slab.h.
>> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
>> new file mode 100644
>> index 0000000..ba5e2b4
>> --- /dev/null
>> +++ b/drivers/nvmem/qfprom.c
>> @@ -0,0 +1,86 @@
>> +/*
>> + * Copyright (C) 2015 Srinivas Kandagatla
>> <srinivas.kandagatla@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/device.h>
>> +#include <linux/module.h>
>> +#include <linux/nvmem-provider.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>
> This include is used?
>
^ permalink raw reply
* Re: [PATCH v8 1/9] nvmem: Add a simple NVMEM framework for nvmem providers
From: Stefan Wahren @ 2015-07-21 9:54 UTC (permalink / raw)
To: Srinivas Kandagatla, Stephen Boyd
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Rob Herring, Mark Brown,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
mporter-OWPKS81ov/FWk0Htik3J/w, wxt-TNX95d0MmH7DzftRWevZcw,
Maxime Ripard
In-Reply-To: <55AE13D8.6020301-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Srinivas,
Am 21.07.2015 um 11:41 schrieb Srinivas Kandagatla:
> Ok, make sense. I moved this too.
> I have v9 ready will send it.
>
> --srini
>
this is not a race. Please give the other (including me :-) ) some time
for testing and reviewing v8.
Thanks
Stefan
^ permalink raw reply
* [PATCH] ARM: ptrace: Implement PTRACE_SYSEMU
From: Kyle Huey @ 2015-07-21 10:04 UTC (permalink / raw)
To: Russell King, Will Deacon, Richard Weinberger, Mark Charlebois,
Jan-Simon Möller, Behan Webster, Vladimir Murzin, Kyle Huey,
Andy Lutomirski, Eric Paris, Kees Cook, moderated list:ARM PORT,
open list
Cc: linux-api
Implement PTRACE_SYSEMU support on ARM. Currently this ptrace call is
supported only on x86. This copies the x86 semantics for invoking ptrace hooks
(the syscall entry hook is invoked, the exit hook is not). This patch also
defines PTRACE_SYSEMU_SINGLESTEP because kernel/ptrace.c expects it to be
present if PTRACE_SYSEMU is present. Attempting to use PTRACE_SYSEMU_SINGLESTEP
will fail at runtime on ARM with EIO since there is no single stepping on ARM.
Signed-off-by: Kyle Huey <khuey@kylehuey.com>
---
arch/arm/include/asm/thread_info.h | 8 ++++++--
arch/arm/include/uapi/asm/ptrace.h | 32 +++++++++++++++++---------------
arch/arm/kernel/ptrace.c | 9 +++++++--
3 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index bd32ede..0e3ee19 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -137,7 +137,8 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user *,
/*
* thread information flags:
* TIF_SYSCALL_TRACE - syscall trace active
- * TIF_SYSCAL_AUDIT - syscall auditing active
+ * TIF_SYSCALL_AUDIT - syscall auditing active
+ * TIF_SYSCALL_EMU - syscall emulation active
* TIF_SIGPENDING - signal pending
* TIF_NEED_RESCHED - rescheduling necessary
* TIF_NOTIFY_RESUME - callback before returning to user
@@ -153,6 +154,7 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user *,
#define TIF_SYSCALL_TRACEPOINT 10
#define TIF_SECCOMP 11 /* seccomp syscall filtering active */
#define TIF_NOHZ 12 /* in adaptive nohz mode */
+#define TIF_SYSCALL_EMU 13
#define TIF_USING_IWMMXT 17
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
#define TIF_RESTORE_SIGMASK 20
@@ -165,11 +167,13 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user *,
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SYSCALL_TRACEPOINT (1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)
#define _TIF_USING_IWMMXT (1 << TIF_USING_IWMMXT)
/* Checks for any syscall work in entry-common.S */
#define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
- _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP)
+ _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \
+ _TIF_SYSCALL_EMU)
/*
* Change these and you break ASM code in entry-common.S
diff --git a/arch/arm/include/uapi/asm/ptrace.h b/arch/arm/include/uapi/asm/ptrace.h
index 5af0ed1..2c5e4d7 100644
--- a/arch/arm/include/uapi/asm/ptrace.h
+++ b/arch/arm/include/uapi/asm/ptrace.h
@@ -12,25 +12,27 @@
#include <asm/hwcap.h>
-#define PTRACE_GETREGS 12
-#define PTRACE_SETREGS 13
-#define PTRACE_GETFPREGS 14
-#define PTRACE_SETFPREGS 15
+#define PTRACE_GETREGS 12
+#define PTRACE_SETREGS 13
+#define PTRACE_GETFPREGS 14
+#define PTRACE_SETFPREGS 15
/* PTRACE_ATTACH is 16 */
/* PTRACE_DETACH is 17 */
-#define PTRACE_GETWMMXREGS 18
-#define PTRACE_SETWMMXREGS 19
+#define PTRACE_GETWMMXREGS 18
+#define PTRACE_SETWMMXREGS 19
/* 20 is unused */
-#define PTRACE_OLDSETOPTIONS 21
-#define PTRACE_GET_THREAD_AREA 22
-#define PTRACE_SET_SYSCALL 23
+#define PTRACE_OLDSETOPTIONS 21
+#define PTRACE_GET_THREAD_AREA 22
+#define PTRACE_SET_SYSCALL 23
/* PTRACE_SYSCALL is 24 */
-#define PTRACE_GETCRUNCHREGS 25
-#define PTRACE_SETCRUNCHREGS 26
-#define PTRACE_GETVFPREGS 27
-#define PTRACE_SETVFPREGS 28
-#define PTRACE_GETHBPREGS 29
-#define PTRACE_SETHBPREGS 30
+#define PTRACE_GETCRUNCHREGS 25
+#define PTRACE_SETCRUNCHREGS 26
+#define PTRACE_GETVFPREGS 27
+#define PTRACE_SETVFPREGS 28
+#define PTRACE_GETHBPREGS 29
+#define PTRACE_SETHBPREGS 30
+#define PTRACE_SYSEMU 31
+#define PTRACE_SYSEMU_SINGLESTEP 32
/*
* PSR bits
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index ef9119f..c84058c 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -930,6 +930,8 @@ static void tracehook_report_syscall(struct pt_regs *regs,
asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno)
{
+ int ret = 0;
+
current_thread_info()->syscall = scno;
/* Do the secure computing check first; failures should be fast. */
@@ -941,7 +943,10 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno)
secure_computing_strict(scno);
#endif
- if (test_thread_flag(TIF_SYSCALL_TRACE))
+ if (test_thread_flag(TIF_SYSCALL_EMU))
+ ret = -1;
+
+ if (ret || test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
scno = current_thread_info()->syscall;
@@ -952,7 +957,7 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno)
audit_syscall_entry(scno, regs->ARM_r0, regs->ARM_r1, regs->ARM_r2,
regs->ARM_r3);
- return scno;
+ return ret ?: scno;
}
asmlinkage void syscall_trace_exit(struct pt_regs *regs)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v8 1/9] nvmem: Add a simple NVMEM framework for nvmem providers
From: Srinivas Kandagatla @ 2015-07-21 10:31 UTC (permalink / raw)
To: Stefan Wahren, Stephen Boyd
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Rob Herring, Mark Brown,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
mporter-OWPKS81ov/FWk0Htik3J/w, wxt-TNX95d0MmH7DzftRWevZcw,
Maxime Ripard
In-Reply-To: <55AE16BB.9090201-eS4NqCHxEME@public.gmane.org>
Hi Stefan,
On 21/07/15 10:54, Stefan Wahren wrote:
> Hi Srinivas,
>
> Am 21.07.2015 um 11:41 schrieb Srinivas Kandagatla:
>> >Ok, make sense. I moved this too.
>> >I have v9 ready will send it.
>> >
>> >--srini
>> >
> this is not a race. Please give the other (including me:-) ) some time
> for testing and reviewing v8.
Ofcourse, I did not mean it now or today! Am actually going to wait till
the end of this week before I post v9.
--srini
>
> Thanks
> Stefan
>
^ permalink raw reply
* Re: [RFC ebeam PATCH 2/2] input: misc: New USB eBeam input driver
From: Yann Cantin @ 2015-07-21 12:18 UTC (permalink / raw)
To: Greg KH
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w, jkosina-AlSwsSmVLrQ
In-Reply-To: <20150720215956.GA21796-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Hi,
Le 20/07/2015 23:59, Greg KH a écrit :
> On Mon, Jul 20, 2015 at 11:03:19PM +0200, Yann Cantin wrote:
>> diff --git a/Documentation/ABI/testing/sysfs-driver-ebeam b/Documentation/ABI/testing/sysfs-driver-ebeam
>> +++ b/Documentation/ABI/testing/sysfs-driver-ebeam
>> @@ -0,0 +1,53 @@
>> +What: /sys/class/input/inputXX/device/min_x
>> + /sys/class/input/inputXX/device/min_y
>> + /sys/class/input/inputXX/device/max_x
>> + /sys/class/input/inputXX/device/max_y
>> +What: /sys/class/input/inputXX/device/h[1..9]
>> +What: /sys/class/input/inputXX/device/calibrated
>
>
> What tool(s) use these sysfs files? Don't we already have "normal"
> events for these types of things such that we don't have to make up new
> sysfs files for these?
The ebeam_calibrator tool is there : http://ebeam.tuxfamily.org.
I agree this can be a problem : this driver is totally useless without a
userspace dedicated calibration tool.
By nature these device's coordinate system can't be mapped to screen via
trivial transformations, such as scaling, flipping and rotating, hence the
special calibration and mapping procedures. I choose to use an homography
transformation as it is more robust and faster than linear interpolation
in this case. And anyway, it requires 9 calibration data and xy range
parameters.
I haven't found any existing tools performing that : xinput_calibrator
(witch ebeam_calibrator is based on) and other touchscreen calibration
tools can't do much more than trivial transformations.
>> +static DEVICE_ATTR(MM, S_IRUSR | S_IRGRP | S_IWUSR | S_IWGRP, \
>> + ebeam_##MM##_get, \
>> + ebeam_##MM##_set)
>
> DEVICE_ATTR_RW()?
Ok, will do.
>> + /* sysfs setup */
>> + err = sysfs_create_group(&intf->dev.kobj, &ebeam_attr_group);
>
> Ick, you just added the sysfs files to the USB device, not your input
> device, are you sure you tested this?
Yes, "run fine since 3.3.6, both x86_32 and 64.".
thanks,
--
Yann Cantin
A4FEB47F
--
^ permalink raw reply
* Re: [RFC ebeam PATCH 2/2] input: misc: New USB eBeam input driver
From: Yann Cantin @ 2015-07-21 12:38 UTC (permalink / raw)
To: Oliver Neukum
Cc: linux-input, linux-usb, linux-kernel, linux-api, dmitry.torokhov,
jkosina, gregkh
In-Reply-To: <1437466763.3823.1.camel@suse.com>
Hi,
Le 21/07/2015 10:19, Oliver Neukum a écrit :
> On Mon, 2015-07-20 at 23:03 +0200, Yann Cantin wrote:
>> diff --git a/drivers/input/misc/ebeam.c b/drivers/input/misc/ebeam.c
>> new file mode 100644
>> index 0000000..79cac51
>> --- /dev/null
>> +++ b/drivers/input/misc/ebeam.c
>> +/* Electronics For Imaging, Inc */
>> +#define USB_VENDOR_ID_EFI 0x2650
>
> You are defining these IDs twice. That is not good.
Is it okay to do this :
#if !defined(CONFIG_INPUT_EBEAM_USB)
#define USB_VENDOR_ID_EFI 0x2650
#...
#endif
so that the driver can also be build outside the kernel tree ?
thanks,
--
Yann Cantin
A4FEB47F
--
^ permalink raw reply
* Re: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)
From: Mathieu Desnoyers @ 2015-07-21 12:58 UTC (permalink / raw)
To: Ondřej Bílka
Cc: Linus Torvalds, Andy Lutomirski, Ben Maurer, Ingo Molnar,
libc-alpha, Andrew Morton, linux-api, rostedt, Paul E. McKenney,
Florian Weimer, Josh Triplett, Lai Jiangshan, Paul Turner,
Andrew Hunter, Peter Zijlstra
In-Reply-To: <20150721073053.GA14716@domone>
----- On Jul 21, 2015, at 3:30 AM, Ondřej Bílka neleai@seznam.cz wrote:
> On Tue, Jul 21, 2015 at 12:25:00AM +0000, Mathieu Desnoyers wrote:
>> >> Does it solve the Wine problem? If Wine uses gs for something and
>> >> calls a function that does this, Wine still goes boom, right?
>> >
>> > So the advantage of just making a global segment descriptor available
>> > is that it's not *that* expensive to just save/restore segments. So
>> > either wine could do it, or any library users would do it.
>> >
>> > But anyway, I'm not sure this is a good idea. The advantage of it is
>> > that the kernel support really is _very_ minimal.
>>
>> Considering that we'd at least also want this feature on ARM and
>> PowerPC 32/64, and that the gs segment selector approach clashes with
>> existing apps (wine), I'm not sure that implementing a gs segment
>> selector based approach to cpu number caching would lead to an overall
>> decrease in complexity if it leads to performance similar to those of
>> portable approaches.
>>
>> I'm perfectly fine with architecture-specific tweaks that lead to
>> fast-path speedups, but if we have to bite the bullet and implement
>> an approach based on TLS and registering a memory area at thread start
>> through a system call on other architectures anyway, it might end up
>> being less complex to add a new system call on x86 too, especially if
>> fast path overhead is similar.
>>
>> But I'm inclined to think that some aspect of the question eludes me,
>> especially given the amount of interest generated by the gs-segment
>> selector approach. What am I missing ?
>>
> As I wrote before you don't have to bite bullet as I said before. It
> suffices to create 128k element array with cpu for each tid, make that
> mmapable file and userspace could get cpu with nearly same performance
> without hacks.
I don't see how this would be acceptable on memory-constrained embedded
systems. They have multiple cores, and performance requirements, so
having a fast getcpu would be useful there (e.g. telecom industry),
but they clearly cannot afford a 512kB table per process just for that.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [RFC ebeam PATCH 2/2] input: misc: New USB eBeam input driver
From: Yann Cantin @ 2015-07-21 13:54 UTC (permalink / raw)
To: Greg KH, Dmitry Torokhov
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, jkosina-AlSwsSmVLrQ
In-Reply-To: <20150720224033.GA23884-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Hi,
Le 21/07/2015 00:40, Greg KH a écrit :
> On Mon, Jul 20, 2015 at 03:26:40PM -0700, Dmitry Torokhov wrote:
>> On Mon, Jul 20, 2015 at 02:59:56PM -0700, Greg KH wrote:
>>> On Mon, Jul 20, 2015 at 11:03:19PM +0200, Yann Cantin wrote:
>>>> Signed-off-by: Yann Cantin <yann.cantin-QFKgK+z4sOrR7s880joybQ@public.gmane.org>
>>>
>>>> +
>>>> + /* sysfs setup */
>>>> + err = sysfs_create_group(&intf->dev.kobj, &ebeam_attr_group);
>>>
>>> Ick, you just added the sysfs files to the USB device, not your input
>>> device, are you sure you tested this?
>>>
>>> And there should be a race-free way to add an attribute group to an
>>> input device, as this is, you are adding them to the device _after_ it
>>> is created, so userspace will not see them at creation time, causing a
>>> race.
>>
>> No, there are no driver-specific attributed on input devices themselves,
>> they belong to the actual hardware devices. The input devices only
>> export standard attributes applicable to every and all input devices
>> in the system.
>
> Then the Documentation in this patch better be fixed up, as it points to
> the input device as having these sysfs files :)
>
> But as these are input device attributes, and not USB device interface
> attributes, putting them on the USB interface doesn't make much sense,
To sum up : these attributes are USB device's not input's, only indirectly
accessed via inputXX/device/, and they only modify the driver's behavior.
So, it make sense to correct the documentation to point at
/sys/bus/usb/drivers/ebeam/X-X:1.0/. Right ?
thanks,
--
Yann Cantin
A4FEB47F
--
^ permalink raw reply
* Re: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)
From: Ondřej Bílka @ 2015-07-21 15:16 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Linus Torvalds, Andy Lutomirski, Ben Maurer, Ingo Molnar,
libc-alpha, Andrew Morton, linux-api, rostedt, Paul E. McKenney,
Florian Weimer, Josh Triplett, Lai Jiangshan, Paul Turner,
Andrew Hunter, Peter Zijlstra
In-Reply-To: <894137397.137.1437483493715.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
On Tue, Jul 21, 2015 at 12:58:13PM +0000, Mathieu Desnoyers wrote:
> ----- On Jul 21, 2015, at 3:30 AM, Ondřej Bílka neleai@seznam.cz wrote:
>
> > On Tue, Jul 21, 2015 at 12:25:00AM +0000, Mathieu Desnoyers wrote:
> >> >> Does it solve the Wine problem? If Wine uses gs for something and
> >> >> calls a function that does this, Wine still goes boom, right?
> >> >
> >> > So the advantage of just making a global segment descriptor available
> >> > is that it's not *that* expensive to just save/restore segments. So
> >> > either wine could do it, or any library users would do it.
> >> >
> >> > But anyway, I'm not sure this is a good idea. The advantage of it is
> >> > that the kernel support really is _very_ minimal.
> >>
> >> Considering that we'd at least also want this feature on ARM and
> >> PowerPC 32/64, and that the gs segment selector approach clashes with
> >> existing apps (wine), I'm not sure that implementing a gs segment
> >> selector based approach to cpu number caching would lead to an overall
> >> decrease in complexity if it leads to performance similar to those of
> >> portable approaches.
> >>
> >> I'm perfectly fine with architecture-specific tweaks that lead to
> >> fast-path speedups, but if we have to bite the bullet and implement
> >> an approach based on TLS and registering a memory area at thread start
> >> through a system call on other architectures anyway, it might end up
> >> being less complex to add a new system call on x86 too, especially if
> >> fast path overhead is similar.
> >>
> >> But I'm inclined to think that some aspect of the question eludes me,
> >> especially given the amount of interest generated by the gs-segment
> >> selector approach. What am I missing ?
> >>
> > As I wrote before you don't have to bite bullet as I said before. It
> > suffices to create 128k element array with cpu for each tid, make that
> > mmapable file and userspace could get cpu with nearly same performance
> > without hacks.
>
> I don't see how this would be acceptable on memory-constrained embedded
> systems. They have multiple cores, and performance requirements, so
> having a fast getcpu would be useful there (e.g. telecom industry),
> but they clearly cannot afford a 512kB table per process just for that.
>
Which just means that you need more complicated api and implementation
for that but idea stays same. You would need syscalls
register/deregister_cpuid_idx that would give you index used instead
tid. A kernel would need to handle that many ids could be registered for
each thread and resize mmaped file in syscalls.
^ permalink raw reply
* Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
From: Vlastimil Babka @ 2015-07-21 15:35 UTC (permalink / raw)
To: Eric B Munson, Jonathan Corbet
Cc: Andrew Morton, Michal Hocko, linux-alpha, linux-kernel,
linux-mips, linux-parisc, linuxppc-dev, sparclinux, linux-xtensa,
linux-mm, linux-arch, linux-api
In-Reply-To: <20150710161948.GF4669@akamai.com>
On 07/10/2015 06:19 PM, Eric B Munson wrote:
> On Fri, 10 Jul 2015, Jonathan Corbet wrote:
>
>> On Thu, 9 Jul 2015 14:46:35 -0400
>> Eric B Munson <emunson@akamai.com> wrote:
>>
>>>> One other question...if I call mlock2(MLOCK_ONFAULT) on a range that
>>>> already has resident pages, I believe that those pages will not be locked
>>>> until they are reclaimed and faulted back in again, right? I suspect that
>>>> could be surprising to users.
>>>
>>> That is the case. I am looking into what it would take to find only the
>>> present pages in a range and lock them, if that is the behavior that is
>>> preferred I can include it in the updated series.
>>
>> For whatever my $0.02 is worth, I think that should be done. Otherwise
>> the mlock2() interface is essentially nondeterministic; you'll never
>> really know if a specific page is locked or not.
>>
>> Thanks,
>>
>> jon
>
> Okay, I likely won't have the new set out today then. This change is
> more invasive. IIUC, I need an equivalent to __get_user_page() skips
> pages which are not present instead of faulting in and the call chain to
> get to it. Unless there is an easier way that I am missing.
IIRC having page PageMlocked and put on unevictable list isn't necessary
to prevent it from being reclaimed. It's just to prevent it from being
scanned for reclaim in the first place. When attempting to unmap the
page, vma flags are still checked, see the code in try_to_unmap_one().
You should probably extend the checks to your new VM_ flag as it is done
for VM_LOCKED and then you shouldn't need to walk the pages to mlock
them (although it would probably still be better for the accounting
accuracy).
> Eric
>
^ permalink raw reply
* Re: [PATCH V3 4/5] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
From: Eric B Munson @ 2015-07-21 15:37 UTC (permalink / raw)
To: Chris Metcalf
Cc: Paul Gortmaker, Andrew Morton, Michal Hocko, Vlastimil Babka,
LKML, linux-mm, linux-arch, linux-api, linux-next@vger.kernel.org
In-Reply-To: <55AD5CB9.4090400@ezchip.com>
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
On Mon, 20 Jul 2015, Chris Metcalf wrote:
> On 07/18/2015 03:11 PM, Paul Gortmaker wrote:
> >On Tue, Jul 7, 2015 at 1:03 PM, Eric B Munson<emunson@akamai.com> wrote:
> >>>The cost of faulting in all memory to be locked can be very high when
> >>>working with large mappings. If only portions of the mapping will be
> >>>used this can incur a high penalty for locking.
> >>>
> >>>Now that we have the new VMA flag for the locked but not present state,
> >>>expose it as an mmap option like MAP_LOCKED -> VM_LOCKED.
> >An automatic bisection on arch/tile leads to this commit:
> >
> >5a5656f2c9b61c74c15f9ef3fa2e6513b6c237bb is the first bad commit
> >commit 5a5656f2c9b61c74c15f9ef3fa2e6513b6c237bb
> >Author: Eric B Munson<emunson@akamai.com>
> >Date: Thu Jul 16 10:09:22 2015 +1000
> >
> > mm: mmap: add mmap flag to request VM_LOCKONFAULT
>
> Eric, I'm happy to help with figuring out the tile issues.
Thanks for the offer, I think I have is sorted in V4 (which I am
checking one last time before I post).
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v8 2/9] nvmem: Add a simple NVMEM framework for consumers
From: Stefan Wahren @ 2015-07-21 16:25 UTC (permalink / raw)
To: Srinivas Kandagatla, Greg Kroah-Hartman, linux-arm-kernel
Cc: wxt, linux-api, Rob Herring, sboyd, arnd, s.hauer, linux-kernel,
mporter, linux-arm-msm, Maxime Ripard, pantelis.antoniou,
Mark Brown, devicetree
In-Reply-To: <1437403403-4180-1-git-send-email-srinivas.kandagatla@linaro.org>
Hi Srinivas,
> Srinivas Kandagatla <srinivas.kandagatla@linaro.org> hat am 20. Juli 2015 um
> 16:43 geschrieben:
>
>
> This patch adds just consumers part of the framework just to enable easy
> review.
>
> Up until now, nvmem drivers were stored in drivers/misc, where they all
> had to duplicate pretty much the same code to register a sysfs file,
> allow in-kernel users to access the content of the devices they were
> driving, etc.
>
> This was also a problem as far as other in-kernel users were involved,
> since the solutions used were pretty much different from on driver to
> another, there was a rather big abstraction leak.
>
> This introduction of this framework aims at solving this. It also
> introduces DT representation for consumer devices to go get the data they
> require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from
> the nvmems.
>
> Having regmap interface to this framework would give much better
> abstraction for nvmems on different buses.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> [Maxime Ripard: intial version of the framework]
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> drivers/nvmem/core.c | 415 +++++++++++++++++++++++++++++++++++++++++
> include/linux/nvmem-consumer.h | 61 ++++++
> 2 files changed, 476 insertions(+)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index bde5528..de14c36 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> [...]
> +struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> + const char *name)
> +{
> + struct device_node *cell_np, *nvmem_np;
> + struct nvmem_cell *cell;
> + struct nvmem_device *nvmem;
> + const __be32 *addr;
> + int rval, len, index;
> +
> + index = of_property_match_string(np, "nvmem-cell-names", name);
> +
> + cell_np = of_parse_phandle(np, "nvmem-cells", index);
> + if (!cell_np)
> + return ERR_PTR(-EINVAL);
> +
> + nvmem_np = of_get_next_parent(cell_np);
> + if (!nvmem_np)
> + return ERR_PTR(-EINVAL);
> +
> + nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
> + if (IS_ERR(nvmem))
> + return ERR_CAST(nvmem);
> +
> + addr = of_get_property(cell_np, "reg", &len);
> + if (!addr || (len < 2 * sizeof(int))) {
I'm not sure, but shouldn't be sizeof(u32) more portable?
> [...]
> +
> + addr = of_get_property(cell_np, "bits", &len);
> + if (addr && len == (2 * sizeof(int))) {
dito
Regards
Stefan
^ permalink raw reply
* Re: [PATCH v8 8/9] nvmem: sunxi: Move the SID driver to the nvmem framework
From: Stefan Wahren @ 2015-07-21 16:38 UTC (permalink / raw)
To: Srinivas Kandagatla, Greg Kroah-Hartman,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: wxt-TNX95d0MmH7DzftRWevZcw, linux-api-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, sboyd-sgV2jX0FEOL9JmXXK+q4OQ, arnd-r2nGTMty4D4,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mporter-OWPKS81ov/FWk0Htik3J/w,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Maxime Ripard,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w, Mark Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1437403462-4432-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Srinivas,
> Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> hat am 20. Juli 2015 um
> 16:44 geschrieben:
>
>
> From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> Now that we have the nvmem framework, we can consolidate the common
> driver code. Move the driver to the framework, and hopefully, it will
> fix the sysfs file creation race.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> [srinivas.kandagatla: Moved to regmap based EEPROM framework]
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 ---
> .../bindings/misc/allwinner,sunxi-sid.txt | 17 ---
> .../bindings/nvmem/allwinner,sunxi-sid.txt | 21 +++
> drivers/misc/eeprom/Kconfig | 13 --
> drivers/misc/eeprom/Makefile | 1 -
> drivers/misc/eeprom/sunxi_sid.c | 156 --------------------
> drivers/nvmem/Kconfig | 11 ++
> drivers/nvmem/Makefile | 2 +
> drivers/nvmem/sunxi_sid.c | 159 +++++++++++++++++++++
> 9 files changed, 193 insertions(+), 209 deletions(-)
> delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
> delete mode 100644
> Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
> create mode 100644
> Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
> create mode 100644 drivers/nvmem/sunxi_sid.c
>
> [...]
> -static int sunxi_sid_probe(struct platform_device *pdev)
> -{
> - struct sunxi_sid_data *sid_data;
> - struct resource *res;
> - const struct of_device_id *of_dev_id;
> - u8 *entropy;
> - unsigned int i;
> -
> - sid_data = devm_kzalloc(&pdev->dev, sizeof(struct sunxi_sid_data),
> - GFP_KERNEL);
> - if (!sid_data)
> - return -ENOMEM;
> -
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - sid_data->reg_base = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(sid_data->reg_base))
> - return PTR_ERR(sid_data->reg_base);
> -
> - of_dev_id = of_match_device(sunxi_sid_of_match, &pdev->dev);
> - if (!of_dev_id)
> - return -ENODEV;
> - sid_data->keysize = (int)of_dev_id->data;
> -
> - platform_set_drvdata(pdev, sid_data);
> -
> - sid_bin_attr.size = sid_data->keysize;
> - if (device_create_bin_file(&pdev->dev, &sid_bin_attr))
> - return -ENODEV;
> -
> - entropy = kzalloc(sizeof(u8) * sid_data->keysize, GFP_KERNEL);
> - for (i = 0; i < sid_data->keysize; i++)
> - entropy[i] = sunxi_sid_read_byte(sid_data, i);
> - add_device_randomness(entropy, sid_data->keysize);
> - kfree(entropy);
> -
in case of porting a driver to a new framework, i would expect the same
features.
The ported driver do not add the Security ID to the device randomness.
What's the reason for this difference?
Regards
Stefan
^ permalink raw reply
* Re: [PATCH v2 3/3] console_codes.4: Add CSI sequence for cursor blink interval
From: Michael Kerrisk (man-pages) @ 2015-07-21 16:55 UTC (permalink / raw)
To: Scot Doyle
Cc: lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Linux API, linux-man,
Pavel Machek
In-Reply-To: <alpine.DEB.2.11.1507051724240.1696@local>
Hello Scot,
On 5 July 2015 at 19:41, Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org> wrote:
> On Thu, 26 Mar 2015, Scot Doyle wrote:
>> Add a Console Private CSI sequence to specify the current console's
>> cursor blink interval. The interval is specified as a number of
>> milliseconds until the next cursor display state toggle, from 50 to
>> 65535.
>>
>> Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
I've applied this, adding Pavel's Acked-by.
I also added some text to note that this appeared in Linux 4.2. Okay?
Cheers,
Michael
>> ---
>> man4/console_codes.4 | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/man4/console_codes.4 b/man4/console_codes.4
>> index 34f7535..7d05076 100644
>> --- a/man4/console_codes.4
>> +++ b/man4/console_codes.4
>> @@ -377,6 +377,7 @@ ESC [ 15 ] T{
>> Bring the previous console to the front
>> (since Linux 2.6.0).
>> T}
>> +ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds.
>> .TE
>> .SS Character sets
>> The kernel knows about 4 translations of bytes into console-screen
>> --
>> 2.1.0
>>
>
> Hi Michael,
>
> Will you apply now that Linus has pulled the rest?
> (see bd63364caa8df38bad2b25b11b2a1b849475cce5)
>
> Thank you,
> Scot
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)
From: Mathieu Desnoyers @ 2015-07-21 17:45 UTC (permalink / raw)
To: Ondřej Bílka
Cc: Linus Torvalds, Andy Lutomirski, Ben Maurer, Ingo Molnar,
libc-alpha, Andrew Morton, linux-api, rostedt, Paul E. McKenney,
Florian Weimer, Josh Triplett, Lai Jiangshan, Paul Turner,
Andrew Hunter, Peter Zijlstra
In-Reply-To: <20150721151613.GA12856@domone>
----- On Jul 21, 2015, at 11:16 AM, Ondřej Bílka neleai@seznam.cz wrote:
> On Tue, Jul 21, 2015 at 12:58:13PM +0000, Mathieu Desnoyers wrote:
>> ----- On Jul 21, 2015, at 3:30 AM, Ondřej Bílka neleai@seznam.cz wrote:
>>
>> > On Tue, Jul 21, 2015 at 12:25:00AM +0000, Mathieu Desnoyers wrote:
>> >> >> Does it solve the Wine problem? If Wine uses gs for something and
>> >> >> calls a function that does this, Wine still goes boom, right?
>> >> >
>> >> > So the advantage of just making a global segment descriptor available
>> >> > is that it's not *that* expensive to just save/restore segments. So
>> >> > either wine could do it, or any library users would do it.
>> >> >
>> >> > But anyway, I'm not sure this is a good idea. The advantage of it is
>> >> > that the kernel support really is _very_ minimal.
>> >>
>> >> Considering that we'd at least also want this feature on ARM and
>> >> PowerPC 32/64, and that the gs segment selector approach clashes with
>> >> existing apps (wine), I'm not sure that implementing a gs segment
>> >> selector based approach to cpu number caching would lead to an overall
>> >> decrease in complexity if it leads to performance similar to those of
>> >> portable approaches.
>> >>
>> >> I'm perfectly fine with architecture-specific tweaks that lead to
>> >> fast-path speedups, but if we have to bite the bullet and implement
>> >> an approach based on TLS and registering a memory area at thread start
>> >> through a system call on other architectures anyway, it might end up
>> >> being less complex to add a new system call on x86 too, especially if
>> >> fast path overhead is similar.
>> >>
>> >> But I'm inclined to think that some aspect of the question eludes me,
>> >> especially given the amount of interest generated by the gs-segment
>> >> selector approach. What am I missing ?
>> >>
>> > As I wrote before you don't have to bite bullet as I said before. It
>> > suffices to create 128k element array with cpu for each tid, make that
>> > mmapable file and userspace could get cpu with nearly same performance
>> > without hacks.
>>
>> I don't see how this would be acceptable on memory-constrained embedded
>> systems. They have multiple cores, and performance requirements, so
>> having a fast getcpu would be useful there (e.g. telecom industry),
>> but they clearly cannot afford a 512kB table per process just for that.
>>
> Which just means that you need more complicated api and implementation
> for that but idea stays same. You would need syscalls
> register/deregister_cpuid_idx that would give you index used instead
> tid. A kernel would need to handle that many ids could be registered for
> each thread and resize mmaped file in syscalls.
I feel we're talking past each other here. What I propose is to implement
a system call that registers a TLS area. It can be invoked at thread start.
The kernel can then keep the current CPU number within that registered
area up-to-date. This system call does not care how the TLS is implemented
underneath.
My understanding is that you are suggesting a way to speed up TLS accesses
by creating a table indexed by TID. Although it might lead to interesting
speed ups useful when reading the TLS, I don't see how you proposal is
useful in addressing the problem of caching the current CPU number (other
than possibly speeding up TLS accesses).
Or am I missing something fundamental to your proposal ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox