Re: [PATCH -v6 13/13] futex: futex_lock_pi() vs PREEMPT_RT_FULL

On Fri, 2017-04-07 at 19:26 -0700, Darren Hart wrote: > I would like to see more testing because... well... futexes. But, we don't > have > a futex torture suite yet, but that is something I'm hoping to be looking into > in the near future. What testing we do have available has passed between my

Re: [PATCH -v6 13/13] futex: futex_lock_pi() vs PREEMPT_RT_FULL

On Fri, 2017-04-07 at 19:26 -0700, Darren Hart wrote: > I would like to see more testing because... well... futexes. But, we don't > have > a futex torture suite yet, but that is something I'm hoping to be looking into > in the near future. What testing we do have available has passed between my

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 9:21 PM, Daniel Micay wrote: >>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >>> somewhere sensible should make those "leaks" visible fast -- and their >>> exploitation impossible, i.e. fail hard. >> >> The leaks surely exist

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 9:21 PM, Daniel Micay wrote: >>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >>> somewhere sensible should make those "leaks" visible fast -- and their >>> exploitation impossible, i.e. fail hard. >> >> The leaks surely exist and now we'll just add an

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Fri, 2017-04-07 at 21:56 +0300, Michael S. Tsirkin wrote: > OK. test3 and test4 are now pushed: test3 should fix your hang, > test4 is trying to fix a crash reported independently. test3 does not fix the post hibernate hang business that I can easily reproduce, those are NFS, and at least as

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Fri, 2017-04-07 at 21:56 +0300, Michael S. Tsirkin wrote: > OK. test3 and test4 are now pushed: test3 should fix your hang, > test4 is trying to fix a crash reported independently. test3 does not fix the post hibernate hang business that I can easily reproduce, those are NFS, and at least as

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause >> wrote: >> > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> >> On Fri, 7

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote: > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote: > >> On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause >> wrote: >> > On 7 April 2017 at 15:14, Thomas Gleixner wrote: >> >> On Fri, 7 Apr 2017, Mathias Krause wrote: >> > Fair enough. However,

[PATCH V8 5/5] PCI/ASPM: move link_state cleanup to bridge remove

For endpoints, change pcie_aspm_exit_link_state() so it cleans up the device's own state and disables ASPM if necessary, but doesn't remove the parent's link_state. For bridges, change pcie_aspm_exit_link_state() so it frees the bridge's own link_state. Fixes:

[PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Now that we added a hook to be called from device_add, save the default values from the HW registers early in the boot for further reuse during hot device add/remove operations. If the link is down during boot, assume that we want to enable L0s and L1 following hotplug insertion as well as L1SS

[PATCH V8 5/5] PCI/ASPM: move link_state cleanup to bridge remove

For endpoints, change pcie_aspm_exit_link_state() so it cleans up the device's own state and disables ASPM if necessary, but doesn't remove the parent's link_state. For bridges, change pcie_aspm_exit_link_state() so it frees the bridge's own link_state. Fixes:

[PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Now that we added a hook to be called from device_add, save the default values from the HW registers early in the boot for further reuse during hot device add/remove operations. If the link is down during boot, assume that we want to enable L0s and L1 following hotplug insertion as well as L1SS

[PATCH V8 2/5] PCI/ASPM: split pci_aspm_init() into two

Split pci_aspm_init() body into pci_aspm_init_upstream() and pci_aspm_init_downstream() for bridge and endpoint specific code behavior. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895 Signed-off-by: Sinan Kaya --- drivers/pci/pcie/aspm.c | 15 ++- 1

[PATCH V8 2/5] PCI/ASPM: split pci_aspm_init() into two

Split pci_aspm_init() body into pci_aspm_init_upstream() and pci_aspm_init_downstream() for bridge and endpoint specific code behavior. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895 Signed-off-by: Sinan Kaya --- drivers/pci/pcie/aspm.c | 15 ++- 1 file changed, 14

[PATCH V8 3/5] PCI/ASPM: add init hook to device_add

For bridges, have pcie_aspm_init_link_state() allocate a link_state, regardless of whether it currently has any children. pcie_aspm_init_link_state(): Called for bridges (upstream end of link) after all children have been enumerated. No longer needs to check aspm_support_enabled or

[PATCH V8 1/5] PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()

We need a callback from pci_init_capabilities function for every single new PCI device that is currently being added. pci_aspm_init() will be used to save the power on state of the HW. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895 Signed-off-by: Sinan Kaya ---

[PATCH V8 3/5] PCI/ASPM: add init hook to device_add

For bridges, have pcie_aspm_init_link_state() allocate a link_state, regardless of whether it currently has any children. pcie_aspm_init_link_state(): Called for bridges (upstream end of link) after all children have been enumerated. No longer needs to check aspm_support_enabled or

[PATCH V8 1/5] PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities()

We need a callback from pci_init_capabilities function for every single new PCI device that is currently being added. pci_aspm_init() will be used to save the power on state of the HW. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=194895 Signed-off-by: Sinan Kaya ---

I have something to discuss with you

Hello my dear My name is Rosita I have something to discuss with you please if you don't mind you can reply me,(rositaadi...@yahoo.com)so that we can discuss it in full, i will wait for your reply thank you,from Rosita

I have something to discuss with you

Hello my dear My name is Rosita I have something to discuss with you please if you don't mind you can reply me,(rositaadi...@yahoo.com)so that we can discuss it in full, i will wait for your reply thank you,from Rosita

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >> somewhere sensible should make those "leaks" visible fast -- and their >> exploitation impossible, i.e. fail hard. > > The leaks surely exist and now we'll just add an exploitable BUG. That didn't seem to matter for landing

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >> somewhere sensible should make those "leaks" visible fast -- and their >> exploitation impossible, i.e. fail hard. > > The leaks surely exist and now we'll just add an exploitable BUG. That didn't seem to matter for landing

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> Not too late to rename it. Scoped write? I think it makes change to s/change/sense/

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> Not too late to rename it. Scoped write? I think it makes change to s/change/sense/

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> I probably chose the wrong name for this feature (write rarely). > That's _usually_ true, but "sensitive_write()" was getting rather > long. The things that we need to protect with this are certainly stuff > that doesn't get much writing, but some things are just plain > sensitive (like page

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

> I probably chose the wrong name for this feature (write rarely). > That's _usually_ true, but "sensitive_write()" was getting rather > long. The things that we need to protect with this are certainly stuff > that doesn't get much writing, but some things are just plain > sensitive (like page

Re: [PATCH 2/2] gpio: arizona: Add support for GPIOs that need to be maintained

Hi Charles, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.11-rc5 next-20170407] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Charles-Keepax/mfd-arizona-Add-GPIO

Re: [PATCH 2/2] gpio: arizona: Add support for GPIOs that need to be maintained

Hi Charles, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.11-rc5 next-20170407] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Charles-Keepax/mfd-arizona-Add-GPIO

Re: [PATCH 2/2] gpio: arizona: Add support for GPIOs that need to be maintained

Hi Charles, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.11-rc5 next-20170407] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Charles-Keepax/mfd-arizona-Add-GPIO

Re: [PATCH 2/2] gpio: arizona: Add support for GPIOs that need to be maintained

Hi Charles, [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.11-rc5 next-20170407] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Charles-Keepax/mfd-arizona-Add-GPIO

Re: [PATCH v2 04/10] mm: make the try_to_munlock void function

1317 Comm: trinity-c62 Tainted: GW 4.11.0-rc5-next-20170407 #7 [ 21.042761] task: 8801067d3e40 task.stack: 8800c06d [ 21.043572] RIP: 0010:try_to_munlock (??:?) [ 21.044639] RSP: 0018:8800c06d71a0 EFLAGS: 00010296 [ 21.045330] RAX: RB

Re: [PATCH v2 04/10] mm: make the try_to_munlock void function

11) [ 21.038901] [ cut here ] [ 21.039546] kernel BUG at mm/rmap.c:1560! [ 21.040126] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN [ 21.040910] Modules linked in: [ 21.041345] CPU: 6 PID: 1317 Comm: trinity-c62 Tainted: GW 4.11.0-rc5-next-20170407 #7 [ 21

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On 06.04.2017 22:25, Jiri Kosina wrote: > On Thu, 6 Apr 2017, Rafael J. Wysocki wrote: > > Your swap partition may be located on an NVDIMM or be encrypted. An NVDIMM should be considered the same as any other persistent storage. It may be encrypted, but where's the key

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

On 06.04.2017 22:25, Jiri Kosina wrote: > On Thu, 6 Apr 2017, Rafael J. Wysocki wrote: > > Your swap partition may be located on an NVDIMM or be encrypted. An NVDIMM should be considered the same as any other persistent storage. It may be encrypted, but where's the key

Re: [PATCH -v6 13/13] futex: futex_lock_pi() vs PREEMPT_RT_FULL

On Wed, Mar 22, 2017 at 11:36:00AM +0100, Peter Zijlstra wrote: > When PREEMPT_RT_FULL does the spinlock -> rt_mutex substitution the PI > chain code will (falsely) report a deadlock and BUG. > > The problem is that we hold hb->lock (now an rt_mutex) while doing > task_blocks_on_rt_mutex on the

Re: [PATCH -v6 13/13] futex: futex_lock_pi() vs PREEMPT_RT_FULL

On Wed, Mar 22, 2017 at 11:36:00AM +0100, Peter Zijlstra wrote: > When PREEMPT_RT_FULL does the spinlock -> rt_mutex substitution the PI > chain code will (falsely) report a deadlock and BUG. > > The problem is that we hold hb->lock (now an rt_mutex) while doing > task_blocks_on_rt_mutex on the

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

>> - trace_seq_printf(s, "#%-5u inner/outer(us): %4llu/%-5llu ts:%ld.%09ld", >> + trace_seq_printf(s, "#%-5u inner/outer(us): %4llu/%-5llu >> ts:%lld.%09ld", >>field->seqnum, >>field->duration, >>

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

>> - trace_seq_printf(s, "#%-5u inner/outer(us): %4llu/%-5llu ts:%ld.%09ld", >> + trace_seq_printf(s, "#%-5u inner/outer(us): %4llu/%-5llu >> ts:%lld.%09ld", >>field->seqnum, >>field->duration, >>

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

On Thu, Apr 06, 2017 at 05:54:14PM +0800, Herbert Xu wrote: > On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote: > > > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to > > skcipher"). The s5p-sss driver stays the same... but the xts changes and > > as a result

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

On Thu, Apr 06, 2017 at 05:54:14PM +0800, Herbert Xu wrote: > On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote: > > > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to > > skcipher"). The s5p-sss driver stays the same... but the xts changes and > > as a result

[PATCH] ARM: dts: stm32f7: add STM32f769I & stm32f746 discovery board support

Stm32f769I & stm32f746 are MCUs of stm32f7 family. Here are the major spces of the two boards: stm32f769I discovery board: - Cortex-M7 core @216MHz - 2MB mcu internal flash - 512KB internal sram - 16MB sdram memory - 64MB qspi flash memory - 4 inch

[PATCH] ARM: dts: stm32f7: add STM32f769I & stm32f746 discovery board support

Stm32f769I & stm32f746 are MCUs of stm32f7 family. Here are the major spces of the two boards: stm32f769I discovery board: - Cortex-M7 core @216MHz - 2MB mcu internal flash - 512KB internal sram - 16MB sdram memory - 64MB qspi flash memory - 4 inch

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

On Fri, 7 Apr 2017 17:57:00 -0700 Deepa Dinamani wrote: > struct timespec is not y2038 safe on 32 bit machines > and needs to be replaced by struct timespec64 > in order to represent times beyond year 2038 on such > machines. > > Fix all the timestamp representation in

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

On Fri, 7 Apr 2017 17:57:00 -0700 Deepa Dinamani wrote: > struct timespec is not y2038 safe on 32 bit machines > and needs to be replaced by struct timespec64 > in order to represent times beyond year 2038 on such > machines. > > Fix all the timestamp representation in struct trace_hwlat > and

[PATCH v4 06/10] soc: mediatek: avoid using fixed spm power status defines

Use variables to replace fixed defines since the offset of the status of spm power might be different for some chips Signed-off-by: Mars Cheng Signed-off-by: Kevin-CW Chen --- drivers/soc/mediatek/mtk-scpsys.c | 33

[PATCH v4 06/10] soc: mediatek: avoid using fixed spm power status defines

Use variables to replace fixed defines since the offset of the status of spm power might be different for some chips Signed-off-by: Mars Cheng Signed-off-by: Kevin-CW Chen --- drivers/soc/mediatek/mtk-scpsys.c | 33 +++-- 1 file changed, 27 insertions(+), 6

Re: [PATCH -v6 12/13] futex: futex_unlock_pi() determinism

On Wed, Mar 22, 2017 at 11:35:59AM +0100, Peter Zijlstra wrote: > The problem with returning -EAGAIN when the waiter state mismatches is > that it becomes very hard to proof a bounded execution time on the prove > operation. And seeing that this is a RT operation, this is somewhat an RT >

[PATCH v4 08/10] dt-bindings: mediatek: add MT6797 power dt-bindings

This adds power dt-bindings for MT6797 Signed-off-by: Mars Cheng Signed-off-by: Kevin-CW Chen --- .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

Re: [PATCH -v6 12/13] futex: futex_unlock_pi() determinism

On Wed, Mar 22, 2017 at 11:35:59AM +0100, Peter Zijlstra wrote: > The problem with returning -EAGAIN when the waiter state mismatches is > that it becomes very hard to proof a bounded execution time on the prove > operation. And seeing that this is a RT operation, this is somewhat an RT >

[PATCH v4 08/10] dt-bindings: mediatek: add MT6797 power dt-bindings

This adds power dt-bindings for MT6797 Signed-off-by: Mars Cheng Signed-off-by: Kevin-CW Chen --- .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt

[PATCH v4 07/10] soc: mediatek: add vdec item for scpsys

for some chips, there is vdec item in scpsys, this patch adds it. Signed-off-by: Mars Cheng --- drivers/soc/mediatek/mtk-scpsys.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index

[PATCH v4 07/10] soc: mediatek: add vdec item for scpsys

for some chips, there is vdec item in scpsys, this patch adds it. Signed-off-by: Mars Cheng --- drivers/soc/mediatek/mtk-scpsys.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index eadbf0d..a8ba800 100644 ---

[PATCH v4 09/10] soc: mediatek: add MT6797 scpsys support

This adds scpsys support for MT6797 Signed-off-by: Mars Cheng Signed-off-by: Kevin-CW Chen --- drivers/soc/mediatek/mtk-scpsys.c| 114 ++ include/dt-bindings/power/mt6797-power.h | 30 2 files

[PATCH v4 09/10] soc: mediatek: add MT6797 scpsys support

This adds scpsys support for MT6797 Signed-off-by: Mars Cheng Signed-off-by: Kevin-CW Chen --- drivers/soc/mediatek/mtk-scpsys.c| 114 ++ include/dt-bindings/power/mt6797-power.h | 30 2 files changed, 144 insertions(+) create mode 100644

[PATCH v4 04/10] clk: mediatek: add mt6797 clock IDs

Signed-off-by: Mars Cheng --- include/dt-bindings/clock/mt6797-clk.h | 281 1 file changed, 281 insertions(+) create mode 100644 include/dt-bindings/clock/mt6797-clk.h diff --git a/include/dt-bindings/clock/mt6797-clk.h

[PATCH v4 04/10] clk: mediatek: add mt6797 clock IDs

Signed-off-by: Mars Cheng --- include/dt-bindings/clock/mt6797-clk.h | 281 1 file changed, 281 insertions(+) create mode 100644 include/dt-bindings/clock/mt6797-clk.h diff --git a/include/dt-bindings/clock/mt6797-clk.h

[PATCH v4 01/10] dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform

This adds dt-binding documentation for Mediatek MT6797. Only include very basic items, gic, uart timer and cpu. Signed-off-by: Mars Cheng Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/mediatek.txt |4

[PATCH v4 01/10] dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform

This adds dt-binding documentation for Mediatek MT6797. Only include very basic items, gic, uart timer and cpu. Signed-off-by: Mars Cheng Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/mediatek.txt |4 .../interrupt-controller/mediatek,sysirq.txt |1 +

[PATCH v4 02/10] arm64: dts: mediatek: add mt6797 support

This adds basic chip support for MT6797 SoC. Signed-off-by: Mars Cheng --- arch/arm64/boot/dts/mediatek/Makefile |1 + arch/arm64/boot/dts/mediatek/mt6797-evb.dts | 36 ++ arch/arm64/boot/dts/mediatek/mt6797.dtsi| 182 +++ 3

[PATCH v4 05/10] clk: mediatek: add clk support for MT6797

From: Kevin-CW Chen Add MT6797 clock support, include topckgen, apmixedsys, infracfg and subsystem clocks Signed-off-by: Kevin-CW Chen Signed-off-by: Mars Cheng Tested-by: Matthias Brugger

[PATCH v4 00/10] Add Basic SoC support for MT6797

This patch set adds basic SoC support for mediatek's first 10-core chip, X20, also known as MT6797. - based on 4.11-rc1 - support common clk framework - apply patches about intpol just accepted to get full feature support: http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008371.html

[PATCH v4 02/10] arm64: dts: mediatek: add mt6797 support

This adds basic chip support for MT6797 SoC. Signed-off-by: Mars Cheng --- arch/arm64/boot/dts/mediatek/Makefile |1 + arch/arm64/boot/dts/mediatek/mt6797-evb.dts | 36 ++ arch/arm64/boot/dts/mediatek/mt6797.dtsi| 182 +++ 3 files changed, 219

[PATCH v4 05/10] clk: mediatek: add clk support for MT6797

From: Kevin-CW Chen Add MT6797 clock support, include topckgen, apmixedsys, infracfg and subsystem clocks Signed-off-by: Kevin-CW Chen Signed-off-by: Mars Cheng Tested-by: Matthias Brugger Acked-by: Stephen Boyd --- drivers/clk/mediatek/Kconfig | 32 ++

[PATCH v4 00/10] Add Basic SoC support for MT6797

This patch set adds basic SoC support for mediatek's first 10-core chip, X20, also known as MT6797. - based on 4.11-rc1 - support common clk framework - apply patches about intpol just accepted to get full feature support: http://lists.infradead.org/pipermail/linux-mediatek/2017-March/008371.html

[PATCH v4 03/10] dt-bindings: arm: mediatek: document clk bindings for MT6797

From: Kevin-CW Chen This patch adds the binding documentation for apmixedsys, imgsys, infracfg, mmsys, topckgen, vdecsys and vencsys for MT6797. Signed-off-by: Kevin-CW Chen Signed-off-by: Mars Cheng Acked-by:

[PATCH v4 03/10] dt-bindings: arm: mediatek: document clk bindings for MT6797

From: Kevin-CW Chen This patch adds the binding documentation for apmixedsys, imgsys, infracfg, mmsys, topckgen, vdecsys and vencsys for MT6797. Signed-off-by: Kevin-CW Chen Signed-off-by: Mars Cheng Acked-by: Rob Herring --- .../bindings/arm/mediatek/mediatek,apmixedsys.txt |1 +

[PATCH v4 10/10] arm64: dts: mediatek: add clk and scp nodes for MT6797

This adds clk and scp nodes for MT6797 Signed-off-by: Mars Cheng --- arch/arm64/boot/dts/mediatek/mt6797.dtsi | 71 -- 1 file changed, 67 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi

[PATCH v4 10/10] arm64: dts: mediatek: add clk and scp nodes for MT6797

This adds clk and scp nodes for MT6797 Signed-off-by: Mars Cheng --- arch/arm64/boot/dts/mediatek/mt6797.dtsi | 71 -- 1 file changed, 67 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi

[PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

struct timespec is not y2038 safe on 32 bit machines and needs to be replaced by struct timespec64 in order to represent times beyond year 2038 on such machines. Fix all the timestamp representation in struct trace_hwlat and all the corresponding implementations. Signed-off-by: Deepa Dinamani

[PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

struct timespec is not y2038 safe on 32 bit machines and needs to be replaced by struct timespec64 in order to represent times beyond year 2038 on such machines. Fix all the timestamp representation in struct trace_hwlat and all the corresponding implementations. Signed-off-by: Deepa Dinamani

[PATCH 09/12] lustre: Replace CURRENT_TIME macro

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time() for filesystem times, and ktime_get_* functions for others. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as lustre uses it

[PATCH 05/12] fs: ufs: Use ktime_get_real_ts64() for birthtime

CURRENT_TIME is not y2038 safe. Replace it with ktime_get_real_ts64(). Inode time formats are already 64 bit long and accommodates time64_t. Signed-off-by: Deepa Dinamani --- fs/ufs/ialloc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH 09/12] lustre: Replace CURRENT_TIME macro

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time() for filesystem times, and ktime_get_* functions for others. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as lustre uses it

[PATCH 05/12] fs: ufs: Use ktime_get_real_ts64() for birthtime

CURRENT_TIME is not y2038 safe. Replace it with ktime_get_real_ts64(). Inode time formats are already 64 bit long and accommodates time64_t. Signed-off-by: Deepa Dinamani --- fs/ufs/ialloc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/ufs/ialloc.c

[PATCH 10/12] apparmorfs: Replace CURRENT_TIME with current_time()

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time(). This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. current_time() is also planned to be

[PATCH 10/12] apparmorfs: Replace CURRENT_TIME with current_time()

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time(). This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. current_time() is also planned to be

[PATCH 07/12] fs: btrfs: Use ktime_get_real_ts for root ctime

btrfs_root_item maintains the ctime for root updates. This is not part of vfs_inode. Since current_time() uses struct inode* as an argument as Linus suggested, this cannot be used to update root times unless, we modify the signature to use inode. Since btrfs uses nanosecond time granularity, it

[PATCH 07/12] fs: btrfs: Use ktime_get_real_ts for root ctime

btrfs_root_item maintains the ctime for root updates. This is not part of vfs_inode. Since current_time() uses struct inode* as an argument as Linus suggested, this cannot be used to update root times unless, we modify the signature to use inode. Since btrfs uses nanosecond time granularity, it

[PATCH 11/12] time: Delete CURRENT_TIME_SEC and CURRENT_TIME

All uses of CURRENT_TIME_SEC and CURRENT_TIME macros have been replaced by other time functions. These macros are also not y2038 safe. And, all their use cases can be fulfilled by y2038 safe ktime_get_* variants. Signed-off-by: Deepa Dinamani Acked-by: John Stultz

[PATCH 11/12] time: Delete CURRENT_TIME_SEC and CURRENT_TIME

All uses of CURRENT_TIME_SEC and CURRENT_TIME macros have been replaced by other time functions. These macros are also not y2038 safe. And, all their use cases can be fulfilled by y2038 safe ktime_get_* variants. Signed-off-by: Deepa Dinamani Acked-by: John Stultz Reviewed-by: Arnd Bergmann

[PATCH 12/12] time: Delete current_fs_time() function

All uses of the current_fs_time() function have been replaced by other time interfaces. And, its use cases can be fulfilled by current_time() or ktime_get_* variants. Signed-off-by: Deepa Dinamani Reviewed-by: Arnd Bergmann --- include/linux/fs.h | 1 -

[PATCH 12/12] time: Delete current_fs_time() function

All uses of the current_fs_time() function have been replaced by other time interfaces. And, its use cases can be fulfilled by current_time() or ktime_get_* variants. Signed-off-by: Deepa Dinamani Reviewed-by: Arnd Bergmann --- include/linux/fs.h | 1 - kernel/time/time.c | 14 --

[PATCH 08/12] fs: ubifs: Replace CURRENT_TIME_SEC with current_time

CURRENT_TIME_SEC is not y2038 safe. current_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transition CURRENT_TIME_SEC to use y2038 safe time interfaces. current_time() returns timestamps according to the granularities set in the inode's

[PATCH 08/12] fs: ubifs: Replace CURRENT_TIME_SEC with current_time

CURRENT_TIME_SEC is not y2038 safe. current_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transition CURRENT_TIME_SEC to use y2038 safe time interfaces. current_time() returns timestamps according to the granularities set in the inode's

[PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

CURRENT_TIME is not y2038 safe. The macro will be deleted and all the references to it will be replaced by ktime_get_* apis. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as ceph uses it internally everywhere. These references will be changed to use

[PATCH 04/12] fs: ceph: CURRENT_TIME with ktime_get_real_ts()

CURRENT_TIME is not y2038 safe. The macro will be deleted and all the references to it will be replaced by ktime_get_* apis. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as ceph uses it internally everywhere. These references will be changed to use

[PATCH 03/12] fs: cifs: Replace CURRENT_TIME by other appropriate apis

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time() for filesystem times, and ktime_get_* functions for authentication timestamps and timezone calculations. This is also in preparation for the patch that transitions vfs

[PATCH 03/12] fs: cifs: Replace CURRENT_TIME by other appropriate apis

CURRENT_TIME macro is not y2038 safe on 32 bit systems. The patch replaces all the uses of CURRENT_TIME by current_time() for filesystem times, and ktime_get_* functions for authentication timestamps and timezone calculations. This is also in preparation for the patch that transitions vfs

[PATCH 06/12] audit: Use timespec64 to represent audit timestamps

struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto

[PATCH 06/12] audit: Use timespec64 to represent audit timestamps

struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto

[PATCH 01/12] fs: f2fs: Use ktime_get_real_seconds for sit_info times

CURRENT_TIME_SEC is not y2038 safe. Replace use of CURRENT_TIME_SEC with ktime_get_real_seconds in segment timestamps used by GC algorithm including the segment mtime timestamps. Signed-off-by: Deepa Dinamani Reviewed-by: Arnd Bergmann ---

[PATCH 01/12] fs: f2fs: Use ktime_get_real_seconds for sit_info times

CURRENT_TIME_SEC is not y2038 safe. Replace use of CURRENT_TIME_SEC with ktime_get_real_seconds in segment timestamps used by GC algorithm including the segment mtime timestamps. Signed-off-by: Deepa Dinamani Reviewed-by: Arnd Bergmann --- fs/f2fs/segment.c | 2 +- fs/f2fs/segment.h | 5 +++--

[PATCH 00/12] Delete CURRENT_TIME, CURRENT_TIME_SEC and current_fs_time

The series contains the last unmerged uses of CURRENT_TIME, CURRENT_TIME_SEC, and current_fs_time(). The series also deletes these apis. All the patches except [PATCH 9/12] and [PATCH 10/12] are resend patches. These patches fix new instances of CURRENT_TIME. cifs and ceph patches have been

[PATCH 00/12] Delete CURRENT_TIME, CURRENT_TIME_SEC and current_fs_time

The series contains the last unmerged uses of CURRENT_TIME, CURRENT_TIME_SEC, and current_fs_time(). The series also deletes these apis. All the patches except [PATCH 9/12] and [PATCH 10/12] are resend patches. These patches fix new instances of CURRENT_TIME. cifs and ceph patches have been

Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

On Wed, Mar 22, 2017 at 11:35:58AM +0100, Peter Zijlstra wrote: > By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive > at a point where all wait_list modifications are done under both > hb->lock and wait_lock. > > This closes the obvious interleave pattern between

Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

On Wed, Mar 22, 2017 at 11:35:58AM +0100, Peter Zijlstra wrote: > By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive > at a point where all wait_list modifications are done under both > hb->lock and wait_lock. > > This closes the obvious interleave pattern between

[PATCH v2 5/5] perf tools: Refactor the code to strip command name with {l,r}trim()

After reading command name from /proc//status, use ltrim() and rtrim() to strip command name, not using just while loop, isspace() and etc. Cc: David Ahern Cc: Don Zickus Cc: Jiri Olsa Cc: Namhyung Kim

[PATCH v2 5/5] perf tools: Refactor the code to strip command name with {l,r}trim()

After reading command name from /proc//status, use ltrim() and rtrim() to strip command name, not using just while loop, isspace() and etc. Cc: David Ahern Cc: Don Zickus Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Taeung Song --- tools/perf/util/event.c | 11 ++- 1 file changed,

[PATCH v2 4/5] perf pmu: Refactor wordwrap() with ltrim()

Cc: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Taeung Song --- tools/perf/util/pmu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/perf/util/pmu.c

[PATCH v2 4/5] perf pmu: Refactor wordwrap() with ltrim()

Cc: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Taeung Song --- tools/perf/util/pmu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c index 362051e..11c7525 100644 --- a/tools/perf/util/pmu.c +++

  1   2   3   4   5   6   7   8   9   10   >