Re: [PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

On Fri, Mar 16, 2018 at 02:13:42PM -0400, Waiman Long wrote: > When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table > entry, any update from the userspace will be clamped to the given > range without error if either the proc_dointvec_minmax() or the > proc_douintvec_minmax() handlers is

Re: [PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

On Fri, Mar 16, 2018 at 02:13:43PM -0400, Waiman Long wrote: > Checking code is added to provide the following additional > ctl_table.flags checks: > > 1) No unknown flag is allowed. > 2) Minimum of a range cannot be larger than the maximum value. > 3) The signed and unsigned flags are

Re: [PATCH v4 6/6] arm64: dts: sdm845: Add I2C controller support

Hi, On Wed, Mar 14, 2018 at 4:58 PM, Karthikeyan Ramasubramanian wrote: > Add I2C master controller support for a built-in test I2C slave. > > Signed-off-by: Karthikeyan Ramasubramanian > --- > arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 19

Re: [PATCH 1/1] Documentation: clk: enable lock is not held for clk_is_enabled API

Quoting Dong Aisheng (2018-01-19 05:37:15) > The core does not need to hold enable lock for clk_is_enabled API. > Update the doc to reflect it. > > Cc: Jonathan Corbet > Cc: Stephen Boyd > Suggested-by: Stephen Boyd > Signed-off-by:

Re: [PATCH v12 22/22] selftests/vm: Fix deadlock in protection_keys.c

On 02/21/2018 05:55 PM, Ram Pai wrote: > From: Thiago Jung Bauermann > > The sig_chld() handler calls dprintf2() taking care of setting > dprint_in_signal so that sigsafe_printf() won't call printf(). > Unfortunately, this precaution is is negated by dprintf_level(),

Re: [PATCH v12 21/22] selftests/vm: sub-page allocator

On 02/21/2018 05:55 PM, Ram Pai wrote: ... > @@ -888,6 +917,7 @@ void setup_hugetlbfs(void) > void *(*pkey_malloc[])(long size, int prot, u16 pkey) = { > > malloc_pkey_with_mprotect, > + malloc_pkey_with_mprotect_subpage, > malloc_pkey_anon_huge, > malloc_pkey_hugetlb >

Re: [PATCH v12 20/22] selftests/vm: testcases must restore pkey-permissions

On 02/21/2018 05:55 PM, Ram Pai wrote: > Generally the signal handler restores the state of the pkey register > before returning. However there are times when the read/write operation > can legitamely fail without invoking the signal handler. Eg: A > sys_read() operaton to a write-protected page

Re: [PATCH v12 19/22] selftests/vm: detect write violation on a mapped access-denied-key page

On 02/21/2018 05:55 PM, Ram Pai wrote: > detect write-violation on a page to which access-disabled > key is associated much after the page is mapped. Acked-by: Dave Hansen -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to

Re: [PATCH v12 18/22] selftests/vm: associate key on a mapped page and detect write violation

On 02/21/2018 05:55 PM, Ram Pai wrote: > detect write-violation on a page to which write-disabled > key is associated much after the page is mapped. The more tests the merrier. Acked-by: Dave Hansen -- To unsubscribe from this list: send the line "unsubscribe linux-doc"

Re: [PATCH v12 17/22] selftests/vm: associate key on a mapped page and detect access violation

On 02/21/2018 05:55 PM, Ram Pai wrote: > detect access-violation on a page to which access-disabled > key is associated much after the page is mapped. Looks fine to me. Did this actually find a bug for you? Acked-by: Dave Hansen -- To unsubscribe from this list: send

Re: [PATCH v12 16/22] selftests/vm: fix an assertion in test_pkey_alloc_exhaust()

On 02/21/2018 05:55 PM, Ram Pai wrote: > +static inline int arch_reserved_keys(void) > +{ > +#if defined(__i386__) || defined(__x86_64__) /* arch */ > + return NR_RESERVED_PKEYS; > +#elif __powerpc64__ /* arch */ > + if (sysconf(_SC_PAGESIZE) == 4096) > + return

Re: [PATCH v12 15/22] selftests/vm: powerpc implementation to check support for pkey

On 02/21/2018 05:55 PM, Ram Pai wrote: > #define PAGE_SIZE (0x1UL << 16) > -static inline int cpu_has_pku(void) > +static inline bool is_pkey_supported(void) > { > - return 1; > + /* > + * No simple way to determine this. > + * lets try allocating a key and see if it succeeds.

Re: [PATCH v12 13/22] selftests/vm: powerpc implementation for generic abstraction

On 02/21/2018 05:55 PM, Ram Pai wrote: > static inline u32 pkey_to_shift(int pkey) > { > +#if defined(__i386__) || defined(__x86_64__) /* arch */ > return pkey * PKEY_BITS_PER_PKEY; > +#elif __powerpc64__ /* arch */ > + return (NR_PKEYS - pkey - 1) * PKEY_BITS_PER_PKEY; > +#endif /*

Re: [PATCH v12 12/22] selftests/vm: generic cleanup

On 02/21/2018 05:55 PM, Ram Pai wrote: > cleanup the code to satisfy coding styles. > > cc: Dave Hansen > cc: Florian Weimer > Signed-off-by: Ram Pai > --- > tools/testing/selftests/vm/protection_keys.c | 81 >

Re: [PATCH v12 11/22] selftests/vm: pkey register should match shadow pkey

On 02/21/2018 05:55 PM, Ram Pai wrote: > expected_pkey_fault() is comparing the contents of pkey > register with 0. This may not be true all the time. There > could be bits set by default by the architecture > which can never be changed. Hence compare the value against > shadow pkey register,

Re: [PATCH v12 10/22] selftests/vm: introduce two arch independent abstraction

On 02/21/2018 05:55 PM, Ram Pai wrote: > open_hugepage_file() <- opens the huge page file > get_start_key() <-- provides the first non-reserved key. > Looks reasonable. Reviewed-by: Dave Hansen -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in

Re: [PATCH v12 09/22] selftests/vm: fix alloc_random_pkey() to make it really random

On 02/21/2018 05:55 PM, Ram Pai wrote: > alloc_random_pkey() was allocating the same pkey every time. > Not all pkeys were geting tested. fixed it. ... > @@ -602,13 +603,15 @@ int alloc_random_pkey(void) > int alloced_pkeys[NR_PKEYS]; > int nr_alloced = 0; > int random_index; > +

Re: [PATCH v12 08/22] selftests/vm: clear the bits in shadow reg when a pkey is freed.

On 02/21/2018 05:55 PM, Ram Pai wrote: > When a key is freed, the key is no more effective. > Clear the bits corresponding to the pkey in the shadow > register. Otherwise it will carry some spurious bits > which can trigger false-positive asserts. ... > diff --git

Re: [PATCH v12 07/22] selftests/vm: fixed bugs in pkey_disable_clear()

On 02/21/2018 05:55 PM, Ram Pai wrote: > --- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -461,7 +461,7 @@ void pkey_disable_clear(int pkey, int flags) > pkey, pkey, pkey_rights); > pkey_assert(pkey_rights >=

Re: [PATCH v12 06/22] selftests/vm: fix the wrong assert in pkey_disable_set()

On 02/21/2018 05:55 PM, Ram Pai wrote: > If the flag is 0, no bits will be set. Hence we cant expect > the resulting bitmap to have a higher value than what it > was earlier. > > cc: Dave Hansen > cc: Florian Weimer > Signed-off-by: Ram Pai

Re: [PATCH v12 05/22] selftests/vm: generic function to handle shadow key register

On 02/21/2018 05:55 PM, Ram Pai wrote: > +static inline u32 pkey_to_shift(int pkey) > +{ > + return pkey * PKEY_BITS_PER_PKEY; > +} pkey_bit_position(), perhaps? > +static inline pkey_reg_t reset_bits(int pkey, pkey_reg_t bits) > +{ > + u32 shift = pkey_to_shift(pkey); > + > + return

Re: [PATCH v12 04/22] selftests/vm: typecast the pkey register

On 02/21/2018 05:55 PM, Ram Pai wrote: > -static inline unsigned int _rdpkey_reg(int line) > +static inline pkey_reg_t _rdpkey_reg(int line) > { > - unsigned int pkey_reg = __rdpkey_reg(); > + pkey_reg_t pkey_reg = __rdpkey_reg(); > > - dprintf4("rdpkey_reg(line=%d) pkey_reg: %x

Re: [PATCH v12 02/22] selftests/vm: rename all references to pkru to a generic name

On 02/21/2018 05:55 PM, Ram Pai wrote: > int pkey_set(int pkey, unsigned long rights, unsigned long flags) > { > u32 mask = (PKEY_DISABLE_ACCESS|PKEY_DISABLE_WRITE); > - u32 old_pkru = __rdpkru(); > - u32 new_pkru; > + u32 old_pkey_reg = __rdpkey_reg(); > + u32

Re: [PATCH v3 4/4] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

Hi Karthik, On Tue, Mar 13, 2018 at 1:16 PM Karthik Ramasubramanian < krama...@codeaurora.org> wrote: > On 3/2/2018 5:11 PM, Evan Green wrote: > >> + > >> +#ifdef CONFIG_CONSOLE_POLL > >> +#define RX_BYTES_PW 1 > >> +#else > >> +#define RX_BYTES_PW 4 > >> +#endif > > > > This seems fishy to

[PATCH v5 5/9] ipc: Clamp semmni to the real IPCMNI limit

For SysV semaphores, the semmni value is the last part of the 4-element sem number array. To make semmni behave in a similar way to msgmni and shmmni, we can't directly use the _minmax handler. Instead, a special sem specific handler is added to check the last argument to make sure that it is

[PATCH v5 4/9] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is really IPCMNI (32k). This can mislead users as they think they can get a value that is not real. Enforcing the limit by failing the sysctl parameter write, however, can

[PATCH v5 7/9] test_sysctl: Add ctl_table registration failure test

Incorrect sysctl tables are constructed and fed to the register_sysctl_table() function in the test_sysctl kernel module. The function is supposed to fail the registration of those tables or an error will be printed if no failure is returned. The registration failures will cause other warning and

[PATCH v5 8/9] ipc: Allow boot time extension of IPCMNI from 32k to 2M

The maximum number of unique System V IPC identifiers was limited to 32k. That limit should be big enough for most use cases. However, there are some users out there requesting for more. To satisfy the need of those users, a new boot time kernel option "ipcmni_extend" is added to extend the

[PATCH v5 9/9] ipc: Conserve sequence numbers in extended IPCMNI mode

The mixing in of a sequence number into the IPC IDs is probably to avoid ID reuse in userspace as much as possible. With extended IPCMNI mode, the number of usable sequecne numbers is greatly reduced leading to higher chance of ID reuse. To address this issue, we need to conserve the sequence

[PATCH v5 6/9] test_sysctl: Add range clamping test

Add a range clamping test to verify that the input value will be clamped if it exceeds the builtin maximum or minimum value. Below is the expected test run result: Running test: sysctl_test_0006 - run #0 Checking range minimum clamping ... ok Checking range maximum clamping ... ok Checking range

[PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

Checking code is added to provide the following additional ctl_table.flags checks: 1) No unknown flag is allowed. 2) Minimum of a range cannot be larger than the maximum value. 3) The signed and unsigned flags are mutually exclusive. 4) The proc_handler should be consistent with the signed or

[PATCH v5 3/9] sysctl: Warn when a clamped sysctl parameter is set out of range

Even with clamped sysctl parameters, it is still not that straight forward to figure out the exact range of those parameters. One may try to write extreme parameter values to see if they get clamped. To make it easier, a warning with the expected range will now be printed into the kernel ring

[PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

When minimum/maximum values are specified for a sysctl parameter in the ctl_table structure with proc_dointvec_minmax() handler, update to that parameter will fail with error if the given value is outside of the required range. There are use cases where it may be better to clamp the value of the

[PATCH v5 0/9] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

v4->v5: - Revert the flags back to 16-bit so that there will be no change to the size of ctl_table. - Enhance the sysctl_check_flags() as requested by Luis to perform more checks to spot incorrect ctl_table entries. - Change the sysctl selftest to use dummy sysctls instead of production

Re: [PATCH 6/8] trace_uprobe/sdt: Fix multiple update of same reference counter

On 03/16, Ravi Bangoria wrote: > > On 03/15/2018 08:19 PM, Oleg Nesterov wrote: > > On 03/13, Ravi Bangoria wrote: > >> For tiny binaries/libraries, different mmap regions points to the > >> same file portion. In such cases, we may increment reference counter > >> multiple times. > > Yes, > > > >>

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

On 03/15, Steven Rostedt wrote: > > On Tue, 13 Mar 2018 18:26:00 +0530 > Ravi Bangoria wrote: > > > +static void sdt_increment_ref_ctr(struct trace_uprobe *tu) > > +{ > > + struct uprobe_map_info *info; > > + struct vm_area_struct *vma; > > + unsigned long

[PATCH] README: Improve documentation descriptions

"This file" indeed was moved once, but at some point "this file", the top-level README, becomes a file in itself. Now that time has come :) Let's describe how things are, and suggest reading "this file" first, "this file" simply being a the admin-guide README file, not a file that was once moved.

Re: [PATCH] crypto: doc - clarify hash callbacks state machine

On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote: > Even though it doesn't make too much sense, it is perfectly legal to: > - call .init() and then (as many times) .update() > - subseqently _not_ call any of .final(), .finup() or .export() Actually it makes perfect sense, because

Re: [PATCH 8/8] trace_uprobe/sdt: Document about reference counter

On Fri, 16 Mar 2018 15:12:38 +0530 Ravi Bangoria wrote: > On 03/15/2018 06:17 PM, Masami Hiramatsu wrote: > > Hi Ravi, > > > > On Wed, 14 Mar 2018 20:52:59 +0530 > > Ravi Bangoria wrote: > > > >> On 03/14/2018 07:20 PM, Masami

Re: [PATCH] Improve mutex documentation

On Thu, Mar 15, 2018 at 04:58:12AM -0700, Matthew Wilcox wrote: > On Wed, Mar 14, 2018 at 01:56:31PM -0700, Andrew Morton wrote: > > My memory is weak and our documentation is awful. What does > > mutex_lock_killable() actually do and how does it differ from > > mutex_lock_interruptible()? > >

Re: [PATCH 6/8] trace_uprobe/sdt: Fix multiple update of same reference counter

On 03/16/2018 05:42 PM, Ravi Bangoria wrote: > > On 03/15/2018 08:19 PM, Oleg Nesterov wrote: >> On 03/13, Ravi Bangoria wrote: >>> For tiny binaries/libraries, different mmap regions points to the >>> same file portion. In such cases, we may increment reference counter >>> multiple times. >>

Re: [RESEND PATCH v5] input: pxrc: new driver for PhoenixRC Flight Controller Adapter

ping. I do not want to nag, but would someone please have a look at this? Thanks, Marcus Folkesson On Sun, Feb 18, 2018 at 05:17:46PM +0100, Marcus Folkesson wrote: > This driver let you plug in your RC controller to the adapter and > use it as input device in various RC simulators. > >

Re: [PATCH 6/8] trace_uprobe/sdt: Fix multiple update of same reference counter

On 03/15/2018 08:19 PM, Oleg Nesterov wrote: > On 03/13, Ravi Bangoria wrote: >> For tiny binaries/libraries, different mmap regions points to the >> same file portion. In such cases, we may increment reference counter >> multiple times. > Yes, > >> But while de-registration, reference counter

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

On 03/16/2018 05:09 PM, Oleg Nesterov wrote: > On 03/16, Ravi Bangoria wrote: >> On 03/15/2018 08:00 PM, Oleg Nesterov wrote: >>> Note to mention that sdt_find_vma() can return NULL but the callers do >>> vma_offset_to_vaddr(vma) without any check. >> If the "mm" we are passing to sdt_find_vma()

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

On 03/16, Ravi Bangoria wrote: > > On 03/15/2018 08:00 PM, Oleg Nesterov wrote: > > Note to mention that sdt_find_vma() can return NULL but the callers do > > vma_offset_to_vaddr(vma) without any check. > > If the "mm" we are passing to sdt_find_vma() is returned by >

Re: [PATCH 8/8] trace_uprobe/sdt: Document about reference counter

On 03/15/2018 06:17 PM, Masami Hiramatsu wrote: > Hi Ravi, > > On Wed, 14 Mar 2018 20:52:59 +0530 > Ravi Bangoria wrote: > >> On 03/14/2018 07:20 PM, Masami Hiramatsu wrote: >>> On Tue, 13 Mar 2018 18:26:03 +0530 >>> Ravi Bangoria

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

On 03/15/2018 08:31 PM, Oleg Nesterov wrote: > On 03/13, Ravi Bangoria wrote: >> +sdt_update_ref_ctr(struct mm_struct *mm, unsigned long vaddr, short d) >> +{ >> +void *kaddr; >> +struct page *page; >> +struct vm_area_struct *vma; >> +int ret = 0; >> +unsigned short orig = 0;

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

On 03/15/2018 08:00 PM, Oleg Nesterov wrote: > On 03/15, Oleg Nesterov wrote: >>> +static struct vm_area_struct * >>> +sdt_find_vma(struct mm_struct *mm, struct trace_uprobe *tu) >>> +{ >>> + struct vm_area_struct *tmp; >>> + >>> + for (tmp = mm->mmap; tmp != NULL; tmp = tmp->vm_next) >>> +

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

On 03/15/2018 07:51 PM, Oleg Nesterov wrote: > On 03/13, Ravi Bangoria wrote: >> @@ -1053,6 +1056,9 @@ int uprobe_mmap(struct vm_area_struct *vma) >> struct uprobe *uprobe, *u; >> struct inode *inode; >> >> +if (uprobe_mmap_callback) >> +uprobe_mmap_callback(vma); >> +

Re: [PATCH 5/8] trace_uprobe: Support SDT markers having reference count (semaphore)

On 03/15/2018 10:18 PM, Steven Rostedt wrote: > On Tue, 13 Mar 2018 18:26:00 +0530 > Ravi Bangoria wrote: > >> +static void sdt_increment_ref_ctr(struct trace_uprobe *tu) >> +{ >> +struct uprobe_map_info *info; >> +struct vm_area_struct *vma; >> +

Re: [PATCH 2/8] mm: Prefix vma_ to vaddr_to_offset() and offset_to_vaddr()

On 03/15/2018 09:58 PM, Steven Rostedt wrote: > On Tue, 13 Mar 2018 18:25:57 +0530 > Ravi Bangoria wrote: > >> No functionality changes. > Again, please add an explanation to why this patch is done. Sure. Will add. Thanks for the review, Ravi > -- Steve > >>

Re: [PATCH 3/8] Uprobe: Rename map_info to uprobe_map_info

On 03/15/2018 10:14 PM, Steven Rostedt wrote: > On Tue, 13 Mar 2018 18:25:58 +0530 > Ravi Bangoria wrote: >> -static inline struct map_info *free_map_info(struct map_info *info) >> +static inline struct uprobe_map_info * >> +uprobe_free_map_info(struct

Re: [PATCH 1/8] Uprobe: Export vaddr <-> offset conversion functions

On 03/15/2018 09:57 PM, Steven Rostedt wrote: > On Tue, 13 Mar 2018 18:25:56 +0530 > Ravi Bangoria wrote: > >> No functionality changes. > Please add a detailed explanation why this patch is needed. All commits > should be self sufficient and stand on their

Re: [PATCH v10 1/5] arm64: KVM: Prepare set virtual SEI syndrome value

Hi James, Thank you very much for this mail and your time to review this patch. Appreciate that. I will check it and reply. On 2018/3/16 4:37, James Morse wrote: > Hi Dongjiu Geng, > > On 03/03/18 16:09, Dongjiu Geng wrote: >> Export one API to specify virtual SEI syndrome value >> for