Re: lib: Introduce priority array area manager

Hi Jiri, On Wed, Feb 22, 2017 at 8:02 PM, Linux Kernel Mailing List wrote: > Web: > https://git.kernel.org/torvalds/c/44091d29f2075972aede47ef17e1e70db3d51190 > Commit: 44091d29f2075972aede47ef17e1e70db3d51190 > Parent:

Re: lib: Introduce priority array area manager

Hi Jiri, On Wed, Feb 22, 2017 at 8:02 PM, Linux Kernel Mailing List wrote: > Web: > https://git.kernel.org/torvalds/c/44091d29f2075972aede47ef17e1e70db3d51190 > Commit: 44091d29f2075972aede47ef17e1e70db3d51190 > Parent: b862815c3ee7b49ec20a9ab25da55a5f0bcbb95e > Refname:

Re: [PATCHv7 2/8] printk: rename nmi.c and exported api

Hi Sergey, On Tue, Dec 27, 2016 at 3:16 PM, Sergey Senozhatsky wrote: > A preparation patch for printk_safe work. No functional change. > - rename nmi.c to print_safe.c > - add `printk_safe' prefix to some (which used both by printk-safe > and printk-nmi) of the

Re: [PATCHv7 2/8] printk: rename nmi.c and exported api

Hi Sergey, On Tue, Dec 27, 2016 at 3:16 PM, Sergey Senozhatsky wrote: > A preparation patch for printk_safe work. No functional change. > - rename nmi.c to print_safe.c > - add `printk_safe' prefix to some (which used both by printk-safe > and printk-nmi) of the exported functions. > >

RE: [PATCH 1/7] fs, xfs: convert xfs_bui_log_item.bui_refcount from atomic_t to refcount_t

> On Wed, Feb 22, 2017 at 11:20:31AM +, Reshetova, Elena wrote: > > > On Tue, Feb 21, 2017 at 05:49:01PM +0200, Elena Reshetova wrote: > > > > refcount_t type and corresponding API should be > > > > used instead of atomic_t when the variable is used as > > > > a reference counter. This allows

RE: [PATCH 1/7] fs, xfs: convert xfs_bui_log_item.bui_refcount from atomic_t to refcount_t

> On Wed, Feb 22, 2017 at 11:20:31AM +, Reshetova, Elena wrote: > > > On Tue, Feb 21, 2017 at 05:49:01PM +0200, Elena Reshetova wrote: > > > > refcount_t type and corresponding API should be > > > > used instead of atomic_t when the variable is used as > > > > a reference counter. This allows

[BUG?] perf: dwarf unwind doesn't work correctly on aarch64

Hello, perf record -g dwarf (and perf report) doesn't show correct callchain on aarch64. Here is how to reproduce it. 1) I've prepared an debian8 aarch64 VM on qemu-system-aarch64, and build/install the latest perftools on it. 2) Build attached program as below # gcc -O0 -ggdb3

[BUG?] perf: dwarf unwind doesn't work correctly on aarch64

Hello, perf record -g dwarf (and perf report) doesn't show correct callchain on aarch64. Here is how to reproduce it. 1) I've prepared an debian8 aarch64 VM on qemu-system-aarch64, and build/install the latest perftools on it. 2) Build attached program as below # gcc -O0 -ggdb3

Re: [PATCH 2/7] clk: tegra: fix isp clock modelling

The TRM shows a CLK_SOURCE_ISPB register, but after some discussion, it seems like that is a documentation generation bug, so this should be correct. Reviewed-by: Mikko Perttunen On 22.02.2017 17:13, Peter De Schrijver wrote: The 2 isp clocks (ispa and ispb) share a

Re: [PATCH 2/7] clk: tegra: fix isp clock modelling

The TRM shows a CLK_SOURCE_ISPB register, but after some discussion, it seems like that is a documentation generation bug, so this should be correct. Reviewed-by: Mikko Perttunen On 22.02.2017 17:13, Peter De Schrijver wrote: The 2 isp clocks (ispa and ispb) share a mux/divider control. So

TEBRIK EDERIZ!!!

Tarihli: 20.02.2017 Ref: 435062725 Toplu is: 7050470902/189 Kazanma no: GB8101 / LPRC TEBRIK EDERIZ!!! Sevgili kazanan, Size olan odulunuzu bildirmekten mutluluk duyuyoruz. 20 subat 2017'de yayinlanan Avustralya Uluslararasi piyango, tamamen temelli olarak programlanmis Kazananlarin elektronik

TEBRIK EDERIZ!!!

Tarihli: 20.02.2017 Ref: 435062725 Toplu is: 7050470902/189 Kazanma no: GB8101 / LPRC TEBRIK EDERIZ!!! Sevgili kazanan, Size olan odulunuzu bildirmekten mutluluk duyuyoruz. 20 subat 2017'de yayinlanan Avustralya Uluslararasi piyango, tamamen temelli olarak programlanmis Kazananlarin elektronik

Re: [PATCH] drm: kselftest: fix spelling mistake: "misalinged" -> "misaligned"

On Thu, Feb 23, 2017 at 12:07:17AM +, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in pr_err message > > Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson -Chris -- Chris

Re: [PATCH] drm: kselftest: fix spelling mistake: "misalinged" -> "misaligned"

On Thu, Feb 23, 2017 at 12:07:17AM +, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in pr_err message > > Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression

On Thu 23-02-17 09:27:34, Ye Xiaolong wrote: > Hi, Michal > > On 02/07, Michal Hocko wrote: > [snip] > >Could you retest with a single NUMA node? I am not familiar with the > >benchmark enough to judge it was set up properly for a NUMA machine. > > I've retested the commit with a single NUMA

Re: [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression

On Thu 23-02-17 09:27:34, Ye Xiaolong wrote: > Hi, Michal > > On 02/07, Michal Hocko wrote: > [snip] > >Could you retest with a single NUMA node? I am not familiar with the > >benchmark enough to judge it was set up properly for a NUMA machine. > > I've retested the commit with a single NUMA

Re: [RFC PATCH] mm/vmscan: fix high cpu usage of kswapd if there

On Wed 22-02-17 15:24:06, Johannes Weiner wrote: > On Wed, Feb 22, 2017 at 03:16:57PM -0500, Johannes Weiner wrote: > > [...] And then it sounds pretty much like what the allocator/direct > > reclaim already does. > > On a side note: Michal, I'm not sure I fully understand why we need > the

Re: [RFC PATCH] mm/vmscan: fix high cpu usage of kswapd if there

On Wed 22-02-17 15:24:06, Johannes Weiner wrote: > On Wed, Feb 22, 2017 at 03:16:57PM -0500, Johannes Weiner wrote: > > [...] And then it sounds pretty much like what the allocator/direct > > reclaim already does. > > On a side note: Michal, I'm not sure I fully understand why we need > the

Re: [PATCH v2] regulator: devres: introduce managed enable and disable operations

On Tue, Feb 21, 2017 at 10:56:34AM -0800, Mark Brown wrote: > On Tue, Feb 21, 2017 at 12:30:03AM -0800, Dmitry Torokhov wrote: > > On Mon, Feb 20, 2017 at 11:02:58AM -0800, Mark Brown wrote: > > > On Mon, Feb 13, 2017 at 10:51:52AM -0800, Dmitry Torokhov wrote: > > > But that is what I meant here

Re: [PATCH v2] regulator: devres: introduce managed enable and disable operations

On Tue, Feb 21, 2017 at 10:56:34AM -0800, Mark Brown wrote: > On Tue, Feb 21, 2017 at 12:30:03AM -0800, Dmitry Torokhov wrote: > > On Mon, Feb 20, 2017 at 11:02:58AM -0800, Mark Brown wrote: > > > On Mon, Feb 13, 2017 at 10:51:52AM -0800, Dmitry Torokhov wrote: > > > But that is what I meant here

Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

On Wed, Feb 22, 2017 at 10:36:50PM -0800, Ricardo Neri wrote: > + /* > + * A negative offset generally means a error, except > + * -EDOM, which means that the contents of the register > + * should not be used as

Re: [PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

On Wed, Feb 22, 2017 at 10:36:50PM -0800, Ricardo Neri wrote: > + /* > + * A negative offset generally means a error, except > + * -EDOM, which means that the contents of the register > + * should not be used as

Re: [RFC PATCH] mm/vmscan: fix high cpu usage of kswapd if there

On Thu 23-02-17 10:46:01, hejianet wrote: > sorry, resend it due to a delivery-failure: > "Wrong MIME labeling on 8-bit character texts" > I am sorry if anybody received it twice > > Hi Johannes > On 23/02/2017 4:16 AM, Johannes Weiner wrote: > > On Wed, Feb 22, 2017 at 05:04:48PM

Re: [RFC PATCH] mm/vmscan: fix high cpu usage of kswapd if there

On Thu 23-02-17 10:46:01, hejianet wrote: > sorry, resend it due to a delivery-failure: > "Wrong MIME labeling on 8-bit character texts" > I am sorry if anybody received it twice > > Hi Johannes > On 23/02/2017 4:16 AM, Johannes Weiner wrote: > > On Wed, Feb 22, 2017 at 05:04:48PM

Re: [Outreachy kernel] Re: [PATCH v2] staging: wilc1000: renames struct tstrRSSI and its members u8Index, u8Full

> Thanks for the feedback Arend, I really appreciate it. I've decided to go with > these changes in my follow-up patch request: > > - rename tstrRSSI to 'rssi_history_buffer' as Aren suggested since it makes > the > purpose of the struct clear > - remove Hungarian notation from all tstrRSSI

Re: [Outreachy kernel] Re: [PATCH v2] staging: wilc1000: renames struct tstrRSSI and its members u8Index, u8Full

> Thanks for the feedback Arend, I really appreciate it. I've decided to go with > these changes in my follow-up patch request: > > - rename tstrRSSI to 'rssi_history_buffer' as Aren suggested since it makes > the > purpose of the struct clear > - remove Hungarian notation from all tstrRSSI

[PATCH] target: Fix NULL dereference during LUN lookup + active I/O shutdown

From: Nicholas Bellinger When transport_clear_lun_ref() is shutting down a se_lun via configfs with new I/O in-flight, it's possible to trigger a NULL pointer dereference in transport_lookup_cmd_lun() due to the fact percpu_ref_get() doesn't do any __PERCPU_REF_DEAD

[PATCH] target: Fix NULL dereference during LUN lookup + active I/O shutdown

From: Nicholas Bellinger When transport_clear_lun_ref() is shutting down a se_lun via configfs with new I/O in-flight, it's possible to trigger a NULL pointer dereference in transport_lookup_cmd_lun() due to the fact percpu_ref_get() doesn't do any __PERCPU_REF_DEAD checking before incrementing

[PATCH] ARM: dts: sunxi: Add regulators for Sinovoip BPI-M2

Add the needed node for DFVS on Sinovoip BPI-M2. This add the axp221 under the p2wi node, the regulators and the cpu-supply property for cpu0. Signed-off-by: Emmanuel Vadot --- arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 57 1 file changed,

[PATCH] ARM: dts: sunxi: Add regulators for Sinovoip BPI-M2

Add the needed node for DFVS on Sinovoip BPI-M2. This add the axp221 under the p2wi node, the regulators and the cpu-supply property for cpu0. Signed-off-by: Emmanuel Vadot --- arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 57 1 file changed, 57 insertions(+) diff

Re: [PATCH V3 0/4] Define coherent device memory node

On 02/22/2017 03:20 PM, Michal Hocko wrote: > On Tue 21-02-17 19:09:18, Anshuman Khandual wrote: >> On 02/21/2017 04:41 PM, Michal Hocko wrote: >>> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote: >>> [...] * User space using mbind() to get CDM memory is an additional benefit we get

Re: [PATCH V3 0/4] Define coherent device memory node

On 02/22/2017 03:20 PM, Michal Hocko wrote: > On Tue 21-02-17 19:09:18, Anshuman Khandual wrote: >> On 02/21/2017 04:41 PM, Michal Hocko wrote: >>> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote: >>> [...] * User space using mbind() to get CDM memory is an additional benefit we get

[PATCH v4 06/17] x86/insn-eval: Add utility function to get segment descriptor

The segment descriptor contains information that is relevant to how linear address need to be computed. It contains the default size of addresses as well as the base address of the segment. Thus, given a segment selector, we ought look at segment descriptor to correctly calculate the linear

[PATCH v4 06/17] x86/insn-eval: Add utility function to get segment descriptor

The segment descriptor contains information that is relevant to how linear address need to be computed. It contains the default size of addresses as well as the base address of the segment. Thus, given a segment selector, we ought look at segment descriptor to correctly calculate the linear

Re: [PATCH] dma-buf: add support for compat ioctl

Hi Marek, On 23 February 2017 at 00:37, Daniel Vetter wrote: > On Tue, Feb 21, 2017 at 4:08 PM, Christian König > wrote: >> Am 21.02.2017 um 15:55 schrieb Marek Szyprowski: >>> >>> Dear All, >>> >>> On 2017-02-21 15:37, Marek Szyprowski wrote:

Re: [PATCH] dma-buf: add support for compat ioctl

Hi Marek, On 23 February 2017 at 00:37, Daniel Vetter wrote: > On Tue, Feb 21, 2017 at 4:08 PM, Christian König > wrote: >> Am 21.02.2017 um 15:55 schrieb Marek Szyprowski: >>> >>> Dear All, >>> >>> On 2017-02-21 15:37, Marek Szyprowski wrote: Hi Christian, On 2017-02-21

[PATCH v4 08/17] x86/insn-eval: Add functions to get default operand and address sizes

These functions read the default values of the address and operand sizes as specified in the segment descriptor. This information is determined from the D and L bits. Hence, it can be used for both IA-32e 64-bit and 32-bit legacy modes. For virtual-8086 mode, the default address and operand sizes

[PATCH v4 08/17] x86/insn-eval: Add functions to get default operand and address sizes

These functions read the default values of the address and operand sizes as specified in the segment descriptor. This information is determined from the D and L bits. Hence, it can be used for both IA-32e 64-bit and 32-bit legacy modes. For virtual-8086 mode, the default address and operand sizes

[PATCH v4 02/17] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when a SIB byte is used and the base of the SIB byte points to R/EBP (i.e., base = 5) and the mod part of the ModRM byte is zero, the value of such register will not be used as part of the

[PATCH v4 02/17] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when a SIB byte is used and the base of the SIB byte points to R/EBP (i.e., base = 5) and the mod part of the ModRM byte is zero, the value of such register will not be used as part of the

[PATCH v4 00/17] x86: Enable User-Mode Instruction Prevention

This is v4 of this series. Again, it took me a while to complete the updates as support for 16-bit address encodings for protected mode required extra rework. The two previous submissions can be found here [1], here [2] and here [3]. === What is UMIP? User-Mode Instruction Prevention (UMIP) is a

[PATCH v4 07/17] x86/insn-eval: Add utility function to get segment descriptor base address

With segmentation, the base address of the segment descriptor is needed to compute a linear address. The segment descriptor used in the address computation depends on either any segment override prefixes in the in the instruction or the default segment determined by the registers involved in the

[PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when memory addressing is used (i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of the SIB byte points to the R/ESP (i.e., index = 4), the index should not be used in the

[PATCH v4 00/17] x86: Enable User-Mode Instruction Prevention

This is v4 of this series. Again, it took me a while to complete the updates as support for 16-bit address encodings for protected mode required extra rework. The two previous submissions can be found here [1], here [2] and here [3]. === What is UMIP? User-Mode Instruction Prevention (UMIP) is a

[PATCH v4 07/17] x86/insn-eval: Add utility function to get segment descriptor base address

With segmentation, the base address of the segment descriptor is needed to compute a linear address. The segment descriptor used in the address computation depends on either any segment override prefixes in the in the instruction or the default segment determined by the registers involved in the

[PATCH v4 01/17] x86/mpx: Do not use SIB index if index points to R/ESP

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when memory addressing is used (i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of the SIB byte points to the R/ESP (i.e., index = 4), the index should not be used in the

[PATCH v4 04/17] x86/insn-eval: Add utility functions to get register offsets

The function insn_get_reg_offset takes as argument an enumeration that indicates the type of offset that is returned: the R/M part of the ModRM byte, the index of the SIB byte or the base of the SIB byte. Callers of this function would need the definition of such enumeration. This is not needed.

[PATCH v4 04/17] x86/insn-eval: Add utility functions to get register offsets

The function insn_get_reg_offset takes as argument an enumeration that indicates the type of offset that is returned: the R/M part of the ModRM byte, the index of the SIB byte or the base of the SIB byte. Callers of this function would need the definition of such enumeration. This is not needed.

[PATCH v4 13/17] x86: Add emulation code for UMIP instructions

The feature User-Mode Instruction Prevention present in recent Intel processor prevents a group of instructions from being executed with CPL > 0. Otherwise, a general protection fault is issued. Rather than relaying this fault to the user space (in the form of a SIGSEGV signal), the instructions

[PATCH v4 09/17] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when the mod part of the ModRM byte is zero and R/EBP is specified in the R/M part of such bit, the value of the aforementioned register should not be used in the address computation. Instead,

[PATCH v4 13/17] x86: Add emulation code for UMIP instructions

The feature User-Mode Instruction Prevention present in recent Intel processor prevents a group of instructions from being executed with CPL > 0. Otherwise, a general protection fault is issued. Rather than relaying this fault to the user space (in the form of a SIGSEGV signal), the instructions

[PATCH v4 09/17] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when the mod part of the ModRM byte is zero and R/EBP is specified in the R/M part of such bit, the value of the aforementioned register should not be used in the address computation. Instead,

[PATCH v4 16/17] x86: Enable User-Mode Instruction Prevention

User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a bit in %cr4. It makes sense to enable UMIP at some point while booting, before user spaces come up. Like SMAP and SMEP, is not critical to have it enabled very early during boot. This is because UMIP is relevant only when

[PATCH v4 16/17] x86: Enable User-Mode Instruction Prevention

User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a bit in %cr4. It makes sense to enable UMIP at some point while booting, before user spaces come up. Like SMAP and SMEP, is not critical to have it enabled very early during boot. This is because UMIP is relevant only when

[PATCH v4 05/17] x86/insn-eval: Add utility function to get segment selector

When computing a linear address and segmentation is used, we need to know the base address of the segment involved in the computation. In most of the cases, it will be sufficient to use USER_DS, which has a base of 0. However, it may be possible that a user space program defines its own segments

[PATCH v4 03/17] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel

Other kernel submodules can benefit from using the utility functions defined in mpx.c to obtain the addresses and values of operands contained in the general purpose registers. An instance of this is the emulation code used for instructions protected by the Intel User-Mode Instruction Prevention

[PATCH v4 05/17] x86/insn-eval: Add utility function to get segment selector

When computing a linear address and segmentation is used, we need to know the base address of the segment involved in the computation. In most of the cases, it will be sufficient to use USER_DS, which has a base of 0. However, it may be possible that a user space program defines its own segments

[PATCH v4 03/17] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel

Other kernel submodules can benefit from using the utility functions defined in mpx.c to obtain the addresses and values of operands contained in the general purpose registers. An instance of this is the emulation code used for instructions protected by the Intel User-Mode Instruction Prevention

[PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

If the User-Mode Instruction Prevention CPU feature is available and enabled, a general protection fault will be issued if the instructions sgdt, sldt, sidt, str or smsw are executed from user-mode context (CPL > 0). If the fault was caused by any of the instructions protected by UMIP,

[PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

If the User-Mode Instruction Prevention CPU feature is available and enabled, a general protection fault will be issued if the instructions sgdt, sldt, sidt, str or smsw are executed from user-mode context (CPL > 0). If the fault was caused by any of the instructions protected by UMIP,

[PATCH v4 11/17] x86/insn-eval: Add support to resolve 16-bit addressing encodings

Tasks running in virtual-8086 mode or in protected mode with code segment descriptors that specify 16-bit default address sizes via the D bit will use 16-bit addressing form encodings as described in the Intel 64 and IA-32 Architecture Software Developer's Manual Volume 2A Section 2.1.5. 16-bit

[PATCH v2 4/4] w1: w1_ds2760.h: fix defines indentation

Signed-off-by: Mariusz Bialonczyk --- drivers/w1/slaves/w1_ds2760.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/w1/slaves/w1_ds2760.h b/drivers/w1/slaves/w1_ds2760.h index 58e774141568..24168c94eeae 100644 ---

[PATCH v4 11/17] x86/insn-eval: Add support to resolve 16-bit addressing encodings

Tasks running in virtual-8086 mode or in protected mode with code segment descriptors that specify 16-bit default address sizes via the D bit will use 16-bit addressing form encodings as described in the Intel 64 and IA-32 Architecture Software Developer's Manual Volume 2A Section 2.1.5. 16-bit

[PATCH v2 4/4] w1: w1_ds2760.h: fix defines indentation

Signed-off-by: Mariusz Bialonczyk --- drivers/w1/slaves/w1_ds2760.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/w1/slaves/w1_ds2760.h b/drivers/w1/slaves/w1_ds2760.h index 58e774141568..24168c94eeae 100644 --- a/drivers/w1/slaves/w1_ds2760.h +++

[PATCH v2 0/4] w1: add DS2438 support, documentation and small fixes

This is my second version of my w1 patchset. It mainly adds support for the DS2438. There is also a documentation for it and also a missing one for DS2413. Changes since v1: Cleaned up according to Evgeniy Polyakov suggestions: 1/ changed to have lock/unlock_mutex calls in a single function

[PATCH v2 0/4] w1: add DS2438 support, documentation and small fixes

This is my second version of my w1 patchset. It mainly adds support for the DS2438. There is also a documentation for it and also a missing one for DS2413. Changes since v1: Cleaned up according to Evgeniy Polyakov suggestions: 1/ changed to have lock/unlock_mutex calls in a single function

[PATCH v2 2/4] w1: add support for DS2438 Smart Battery Monitor

Detailed information about support and provided sysfs files in my next commit which creates a documentation file: Documentation/w1/slaves/w1_ds2438 Signed-off-by: Mariusz Bialonczyk --- drivers/w1/slaves/Kconfig | 6 + drivers/w1/slaves/Makefile| 1 +

[PATCH v4 10/17] insn/eval: Incorporate segment base in address computation

insn_get_addr_ref returns the effective address as defined by the section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software Developer's Manual. In order to truly give the linear address, we must add the effective address to the segment base as described by the segment descriptor. In

[PATCH v2 1/4] w1: add missing DS2413 documentation

Signed-off-by: Mariusz Bialonczyk --- Documentation/w1/slaves/00-INDEX | 2 ++ Documentation/w1/slaves/w1_ds2413 | 50 +++ 2 files changed, 52 insertions(+) create mode 100644 Documentation/w1/slaves/w1_ds2413 diff --git

[PATCH v4 10/17] insn/eval: Incorporate segment base in address computation

insn_get_addr_ref returns the effective address as defined by the section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software Developer's Manual. In order to truly give the linear address, we must add the effective address to the segment base as described by the segment descriptor. In

[PATCH v2 1/4] w1: add missing DS2413 documentation

Signed-off-by: Mariusz Bialonczyk --- Documentation/w1/slaves/00-INDEX | 2 ++ Documentation/w1/slaves/w1_ds2413 | 50 +++ 2 files changed, 52 insertions(+) create mode 100644 Documentation/w1/slaves/w1_ds2413 diff --git a/Documentation/w1/slaves/00-INDEX

[PATCH v2 2/4] w1: add support for DS2438 Smart Battery Monitor

Detailed information about support and provided sysfs files in my next commit which creates a documentation file: Documentation/w1/slaves/w1_ds2438 Signed-off-by: Mariusz Bialonczyk --- drivers/w1/slaves/Kconfig | 6 + drivers/w1/slaves/Makefile| 1 + drivers/w1/slaves/w1_ds2438.c |

[PATCH v2 3/4] w1: add documentation for w1_ds2438

Signed-off-by: Mariusz Bialonczyk --- Documentation/w1/slaves/00-INDEX | 2 ++ Documentation/w1/slaves/w1_ds2438 | 63 +++ 2 files changed, 65 insertions(+) create mode 100644 Documentation/w1/slaves/w1_ds2438 diff --git

[PATCH v2 3/4] w1: add documentation for w1_ds2438

Signed-off-by: Mariusz Bialonczyk --- Documentation/w1/slaves/00-INDEX | 2 ++ Documentation/w1/slaves/w1_ds2438 | 63 +++ 2 files changed, 65 insertions(+) create mode 100644 Documentation/w1/slaves/w1_ds2438 diff --git a/Documentation/w1/slaves/00-INDEX

[PATCH v4 14/17] x86/umip: Force a page fault when unable to copy emulated result to user

fixup_umip_exception will be called from do_general_protection. If the former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV. However, when emulation is successful but the emulated result cannot be copied to user space memory, it is more accurate to issue a SIGSEGV with

[PATCH v4 12/17] x86/cpufeature: Add User-Mode Instruction Prevention definitions

User-Mode Instruction Prevention is a security feature present in new Intel processors that, when set, prevents the execution of a subset of instructions if such instructions are executed in user mode (CPL > 0). Attempting to execute such instructions causes a general protection exception. The

[PATCH v4 17/17] selftests/x86: Add tests for User-Mode Instruction Prevention

Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a

[PATCH v4 14/17] x86/umip: Force a page fault when unable to copy emulated result to user

fixup_umip_exception will be called from do_general_protection. If the former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV. However, when emulation is successful but the emulated result cannot be copied to user space memory, it is more accurate to issue a SIGSEGV with

[PATCH v4 12/17] x86/cpufeature: Add User-Mode Instruction Prevention definitions

User-Mode Instruction Prevention is a security feature present in new Intel processors that, when set, prevents the execution of a subset of instructions if such instructions are executed in user mode (CPL > 0). Attempting to execute such instructions causes a general protection exception. The

[PATCH v4 17/17] selftests/x86: Add tests for User-Mode Instruction Prevention

Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a

Re: [PATCH v2] staging: wilc1000: renames struct tstrRSSI and its members u8Index, u8Full

On Wed, 2017-02-22 at 20:50 +0100, Arend Van Spriel wrote: > On 22-2-2017 18:14, Tahia Khan wrote: > > Fixes multiple camel case checks on struct tstrRSSI from checkpatch.pl: [] > Just a generic remark that may help you with other changes you will be > making in the linux kernel. Warnings from

Re: [PATCH v2] staging: wilc1000: renames struct tstrRSSI and its members u8Index, u8Full

On Wed, 2017-02-22 at 20:50 +0100, Arend Van Spriel wrote: > On 22-2-2017 18:14, Tahia Khan wrote: > > Fixes multiple camel case checks on struct tstrRSSI from checkpatch.pl: [] > Just a generic remark that may help you with other changes you will be > making in the linux kernel. Warnings from

Re: [PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[...] >>> > + >>> > + soc { >>> > + soc_funnel: funnel@10001000 { >>> >>> There is no need for a label ("soc_funnel) before the device name if that >>> device is not referenced elsewhere in the DTS. The same comment applies to >>> most >>> of the component listed below. >>> >> >>

Re: [PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[...] >>> > + >>> > + soc { >>> > + soc_funnel: funnel@10001000 { >>> >>> There is no need for a label ("soc_funnel) before the device name if that >>> device is not referenced elsewhere in the DTS. The same comment applies to >>> most >>> of the component listed below. >>> >> >>

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote: > > Poor Simon Sandström. > > > > Funnily enough, this only exists for one commit. You've got several > > other commits from Simon that get his name right. > > > > What happened? > > I don't know what happened, I used git for this, I

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote: > > Poor Simon Sandström. > > > > Funnily enough, this only exists for one commit. You've got several > > other commits from Simon that get his name right. > > > > What happened? > > I don't know what happened, I used git for this, I

Re: Problem on SCTP

On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote: > does this fixed in RHEL7? yes, I think so. > > On Wed, Feb 22, 2017 at 11:03 AM, Xin Long wrote: >> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: >>> Hi Xin >>> >>> do you mean we

Re: Problem on SCTP

On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote: > does this fixed in RHEL7? yes, I think so. > > On Wed, Feb 22, 2017 at 11:03 AM, Xin Long wrote: >> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote: >>> Hi Xin >>> >>> do you mean we need to patch the kernel? >> Yups, pls comment on that bz

min_vruntime update when a task is sleeping/migrating

Hi Peter, The comment and the code around 2nd update_min_vruntime() call in dequeue_entity() are not matching. If I understand commit b60205c7c558 ("sched/fair: Fix min_vruntime tracking") correctly, the check is inverted there. We want to update min_vruntime when a task is sleeping/migrating. is

min_vruntime update when a task is sleeping/migrating

Hi Peter, The comment and the code around 2nd update_min_vruntime() call in dequeue_entity() are not matching. If I understand commit b60205c7c558 ("sched/fair: Fix min_vruntime tracking") correctly, the check is inverted there. We want to update min_vruntime when a task is sleeping/migrating. is

[PATCH v3] sched/deadline: Change the time to replenish runtime for sleep tasks

Let's consider the following example. timeline : o...o.o...o..o ^ ^ ^ ^ ^ | | | | | start | | | | original runtime |

Re: [PATCH v2 2/2] sched/deadline: Change the way to replenish runtime for sleep tasks

On Thu, Feb 23, 2017 at 12:18:48PM +0900, byungchul.park wrote: > > Current code handles this by replenishing a runtime in hrtimer callback > > for deadline. But this approach has room for improvement in two ways: > > > >1. No need to keep the hrtimer for a sleep task because it can be > >

[PATCH v3] sched/deadline: Change the time to replenish runtime for sleep tasks

Let's consider the following example. timeline : o...o.o...o..o ^ ^ ^ ^ ^ | | | | | start | | | | original runtime |

Re: [PATCH v2 2/2] sched/deadline: Change the way to replenish runtime for sleep tasks

On Thu, Feb 23, 2017 at 12:18:48PM +0900, byungchul.park wrote: > > Current code handles this by replenishing a runtime in hrtimer callback > > for deadline. But this approach has room for improvement in two ways: > > > >1. No need to keep the hrtimer for a sleep task because it can be > >

Re: [f2fs-dev] [PATCH 2/5] f2fs: check last page index in cached bio to decide submission

On 2017/2/4 7:48, Jaegeuk Kim wrote: > If the cached bio has the last page's index, then we need to submit it. > Otherwise, we don't need to submit it and can wait for further IO merges. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu

Re: [f2fs-dev] [PATCH 2/5] f2fs: check last page index in cached bio to decide submission

On 2017/2/4 7:48, Jaegeuk Kim wrote: > If the cached bio has the last page's index, then we need to submit it. > Otherwise, we don't need to submit it and can wait for further IO merges. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu

git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Wed, Feb 22, 2017 at 11:59:01AM -0800, Linus Torvalds wrote: > On Wed, Feb 22, 2017 at 6:56 AM, Greg KH wrote: > > > > =?UTF-8?q?Simon=20Sandstr=C3=B6m?= (1): > > staging: vt6656: Add missing identifier names > > Wow, your scripts really screwed up that name.

git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Wed, Feb 22, 2017 at 11:59:01AM -0800, Linus Torvalds wrote: > On Wed, Feb 22, 2017 at 6:56 AM, Greg KH wrote: > > > > =?UTF-8?q?Simon=20Sandstr=C3=B6m?= (1): > > staging: vt6656: Add missing identifier names > > Wow, your scripts really screwed up that name. > > I'm assuming this is

Re: [PATCH v3] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

On 02/23/2017 at 02:50 AM, Luck, Tony wrote: > On Wed, Feb 22, 2017 at 12:11:14PM +0800, Xunlei Pang wrote: >> +/* >> + * Cases to bail out to avoid rendezvous process timeout: >> + * 1)If this CPU is offline. >> + * 2)If crashing_cpu was set, e.g. entering kdump, >> + * we

Re: [PATCH v3] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

On 02/23/2017 at 02:50 AM, Luck, Tony wrote: > On Wed, Feb 22, 2017 at 12:11:14PM +0800, Xunlei Pang wrote: >> +/* >> + * Cases to bail out to avoid rendezvous process timeout: >> + * 1)If this CPU is offline. >> + * 2)If crashing_cpu was set, e.g. entering kdump, >> + * we

  1   2   3   4   5   6   7   8   9   10   >