Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Sat, Mar 05, 2016 at 10:05:48AM +1100, Dave Chinner wrote: > On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > > On Fri, 4 Mar 2016, Dave Hansen wrote: > > > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Sat, Mar 05, 2016 at 10:05:48AM +1100, Dave Chinner wrote: > On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > > On Fri, 4 Mar 2016, Dave Hansen wrote: > > > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov

[PATCH 2/2] drm/rockchip: vop: Fix vop crtc cleanup

This fixes a few problems in the vop crtc cleanup (handling error paths and cleanup upon exit): * The vop_create_crtc() error path had an unsafe version of the iterator used for iterating over all planes (though it was destroying planes in the iterator so should have used the safe version)

[PATCH 2/2] drm/rockchip: vop: Fix vop crtc cleanup

This fixes a few problems in the vop crtc cleanup (handling error paths and cleanup upon exit): * The vop_create_crtc() error path had an unsafe version of the iterator used for iterating over all planes (though it was destroying planes in the iterator so should have used the safe version)

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

The drm_encoder_cleanup() was missing both from the error path of dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was enabled and we ended up deferring probe of HDMI at boot. This call isn't needed from unbind() because if dw_hdmi_bind() returns no error then it takes over the job

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

The drm_encoder_cleanup() was missing both from the error path of dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was enabled and we ended up deferring probe of HDMI at boot. This call isn't needed from unbind() because if dw_hdmi_bind() returns no error then it takes over the job

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:40 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki wrote: >> On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle >> wrote: >>> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote:

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:40 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki wrote: >> On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle >> wrote: >>> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: +void cpufreq_driver_fast_switch(struct cpufreq_policy

[PATCH] steal_account_process_tick() should return jiffies

The callers of steal_account_process_tick() expect it to return whether the last jiffy was stolen or not. Currently the return value of steal_account_process_tick() is in units of cputime, which vary between either jiffies or nsecs depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN. The fix is

[PATCH] steal_account_process_tick() should return jiffies

The callers of steal_account_process_tick() expect it to return whether the last jiffy was stolen or not. Currently the return value of steal_account_process_tick() is in units of cputime, which vary between either jiffies or nsecs depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN. The fix is

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > On Fri, 4 Mar 2016, Dave Hansen wrote: > > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov wrote: > > >> Truncate and punch hole that only cover part of THP range is

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > On Fri, 4 Mar 2016, Dave Hansen wrote: > > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov wrote: > > >> Truncate and punch hole that only cover part of THP range is

Suspicious code in tun_flow_update()

Hello, If tun_flow_find() successfully finds tun_flow_entry, tun_flow_update() updates the entry in place. Is such usage of RCU safe here? Found by Linux Driver Verification project (linuxtesting.org). -- Alexey Khoroshilov Linux Verification Center, ISPRAS

Suspicious code in tun_flow_update()

Hello, If tun_flow_find() successfully finds tun_flow_entry, tun_flow_update() updates the entry in place. Is such usage of RCU safe here? Found by Linux Driver Verification project (linuxtesting.org). -- Alexey Khoroshilov Linux Verification Center, ISPRAS

[PATCH v2] bsp: add SoC driver to brcmstb

From: Justin Chen Value of soc_dev_attributes: family = chip family id soc_id = product id revision = product revision Signed-off-by: Justin Chen --- arch/arm/mach-bcm/Kconfig|1 + drivers/soc/brcmstb/common.c | 58

[PATCH v2] bsp: add SoC driver to brcmstb

From: Justin Chen Value of soc_dev_attributes: family = chip family id soc_id = product id revision = product revision Signed-off-by: Justin Chen --- arch/arm/mach-bcm/Kconfig|1 + drivers/soc/brcmstb/common.c | 58 ++ 2 files changed, 59

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle wrote: >> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: >>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >>> +

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle wrote: >> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: >>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >>> + unsigned int target_freq,

Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

Am 04.03.2016 um 19:23 schrieb Douglas Anderson : > This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on > bcm2835") now that we've found the root cause. See the change > titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"). > > Signed-off-by:

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi Douglas, Am 04.03.2016 um 19:23 schrieb Douglas Anderson : > From testing and trying to make sense of the documentation, it appears > that a 10 ms delay is needed after resetting the core to make sure that > everything is stable and consistent. Let's add it. > > In my

Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

Am 04.03.2016 um 19:23 schrieb Douglas Anderson : > This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on > bcm2835") now that we've found the root cause. See the change > titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()"). > > Signed-off-by: Douglas Anderson

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi Douglas, Am 04.03.2016 um 19:23 schrieb Douglas Anderson : > From testing and trying to make sense of the documentation, it appears > that a 10 ms delay is needed after resetting the core to make sure that > everything is stable and consistent. Let's add it. > > In my testing (on rk3288)

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 02:45:11PM -0800, Paul McKenney wrote: > On Fri, Mar 04, 2016 at 02:38:01PM -0800, Darren Hart wrote: > > On Fri, Mar 04, 2016 at 01:57:20PM -0800, Paul McKenney wrote: > > > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > > > > On Fri, Mar 04, 2016 at

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 4.3.2016 v 23:51 Michal Marek napsal(a): > Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a): >> +cmd_and_fixdep = >> \ >> +$(echo-cmd) $(cmd_$(1)); \ >> +$(ksym_dep_filter) |

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 4.3.2016 v 23:51 Michal Marek napsal(a): > Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a): >> +cmd_and_fixdep = >> \ >> +$(echo-cmd) $(cmd_$(1)); \ >> +$(ksym_dep_filter) |

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 02:45:11PM -0800, Paul McKenney wrote: > On Fri, Mar 04, 2016 at 02:38:01PM -0800, Darren Hart wrote: > > On Fri, Mar 04, 2016 at 01:57:20PM -0800, Paul McKenney wrote: > > > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > > > > On Fri, Mar 04, 2016 at

Re: [PATCH RESEND v2 11/18] fs: Ensure the mounter of a filesystem is privileged towards its inodes

Seth Forshee writes: > On Mon, Jan 04, 2016 at 12:03:50PM -0600, Seth Forshee wrote: >> The mounter of a filesystem should be privileged towards the >> inodes of that filesystem. Extend the checks in >> inode_owner_or_capable() and capable_wrt_inode_uidgid() to >>

Re: [PATCH RESEND v2 11/18] fs: Ensure the mounter of a filesystem is privileged towards its inodes

Seth Forshee writes: > On Mon, Jan 04, 2016 at 12:03:50PM -0600, Seth Forshee wrote: >> The mounter of a filesystem should be privileged towards the >> inodes of that filesystem. Extend the checks in >> inode_owner_or_capable() and capable_wrt_inode_uidgid() to >> permit access by users

Re: [PATCHv3 00/29] huge tmpfs implementation using compound pages

On Thu, Mar 03, 2016 at 11:20:00PM -0500, Sasha Levin wrote: > On 03/03/2016 11:51 AM, Kirill A. Shutemov wrote: > > I consider it feature complete for initial step into upstream. I'll focus > > on validation now. I work with Sasha on that. > > Hey Kirill, > > I see the following two (separate)

Re: [PATCHv3 00/29] huge tmpfs implementation using compound pages

On Thu, Mar 03, 2016 at 11:20:00PM -0500, Sasha Levin wrote: > On 03/03/2016 11:51 AM, Kirill A. Shutemov wrote: > > I consider it feature complete for initial step into upstream. I'll focus > > on validation now. I work with Sasha on that. > > Hey Kirill, > > I see the following two (separate)

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a): > +cmd_and_fixdep = > \ > + $(echo-cmd) $(cmd_$(1)); \ > + $(ksym_dep_filter) | \ > +

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a): > +cmd_and_fixdep = > \ > + $(echo-cmd) $(cmd_$(1)); \ > + $(ksym_dep_filter) | \ > +

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > On Fri, 4 Mar 2016, Dave Hansen wrote: > > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov wrote: > > >> Truncate and punch hole that only cover part of THP range is

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > On Fri, 4 Mar 2016, Dave Hansen wrote: > > On 03/04/2016 03:26 AM, Kirill A. Shutemov wrote: > > > On Thu, Mar 03, 2016 at 07:51:50PM +0300, Kirill A. Shutemov wrote: > > >> Truncate and punch hole that only cover part of THP range is

[PATCH] udp6: fix UDP/IPv6 encap resubmit path

IPv4 interprets a negative return value from a protocol handler as a request to redispatch to a new protocol. In contrast, IPv6 interprets a negative value as an error, and interprets a positive value as a request for redispatch. UDP for IPv6 was unaware of this difference. Change

[PATCH] udp6: fix UDP/IPv6 encap resubmit path

IPv4 interprets a negative return value from a protocol handler as a request to redispatch to a new protocol. In contrast, IPv6 interprets a negative value as an error, and interprets a positive value as a request for redispatch. UDP for IPv6 was unaware of this difference. Change

[PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

The current documentation refers to using set_memory_wc() as a possible hole strategy when you have overlapping ioremap() regions, that's incorrect as set_memory_*() helpers can only be used on RAM, not IO memory. Using set_memory_wc() will not fail, that's a problem which must be corrected in the

[PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

The current documentation refers to using set_memory_wc() as a possible hole strategy when you have overlapping ioremap() regions, that's incorrect as set_memory_*() helpers can only be used on RAM, not IO memory. Using set_memory_wc() will not fail, that's a problem which must be corrected in the

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 02:38:01PM -0800, Darren Hart wrote: > On Fri, Mar 04, 2016 at 01:57:20PM -0800, Paul McKenney wrote: > > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > > > On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > > > > On Fri, Mar 4, 2016 at 1:05 AM,

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 02:38:01PM -0800, Darren Hart wrote: > On Fri, Mar 04, 2016 at 01:57:20PM -0800, Paul McKenney wrote: > > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > > > On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > > > > On Fri, Mar 4, 2016 at 1:05 AM,

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle wrote: >> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: >>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >>> +

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle wrote: >> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: >>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >>> + unsigned int target_freq,

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 01:57:20PM -0800, Paul McKenney wrote: > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > > On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > > > On Fri, Mar 4, 2016 at 1:05 AM, Darren Hart wrote: > > > > I thought I

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 01:57:20PM -0800, Paul McKenney wrote: > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > > On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > > > On Fri, Mar 4, 2016 at 1:05 AM, Darren Hart wrote: > > > > I thought I provided a corrected comment

Re: [PATCHv2 0/3] KASAN: clean stale poison upon cold re-entry to kernel

On Thu, 3 Mar 2016 16:54:25 + Mark Rutland wrote: > Andrew, the conclusion [5] from v1 was that this should go via the mm tree. > Are you happy to pick this up? yep. I'll aim to get this into 4.5.

Re: [PATCHv2 0/3] KASAN: clean stale poison upon cold re-entry to kernel

On Thu, 3 Mar 2016 16:54:25 + Mark Rutland wrote: > Andrew, the conclusion [5] from v1 was that this should go via the mm tree. > Are you happy to pick this up? yep. I'll aim to get this into 4.5.

[ANNOUNCE] Git v2.8.0-rc1

A release candidate Git v2.8.0-rc1 is now available for testing at the usual places. It is comprised of 453 non-merge commits since v2.7.0, contributed by 59 people, 19 of which are new faces. There still is a known regression around "git status" (and "ls-files -o") relative to v2.7.2, which we

[ANNOUNCE] Git v2.8.0-rc1

A release candidate Git v2.8.0-rc1 is now available for testing at the usual places. It is comprised of 453 non-merge commits since v2.7.0, contributed by 59 people, 19 of which are new faces. There still is a known regression around "git status" (and "ls-files -o") relative to v2.7.2, which we

[PATCH v7 1/3] PCI: generic: Refactor code to enable reuse by other drivers.

From: David Daney No change in functionality. Move structure definitions into a separate header file. Move common code to new file with Kconfig machinery to build it. Split probe function in to two parts: - a small driver specific probe function (gen_pci_probe)

[PATCH v7 1/3] PCI: generic: Refactor code to enable reuse by other drivers.

From: David Daney No change in functionality. Move structure definitions into a separate header file. Move common code to new file with Kconfig machinery to build it. Split probe function in to two parts: - a small driver specific probe function (gen_pci_probe) - a common probe that

[PATCH v7 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass{1,2} on-chip devices

From: David Daney The cavium,pci-thunder-ecam devices are exactly ECAM based PCI root complexes. These root complexes (loosely referred to as ECAM units in the hardware manuals) are used to access the Thunder on-chips devices. They are special in that all the BARs on

Re: [PATCH 00/13] RxRPC: Rewrite part 1

David Miller wrote: > Can you go through and use "unsigned int" instead of just plain > "unsigned" in the RxRPC code? Do you mind if I leave it to after the rewrite? I don't particularly want to have to rejig all the patches I have. David

[PATCH v7 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass{1,2} on-chip devices

From: David Daney The cavium,pci-thunder-ecam devices are exactly ECAM based PCI root complexes. These root complexes (loosely referred to as ECAM units in the hardware manuals) are used to access the Thunder on-chips devices. They are special in that all the BARs on devices behind these root

Re: [PATCH 00/13] RxRPC: Rewrite part 1

David Miller wrote: > Can you go through and use "unsigned int" instead of just plain > "unsigned" in the RxRPC code? Do you mind if I leave it to after the rewrite? I don't particularly want to have to rejig all the patches I have. David

[PATCH v7 2/3] pci, pci-thunder-pem: Add PCIe host driver for ThunderX processors.

From: David Daney The root complexes used to access off-chip PCIe devices (called PEM units in the hardware manuals) on some Cavium ThunderX processors require quirky access methods for the config space of the PCIe bridge. Add a driver to provide these config space

[PATCH v7 2/3] pci, pci-thunder-pem: Add PCIe host driver for ThunderX processors.

From: David Daney The root complexes used to access off-chip PCIe devices (called PEM units in the hardware manuals) on some Cavium ThunderX processors require quirky access methods for the config space of the PCIe bridge. Add a driver to provide these config space accessor functions. The

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle wrote: > On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: >> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >> + unsigned int target_freq, unsigned int >> relation) >> +{ >> +

[PATCH v7 0/3] Add host controller drivers for Cavium ThunderX PCI

From: David Daney Some Cavium ThunderX processors require quirky access methods for the config space of the PCIe bridge. There are now three patches: 1) Refactor code in pci-host-generic so that it can more easily be used by other drivers. This splits the driver for

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle wrote: > On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: >> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >> + unsigned int target_freq, unsigned int >> relation) >> +{ >> + unsigned int freq; >> +

[PATCH v7 0/3] Add host controller drivers for Cavium ThunderX PCI

From: David Daney Some Cavium ThunderX processors require quirky access methods for the config space of the PCIe bridge. There are now three patches: 1) Refactor code in pci-host-generic so that it can more easily be used by other drivers. This splits the driver for CAM and ECAM access

Re: [PATCH 27/41] clk: fixed-rate: Remove CLK_IS_ROOT

On 03/01, Stephen Boyd wrote: > This flag is a no-op now. Remove usage of the flag. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 27/41] clk: fixed-rate: Remove CLK_IS_ROOT

On 03/01, Stephen Boyd wrote: > This flag is a no-op now. Remove usage of the flag. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: headsup: random memory corruption on 4.5-rc5

On Fri, Mar 4, 2016 at 1:44 PM, Dave Airlie wrote: > > [ cut here ] > kernel BUG at mm/slub.c:3625! Yeah, not a lot to go on. That case should probably use VM_BUG_ON_PAGE() to five a little more information, but on the whole it's does look like just

Re: headsup: random memory corruption on 4.5-rc5

On Fri, Mar 4, 2016 at 1:44 PM, Dave Airlie wrote: > > [ cut here ] > kernel BUG at mm/slub.c:3625! Yeah, not a lot to go on. That case should probably use VM_BUG_ON_PAGE() to five a little more information, but on the whole it's does look like just major memory

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev wrote: > This patch implements the SS_AUTODISARM flag that can be ORed with > SS_ONSTACK when forming ss_flags. > When this flag is set, sigaltstack will be disabled when entering > the signal handler; more precisely, after saving sas to

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev wrote: > This patch implements the SS_AUTODISARM flag that can be ORed with > SS_ONSTACK when forming ss_flags. > When this flag is set, sigaltstack will be disabled when entering > the signal handler; more precisely, after saving sas to uc_stack. >

Re: [PATCH] kbuild: suppress annoying "... is up to date." message

On Thu, Mar 03, 2016 at 05:36:30PM +0900, Masahiro Yamada wrote: > Under certain conditions, Kbuild shows "... is up to date" where > if_changed or friends are used. > > For example, the incremental build of ARM64 Linux shows this message > when the kernel image has not been updated. > > $

Re: [PATCH] kbuild: suppress annoying "... is up to date." message

On Thu, Mar 03, 2016 at 05:36:30PM +0900, Masahiro Yamada wrote: > Under certain conditions, Kbuild shows "... is up to date" where > if_changed or friends are used. > > For example, the incremental build of ARM64 Linux shows this message > when the kernel image has not been updated. > > $

Re: [PATCH 00/13] RxRPC: Rewrite part 1

et reception/generation stage. > > The patches can be found here also: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite > > Tagged thusly: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git &g

Re: [PATCH 00/13] RxRPC: Rewrite part 1

tage. > > The patches can be found here also: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite > > Tagged thusly: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-rewrite-201

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: > +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, > + unsigned int target_freq, unsigned int relation) > +{ > + unsigned int freq; > + > + freq = cpufreq_driver->fast_switch(policy, target_freq,

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: > +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, > + unsigned int target_freq, unsigned int relation) > +{ > + unsigned int freq; > + > + freq = cpufreq_driver->fast_switch(policy, target_freq,

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On Fri, Mar 4, 2016 at 12:56 PM, Dmitry Torokhov wrote: > On Fri, Mar 04, 2016 at 03:41:36PM -0500, Evan McClain wrote: >> On Fri, 2016-03-04 at 11:13 -0800, Dmitry Torokhov wrote: >> > On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: >> > > >> > > Hi

[git pull] drm fixes

Hi Linus, Hopefully not too big, I've held off on some vc4 fixes that came in that I think can wait next window. This contains one i915 patch twice, as I merged it locally for testing, and then pulled some stuff in on top, and then Jani sent to me, I didn't think it was worth redoing all the

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On Fri, Mar 4, 2016 at 12:56 PM, Dmitry Torokhov wrote: > On Fri, Mar 04, 2016 at 03:41:36PM -0500, Evan McClain wrote: >> On Fri, 2016-03-04 at 11:13 -0800, Dmitry Torokhov wrote: >> > On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: >> > > >> > > Hi Evan, >> > > >> > > On

[git pull] drm fixes

Hi Linus, Hopefully not too big, I've held off on some vc4 fixes that came in that I think can wait next window. This contains one i915 patch twice, as I merged it locally for testing, and then pulled some stuff in on top, and then Jani sent to me, I didn't think it was worth redoing all the

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > > On Fri, Mar 4, 2016 at 1:05 AM, Darren Hart wrote: > > > I thought I provided a corrected comment block maybe I didn't. We > > > have been > >

[GIT PULL] libata fixes for v4.5-rc6

Hello, Linus. Assorted fixes for libata drivers. * Turns out HDIO_GET_32BIT ioctl was subtly broken all along. * Recent update to ahci external port handling was incorrectly marking hotpluggable ports as external making userland handle devices connected to those ports incorrectly. *

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

On Fri, Mar 04, 2016 at 01:05:24PM -0800, Darren Hart wrote: > On Fri, Mar 04, 2016 at 09:12:31AM +0800, Jianyu Zhan wrote: > > On Fri, Mar 4, 2016 at 1:05 AM, Darren Hart wrote: > > > I thought I provided a corrected comment block maybe I didn't. We > > > have been > > > working on

[GIT PULL] libata fixes for v4.5-rc6

Hello, Linus. Assorted fixes for libata drivers. * Turns out HDIO_GET_32BIT ioctl was subtly broken all along. * Recent update to ahci external port handling was incorrectly marking hotpluggable ports as external making userland handle devices connected to those ports incorrectly. *

Re: [PATCH] ARM: LLVMLinux: Change "extern inline" to "static inline" in mpi-inline.h and mpi-internal.h

Hi, >Can you be more specific about which compiler you use? > >I had seen this problem with prerelease gcc-5.0 versions, but >I don't see it with 5.1.1, 5.2.1 or 5.3.1. $ arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabi-gcc

Re: [PATCH] ARM: LLVMLinux: Change "extern inline" to "static inline" in mpi-inline.h and mpi-internal.h

Hi, >Can you be more specific about which compiler you use? > >I had seen this problem with prerelease gcc-5.0 versions, but >I don't see it with 5.1.1, 5.2.1 or 5.3.1. $ arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabi-gcc

[GIT PULL] Block fixes for 4.5-final

Hi Linus, Round 2 of this. I cut back to the bare necessities, the patch is still larger than it usually would be at this time, due to the number of NVMe fixes in there. This pull request contains: - The 4 core fixes from Ming, that fix both problems with exceeding the virtual boundary limit

[GIT PULL] Block fixes for 4.5-final

Hi Linus, Round 2 of this. I cut back to the bare necessities, the patch is still larger than it usually would be at this time, due to the number of NVMe fixes in there. This pull request contains: - The 4 core fixes from Ming, that fix both problems with exceeding the virtual boundary limit

Re: [PATCH v2 2/8] perf tools: Introduce perf_hpp__setup_hists_formats()

Em Fri, Mar 04, 2016 at 06:58:22PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Mar 04, 2016 at 11:59:36PM +0900, Namhyung Kim escreveu: > > The perf_hpp__setup_hists_formats() is to build hists-specific output > > formats (and sort keys). Currently it's only used in order to build the > >

Re: [PATCH v2 2/8] perf tools: Introduce perf_hpp__setup_hists_formats()

Em Fri, Mar 04, 2016 at 11:59:36PM +0900, Namhyung Kim escreveu: > The perf_hpp__setup_hists_formats() is to build hists-specific output > formats (and sort keys). Currently it's only used in order to build the > output format in a hierarchy with same sort keys, but it could be used > with

Re: [PATCH v2 2/8] perf tools: Introduce perf_hpp__setup_hists_formats()

Em Fri, Mar 04, 2016 at 11:59:36PM +0900, Namhyung Kim escreveu: > The perf_hpp__setup_hists_formats() is to build hists-specific output > formats (and sort keys). Currently it's only used in order to build the > output format in a hierarchy with same sort keys, but it could be used > with

Re: [PATCH v2 2/8] perf tools: Introduce perf_hpp__setup_hists_formats()

Em Fri, Mar 04, 2016 at 06:58:22PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Mar 04, 2016 at 11:59:36PM +0900, Namhyung Kim escreveu: > > The perf_hpp__setup_hists_formats() is to build hists-specific output > > formats (and sort keys). Currently it's only used in order to build the > >

Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal

Dne 2.3.2016 v 15:28 Paolo Abeni napsal(a): > This patch add a rpm preuninstall scriptlet to cleanup the > boot loader configuration on kernel package uninstall. > The initrd for the to-be-removed kernel is deleted, too. > > Signed-off-by: Paolo Abeni Applied to

Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal

Dne 2.3.2016 v 15:28 Paolo Abeni napsal(a): > This patch add a rpm preuninstall scriptlet to cleanup the > boot loader configuration on kernel package uninstall. > The initrd for the to-be-removed kernel is deleted, too. > > Signed-off-by: Paolo Abeni Applied to kbuild.git#misc. Michal

Re: [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc

Hi Petr, On Thu, Mar 03, 2016 at 05:52:01PM +0100, Petr Mladek wrote: > From: Balbir Singh > > Changelog v4: > 1. Renamed klp_matchaddr() to klp_get_ftrace_location() > and used it just to convert the function address. > 2. Synced

Re: [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc

Hi Petr, On Thu, Mar 03, 2016 at 05:52:01PM +0100, Petr Mladek wrote: > From: Balbir Singh > > Changelog v4: > 1. Renamed klp_matchaddr() to klp_get_ftrace_location() > and used it just to convert the function address. > 2. Synced klp_write_module_reloc() with s390(); made

Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal

Dne 3.3.2016 v 10:09 Paolo Abeni napsal(a): > I'm sorry, I try to dig a bit, but I did not find any distro agnostic > kernel removal tools. Can you please point out some ? There isn't any, so unfortunately we need a list of various distro-specific methods, starting with ew-kernel-pkg. The %post

Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal

Dne 3.3.2016 v 10:09 Paolo Abeni napsal(a): > I'm sorry, I try to dig a bit, but I did not find any distro agnostic > kernel removal tools. Can you please point out some ? There isn't any, so unfortunately we need a list of various distro-specific methods, starting with ew-kernel-pkg. The %post

Re: [PATCH v2 4/8] perf tools: Support multiple sort keys in a hierarchy level

Em Fri, Mar 04, 2016 at 11:59:38PM +0900, Namhyung Kim escreveu: > This implements having multiple sort keys in a single hierarchy level. > +++ b/tools/perf/util/sort.c > @@ -2310,18 +2310,40 @@ static int setup_sort_list(char *str, struct > perf_evlist *evlist) > char *tmp, *tok; >

Re: [PATCH v2 4/8] perf tools: Support multiple sort keys in a hierarchy level

Em Fri, Mar 04, 2016 at 11:59:38PM +0900, Namhyung Kim escreveu: > This implements having multiple sort keys in a single hierarchy level. > +++ b/tools/perf/util/sort.c > @@ -2310,18 +2310,40 @@ static int setup_sort_list(char *str, struct > perf_evlist *evlist) > char *tmp, *tok; >

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On 03/04/2016 09:59 PM, Dmitry Torokhov wrote: On Fri, Mar 04, 2016 at 09:55:24PM +0100, Jacek Anaszewski wrote: On 03/04/2016 08:13 PM, Dmitry Torokhov wrote: On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: Hi Evan, On 03/04/2016 09:38 AM, Evan McClain wrote: On Thu,

Re: [PATCH] leds: Add Chrome OS keyboard backlight LEDs driver

On 03/04/2016 09:59 PM, Dmitry Torokhov wrote: On Fri, Mar 04, 2016 at 09:55:24PM +0100, Jacek Anaszewski wrote: On 03/04/2016 08:13 PM, Dmitry Torokhov wrote: On Fri, Mar 04, 2016 at 10:38:40AM +0100, Jacek Anaszewski wrote: Hi Evan, On 03/04/2016 09:38 AM, Evan McClain wrote: On Thu,

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

> +Required properties: > + > +- compatible: Must be: > + - Tegra124: "nvidia,tegra124-xusb-padctl" > + - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl" > +- reg: Physical base address and length of the controller's registers. > +- resets: Must contain

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

> +Required properties: > + > +- compatible: Must be: > + - Tegra124: "nvidia,tegra124-xusb-padctl" > + - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl" > +- reg: Physical base address and length of the controller's registers. > +- resets: Must contain

<    1   2   3   4   5   6   7   8   9   10   >