Re: [PATCH 0/3] selftests: sync test conversion to TAP13

On 07/28/2017 12:25 PM, Gustavo Padovan wrote: > Hi Shuah, > > Thank you for your patches. > > On Mon, 2017-07-24 at 15:07 -0600, Shuah Khan wrote: >> This patch series includes patches to convert sync test to use TAP13 >> ksft framework. In addition, fix to sync test to differentiate >> between

Re: [PATCH 0/3] selftests: sync test conversion to TAP13

On 07/28/2017 12:25 PM, Gustavo Padovan wrote: > Hi Shuah, > > Thank you for your patches. > > On Mon, 2017-07-24 at 15:07 -0600, Shuah Khan wrote: >> This patch series includes patches to convert sync test to use TAP13 >> ksft framework. In addition, fix to sync test to differentiate >> between

Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync

On 2017-07-28 02:28, Peter Zijlstra wrote: On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: I think we should have this discussion now - I brought this up earlier [1] and I promised a test case that I completely forgot about - but here it is (attached). Essentially a Big CPU

Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync

On 2017-07-28 02:28, Peter Zijlstra wrote: On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: I think we should have this discussion now - I brought this up earlier [1] and I promised a test case that I completely forgot about - but here it is (attached). Essentially a Big CPU

Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync

On 2017-07-28 02:28, Will Deacon wrote: On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: I think we should have this discussion now - I brought this up earlier [1] and I promised a test case that I completely forgot about - but here it is (attached). Essentially a Big

Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync

On 2017-07-28 02:28, Will Deacon wrote: On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: I think we should have this discussion now - I brought this up earlier [1] and I promised a test case that I completely forgot about - but here it is (attached). Essentially a Big

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-07-28 19:48 GMT+03:00 Will Deacon : > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: >> vDSO VMA address is saved in mm_context for the purpose of using >> restorer from vDSO page to return to userspace after signal handling. >> >> In Checkpoint Restore

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-07-28 19:48 GMT+03:00 Will Deacon : > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: >> vDSO VMA address is saved in mm_context for the purpose of using >> restorer from vDSO page to return to userspace after signal handling. >> >> In Checkpoint Restore in Userspace (CRIU)

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 06:29:57PM +, Levin, Alexander (Sasha Levin) wrote: > On Fri, Jul 28, 2017 at 12:52:34PM -0500, Josh Poimboeuf wrote: > >On Fri, Jul 28, 2017 at 04:48:47PM +, Levin, Alexander (Sasha Levin) > >wrote: > >> Hey Josh, > >> > >> Syzkaller seems to trigger the

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 06:29:57PM +, Levin, Alexander (Sasha Levin) wrote: > On Fri, Jul 28, 2017 at 12:52:34PM -0500, Josh Poimboeuf wrote: > >On Fri, Jul 28, 2017 at 04:48:47PM +, Levin, Alexander (Sasha Levin) > >wrote: > >> Hey Josh, > >> > >> Syzkaller seems to trigger the

Re: [PATCH] PM / Domains: Ensure genpd name is set before creating debugfs entry

Hi, On 07/28/2017 01:48 PM, Dave Gerlach wrote: > Commit b6a1d093f96b ("PM / Domains: Extend generic power domain > debugfs") extends the existing generic power domain debugfs to provide > more information about each genpd, however it creates a debugfs > directory for each based on the name of the

Re: [PATCH] PM / Domains: Ensure genpd name is set before creating debugfs entry

Hi, On 07/28/2017 01:48 PM, Dave Gerlach wrote: > Commit b6a1d093f96b ("PM / Domains: Extend generic power domain > debugfs") extends the existing generic power domain debugfs to provide > more information about each genpd, however it creates a debugfs > directory for each based on the name of the

[RESEND PATCH 4/6] ipc: sem: Make sem_array timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interface themselves

[RESEND PATCH 4/6] ipc: sem: Make sem_array timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interface themselves

[PATCH] drivers/serial: Do not leave sysfs group in case of error in aspeed_vuart_probe()

There are several error handling paths in aspeed_vuart_probe(), where sysfs group is left unremoved. The patch fixes them. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/tty/serial/8250/8250_aspeed_vuart.c | 7

[PATCH] drivers/serial: Do not leave sysfs group in case of error in aspeed_vuart_probe()

There are several error handling paths in aspeed_vuart_probe(), where sysfs group is left unremoved. The patch fixes them. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/tty/serial/8250/8250_aspeed_vuart.c | 7 +-- 1 file

[RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

struct timespec is not y2038 safe. Replace all uses of timespec by y2038 safe struct timespec64. Even though timespec is used here to represent timeouts, replace these with timespec64 so that it facilitates in verification by creating a y2038 safe kernel image that is free of timespec. The

[RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

struct timespec is not y2038 safe. Replace all uses of timespec by y2038 safe struct timespec64. Even though timespec is used here to represent timeouts, replace these with timespec64 so that it facilitates in verification by creating a y2038 safe kernel image that is free of timespec. The

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

On 07/28/2017 01:33 PM, Oliver Hartkopp wrote: > Hi Kurt, > > On 07/28/2017 03:02 PM, Kurt Van Dijck wrote: > The word 'max-arbitration-bitrate' makes the difference very clear. >>> >>> I think you are mixing up ISO layer 1 and ISO layer 2. >> >> In order to provide higher data throughput

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

On 07/28/2017 01:33 PM, Oliver Hartkopp wrote: > Hi Kurt, > > On 07/28/2017 03:02 PM, Kurt Van Dijck wrote: > The word 'max-arbitration-bitrate' makes the difference very clear. >>> >>> I think you are mixing up ISO layer 1 and ISO layer 2. >> >> In order to provide higher data throughput

[RESEND PATCH 5/6] ipc: shm: Make shmid_kernel timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats

Quoting Eric Anholt (2017-07-25 19:27:25) > Chris Wilson writes: > > > Quoting Eric Anholt (2017-06-22 21:50:54) > >> This has proven immensely useful for debugging memory leaks and > >> overallocation (which is a rather serious concern on the platform, > >> given that

[RESEND PATCH 5/6] ipc: shm: Make shmid_kernel timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats

Quoting Eric Anholt (2017-07-25 19:27:25) > Chris Wilson writes: > > > Quoting Eric Anholt (2017-06-22 21:50:54) > >> This has proven immensely useful for debugging memory leaks and > >> overallocation (which is a rather serious concern on the platform, > >> given that we typically run at about

[RESEND 0/6] Make ipc y2038 safe

Resending to fix mail subject header. The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with timespec64

[RESEND 0/6] Make ipc y2038 safe

Resending to fix mail subject header. The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with timespec64

[RESEND PATCH 6/6] utimes: Make utimes y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interfaces. This will be part of a separate series. Signed-off-by: Deepa Dinamani ---

[RESEND PATCH 6/6] utimes: Make utimes y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interfaces. This will be part of a separate series. Signed-off-by: Deepa Dinamani --- fs/utimes.c | 23

[RESEND PATCH 3/6] ipc: msg: Make msg_queue timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

[RESEND PATCH 1/6] ipc: Make sys_semtimedop() y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interface. This will be part of a separate series. Signed-off-by: Deepa Dinamani ---

[RESEND PATCH 3/6] ipc: msg: Make msg_queue timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

[RESEND PATCH 1/6] ipc: Make sys_semtimedop() y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interface. This will be part of a separate series. Signed-off-by: Deepa Dinamani --- ipc/sem.c | 12

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 10:48 +0200, Borislav Petkov wrote: > From: Borislav Petkov > > Register with the GHES notifier chain so that there's no need to call > into the module with ghes_edac_report_mem_error(). > > Signed-off-by: Borislav Petkov : > +static int

Re: [PATCH net] net: phy: Run state machine to completion

On 07/28/2017 03:57 AM, Marc Gonzalez wrote: > On 26/07/2017 21:24, Florian Fainelli wrote: > >> Marc reported that he was not getting the PHY library adjust_link() >> callback function to run when calling phy_stop() + phy_disconnect() >> which does not indeed happen because we don't make sure we

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

On Wed, 2017-07-26 at 10:48 +0200, Borislav Petkov wrote: > From: Borislav Petkov > > Register with the GHES notifier chain so that there's no need to call > into the module with ghes_edac_report_mem_error(). > > Signed-off-by: Borislav Petkov : > +static int report_mem_error(struct

Re: [PATCH net] net: phy: Run state machine to completion

On 07/28/2017 03:57 AM, Marc Gonzalez wrote: > On 26/07/2017 21:24, Florian Fainelli wrote: > >> Marc reported that he was not getting the PHY library adjust_link() >> callback function to run when calling phy_stop() + phy_disconnect() >> which does not indeed happen because we don't make sure we

[PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

The APM X-Gene PCIe root port does not support ACS at this point. However, the hw provides isolation and source validation through the SMMU. The stream ID generated by the PCIe ports contain both the BDF as well as the port ID in its 3 most significant bits. Turn on ACS but disable all the peer to

[PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

The APM X-Gene PCIe root port does not support ACS at this point. However, the hw provides isolation and source validation through the SMMU. The stream ID generated by the PCIe ports contain both the BDF as well as the port ID in its 3 most significant bits. Turn on ACS but disable all the peer to

[PATCH] PM / Domains: Ensure genpd name is set before creating debugfs entry

Commit b6a1d093f96b ("PM / Domains: Extend generic power domain debugfs") extends the existing generic power domain debugfs to provide more information about each genpd, however it creates a debugfs directory for each based on the name of the genpd. While it is a good idea to populate the name

[PATCH] PM / Domains: Ensure genpd name is set before creating debugfs entry

Commit b6a1d093f96b ("PM / Domains: Extend generic power domain debugfs") extends the existing generic power domain debugfs to provide more information about each genpd, however it creates a debugfs directory for each based on the name of the genpd. While it is a good idea to populate the name

Re: [RFC PATCH 0/4] serial: uartps: Dynamic allocation

On Fri, 21 Jul 2017 11:32:23 +0200 Michal Simek wrote: > Hi Alan, > > this is the initial version before next step which is move > uart_register_driver to probe function. > I was able to get rid of static array with uart_port structures. > It was wired with console

Re: [RFC PATCH 0/4] serial: uartps: Dynamic allocation

On Fri, 21 Jul 2017 11:32:23 +0200 Michal Simek wrote: > Hi Alan, > > this is the initial version before next step which is move > uart_register_driver to probe function. > I was able to get rid of static array with uart_port structures. > It was wired with console which is also fixed. > And

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

On Fri, Jul 28, 2017 at 7:23 AM, Tom Bogendoerfer wrote: > On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote: >> I don't know the intricacies of the Mustang hardware but external >> aborts have been a symptom of missing clocks on other hardware. > > you are

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

On Fri, Jul 28, 2017 at 7:23 AM, Tom Bogendoerfer wrote: > On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote: >> I don't know the intricacies of the Mustang hardware but external >> aborts have been a symptom of missing clocks on other hardware. > > you are right, it's a missing clock.

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: David Miller Date: Fri, 28 Jul 2017 11:27:41 -0700 (PDT) > From: Mikael Pettersson > Date: Fri, 28 Jul 2017 10:45:15 +0200 > >> David Miller writes: >> > From: Mikael Pettersson >> > Date: Thu, 27 Jul 2017 21:45:25 +0200

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: David Miller Date: Fri, 28 Jul 2017 11:27:41 -0700 (PDT) > From: Mikael Pettersson > Date: Fri, 28 Jul 2017 10:45:15 +0200 > >> David Miller writes: >> > From: Mikael Pettersson >> > Date: Thu, 27 Jul 2017 21:45:25 +0200 >> > >> > > Attempting to build strace-4.18 as sparcv9 code

[PATCH v3 1/5] fs/dcache: Limit numbers of negative dentries

The number of positive dentries is limited by the number of files in the filesystems. The number of negative dentries, however, has no limit other than the total amount of memory available in the system. So a rogue application that generates a lot of negative dentries can potentially exhaust most

[PATCH v3 1/5] fs/dcache: Limit numbers of negative dentries

The number of positive dentries is limited by the number of files in the filesystems. The number of negative dentries, however, has no limit other than the total amount of memory available in the system. So a rogue application that generates a lot of negative dentries can potentially exhaust most

[PATCH v3 4/5] fs/dcache: Protect negative dentry pruning from racing with umount

The negative dentry pruning is done on a specific super_block set in the ndblk.prune_sb variable. If the super_block is also being un-mounted concurrently, the content of the super_block may no longer be valid. To protect against such racing condition, a new lock is added to the ndblk structure

[PATCH v3 4/5] fs/dcache: Protect negative dentry pruning from racing with umount

The negative dentry pruning is done on a specific super_block set in the ndblk.prune_sb variable. If the super_block is also being un-mounted concurrently, the content of the super_block may no longer be valid. To protect against such racing condition, a new lock is added to the ndblk structure

[PATCH v3 2/5] fs/dcache: Report negative dentry number in dentry-state

The number of negative dentries currently in the system is now reported in the /proc/sys/fs/dentry-state file. Signed-off-by: Waiman Long --- fs/dcache.c| 16 +++- include/linux/dcache.h | 7 --- 2 files changed, 19 insertions(+), 4 deletions(-)

[PATCH v3 2/5] fs/dcache: Report negative dentry number in dentry-state

The number of negative dentries currently in the system is now reported in the /proc/sys/fs/dentry-state file. Signed-off-by: Waiman Long --- fs/dcache.c| 16 +++- include/linux/dcache.h | 7 --- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git

[PATCH v3 5/5] fs/dcache: Track count of negative dentries forcibly killed

There is performance concern about killing recently created negative dentries. This should rarely happen under normal working condition. To understand the extent of how often this negative dentry killing is happening, the /proc/sys/fs/denty-state file is extended to track this number. This allows

[PATCH v3 5/5] fs/dcache: Track count of negative dentries forcibly killed

There is performance concern about killing recently created negative dentries. This should rarely happen under normal working condition. To understand the extent of how often this negative dentry killing is happening, the /proc/sys/fs/denty-state file is extended to track this number. This allows

[PATCH v3 3/5] fs/dcache: Enable automatic pruning of negative dentries

Having a limit for the number of negative dentries may have an undesirable side effect that no new negative dentries will be allowed when the limit is reached. This may have a performance impact on some workloads. To prevent this from happening, we need a way to prune the negative dentries so

[PATCH v3 3/5] fs/dcache: Enable automatic pruning of negative dentries

Having a limit for the number of negative dentries may have an undesirable side effect that no new negative dentries will be allowed when the limit is reached. This may have a performance impact on some workloads. To prevent this from happening, we need a way to prune the negative dentries so

[PATCH v3 0/5] fs/dcache: Limit # of negative dentries

v2->v3: - Add a faster pruning rate when the free pool is closed to depletion. - As suggested by James Bottomley, add an artificial delay waiting loop before killing a negative dentry and properly clear the DCACHE_KILL_NEGATIVE flag if killing doesn't happen. - Add a new patch to

[PATCH v3 0/5] fs/dcache: Limit # of negative dentries

v2->v3: - Add a faster pruning rate when the free pool is closed to depletion. - As suggested by James Bottomley, add an artificial delay waiting loop before killing a negative dentry and properly clear the DCACHE_KILL_NEGATIVE flag if killing doesn't happen. - Add a new patch to

Re: [RFC 06/12] Clk: qcom: support for dynamic updating the PLL

On 07/27, Abhishek Sahu wrote: > Some of the Alpha PLL’s support dynamic update in which the > frequency can be changed dynamically without turning off the PLL. > > This dynamic update requires the following sequence > > 1. Write the desired values to pll_l_val and pll_alpha_val. > 2. Toggle

Re: [RFC 06/12] Clk: qcom: support for dynamic updating the PLL

On 07/27, Abhishek Sahu wrote: > Some of the Alpha PLL’s support dynamic update in which the > frequency can be changed dynamically without turning off the PLL. > > This dynamic update requires the following sequence > > 1. Write the desired values to pll_l_val and pll_alpha_val. > 2. Toggle

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

Hi Kurt, On 07/28/2017 03:02 PM, Kurt Van Dijck wrote: The word 'max-arbitration-bitrate' makes the difference very clear. I think you are mixing up ISO layer 1 and ISO layer 2. In order to provide higher data throughput without putting extra limits on transceiver & wire, the requirement

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

Hi Kurt, On 07/28/2017 03:02 PM, Kurt Van Dijck wrote: The word 'max-arbitration-bitrate' makes the difference very clear. I think you are mixing up ISO layer 1 and ISO layer 2. In order to provide higher data throughput without putting extra limits on transceiver & wire, the requirement

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

On Thu, 27 Jul 2017, Zdenek Kabelac wrote: > > Zdenek, you check this explanation by commenting out these last two > > lines at the end of hub_port_connect() in drivers/usb/core/hub.c: > > > > if (hcd->driver->relinquish_port && !hub->hdev->parent) > >

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

On Thu, 27 Jul 2017, Zdenek Kabelac wrote: > > Zdenek, you check this explanation by commenting out these last two > > lines at the end of hub_port_connect() in drivers/usb/core/hub.c: > > > > if (hcd->driver->relinquish_port && !hub->hdev->parent) > >

Re: [RFC 02/12] clk: qcom: flag for 64 bit CONFIG_CTL

On 07/27, Abhishek Sahu wrote: > diff --git a/drivers/clk/qcom/clk-alpha-pll.c > b/drivers/clk/qcom/clk-alpha-pll.c > index 47a1da3..e6cde2d 100644 > --- a/drivers/clk/qcom/clk-alpha-pll.c > +++ b/drivers/clk/qcom/clk-alpha-pll.c > @@ -118,7 +118,10 @@ void clk_alpha_pll_configure(struct

Re: [RFC 02/12] clk: qcom: flag for 64 bit CONFIG_CTL

On 07/27, Abhishek Sahu wrote: > diff --git a/drivers/clk/qcom/clk-alpha-pll.c > b/drivers/clk/qcom/clk-alpha-pll.c > index 47a1da3..e6cde2d 100644 > --- a/drivers/clk/qcom/clk-alpha-pll.c > +++ b/drivers/clk/qcom/clk-alpha-pll.c > @@ -118,7 +118,10 @@ void clk_alpha_pll_configure(struct

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 12:52:34PM -0500, Josh Poimboeuf wrote: >On Fri, Jul 28, 2017 at 04:48:47PM +, Levin, Alexander (Sasha Levin) wrote: >> Hey Josh, >> >> Syzkaller seems to trigger the following: >> >> == >> BUG: KASAN:

Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder

On Fri, Jul 28, 2017 at 12:52:34PM -0500, Josh Poimboeuf wrote: >On Fri, Jul 28, 2017 at 04:48:47PM +, Levin, Alexander (Sasha Levin) wrote: >> Hey Josh, >> >> Syzkaller seems to trigger the following: >> >> == >> BUG: KASAN:

Re: [PATCH] livepatch: add (un)patch hooks

On Fri, Jul 28, 2017 at 02:08:33PM -0400, Joe Lawrence wrote: > On 07/27/2017 05:36 PM, Josh Poimboeuf wrote: > > On Thu, Jul 27, 2017 at 04:43:58PM -0400, Joe Lawrence wrote: > >> On 07/20/2017 12:17 AM, Josh Poimboeuf wrote: > >>> - The post-patch and post-unpatch hooks will need to be run from

Re: [PATCH] livepatch: add (un)patch hooks

On Fri, Jul 28, 2017 at 02:08:33PM -0400, Joe Lawrence wrote: > On 07/27/2017 05:36 PM, Josh Poimboeuf wrote: > > On Thu, Jul 27, 2017 at 04:43:58PM -0400, Joe Lawrence wrote: > >> On 07/20/2017 12:17 AM, Josh Poimboeuf wrote: > >>> - The post-patch and post-unpatch hooks will need to be run from

Re: [RFC PATCH v3] membarrier: expedited private command

On Fri, Jul 28, 2017 at 12:54:29PM -0400, Mathieu Desnoyers wrote: > Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built > from all runqueues for which current thread's mm is the same as the > thread calling sys_membarrier. > > Scheduler-wise, it requires a memory barrier

Re: [RFC PATCH v3] membarrier: expedited private command

On Fri, Jul 28, 2017 at 12:54:29PM -0400, Mathieu Desnoyers wrote: > Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built > from all runqueues for which current thread's mm is the same as the > thread calling sys_membarrier. > > Scheduler-wise, it requires a memory barrier

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: Mikael Pettersson Date: Fri, 28 Jul 2017 10:45:15 +0200 > David Miller writes: > > From: Mikael Pettersson > > Date: Thu, 27 Jul 2017 21:45:25 +0200 > > > > > Attempting to build strace-4.18 as sparcv9 code and run its test suite > > > on

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

From: Mikael Pettersson Date: Fri, 28 Jul 2017 10:45:15 +0200 > David Miller writes: > > From: Mikael Pettersson > > Date: Thu, 27 Jul 2017 21:45:25 +0200 > > > > > Attempting to build strace-4.18 as sparcv9 code and run its test suite > > > on a sparc64 machine (Sun Blade 2500 w/ 2 x

Re: [PATCH 0/3] selftests: sync test conversion to TAP13

Hi Shuah, Thank you for your patches. On Mon, 2017-07-24 at 15:07 -0600, Shuah Khan wrote: > This patch series includes patches to convert sync test to use TAP13 > ksft framework. In addition, fix to sync test to differentiate > between > unsupported feature and access error when a non-root user

Re: [PATCH 0/3] selftests: sync test conversion to TAP13

Hi Shuah, Thank you for your patches. On Mon, 2017-07-24 at 15:07 -0600, Shuah Khan wrote: > This patch series includes patches to convert sync test to use TAP13 > ksft framework. In addition, fix to sync test to differentiate > between > unsupported feature and access error when a non-root user

Re: [PATCH] mm: memcontrol: Use int for event/state parameter in several functions

El Thu, Jul 27, 2017 at 02:10:04PM -0700 Matthias Kaehlcke ha dit: > Several functions use an enum type as parameter for an event/state, > but are called in some locations with an argument of a different enum > type. Adjust the interface of these functions to reality by changing the > parameter

Re: [PATCH] mm: memcontrol: Use int for event/state parameter in several functions

El Thu, Jul 27, 2017 at 02:10:04PM -0700 Matthias Kaehlcke ha dit: > Several functions use an enum type as parameter for an event/state, > but are called in some locations with an argument of a different enum > type. Adjust the interface of these functions to reality by changing the > parameter

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:37:25AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney > wrote: > > IPIin only those CPUs running threads in the same process as the > > thread invoking membarrier() would be very nice! There is some LKML >

Re: Udpated sys_membarrier() speedup patch, FYI

On Fri, Jul 28, 2017 at 10:37:25AM -0700, Andrew Hunter wrote: > On Thu, Jul 27, 2017 at 12:06 PM, Paul E. McKenney > wrote: > > IPIin only those CPUs running threads in the same process as the > > thread invoking membarrier() would be very nice! There is some LKML > > discussion on this topic,

Re: [PATCH V6] sched/fair: Remove group imbalance from calculate_imbalance()

On 7/28/2017 7:34 AM, Dietmar Eggemann wrote: On 28/07/17 13:59, Peter Zijlstra wrote: On Fri, Jul 28, 2017 at 01:16:24PM +0100, Dietmar Eggemann wrote: IIRC the topology you had in mind was MC + DIE level with n (n > 2) DIE level sched groups. [...] If I then start a 3rd loop, I see 100%

Re: [PATCH V6] sched/fair: Remove group imbalance from calculate_imbalance()

On 7/28/2017 7:34 AM, Dietmar Eggemann wrote: On 28/07/17 13:59, Peter Zijlstra wrote: On Fri, Jul 28, 2017 at 01:16:24PM +0100, Dietmar Eggemann wrote: IIRC the topology you had in mind was MC + DIE level with n (n > 2) DIE level sched groups. [...] If I then start a 3rd loop, I see 100%

Re: [PATCH] livepatch: add (un)patch hooks

On 07/27/2017 05:36 PM, Josh Poimboeuf wrote: > On Thu, Jul 27, 2017 at 04:43:58PM -0400, Joe Lawrence wrote: >> On 07/20/2017 12:17 AM, Josh Poimboeuf wrote: >>> - The post-patch and post-unpatch hooks will need to be run from either >>> klp_complete_transition() or klp_module_coming/going(),

[PATCH 1/6] ipc: Make sys_semtimedop() y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interface. This will be part of a separate series. Signed-off-by: Deepa Dinamani ---

Re: [PATCH] livepatch: add (un)patch hooks

On 07/27/2017 05:36 PM, Josh Poimboeuf wrote: > On Thu, Jul 27, 2017 at 04:43:58PM -0400, Joe Lawrence wrote: >> On 07/20/2017 12:17 AM, Josh Poimboeuf wrote: >>> - The post-patch and post-unpatch hooks will need to be run from either >>> klp_complete_transition() or klp_module_coming/going(),

[PATCH 1/6] ipc: Make sys_semtimedop() y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interface. This will be part of a separate series. Signed-off-by: Deepa Dinamani --- ipc/sem.c | 12

[PATCH 3/6] ipc: msg: Make msg_queue timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

[PATCH 3/6] ipc: msg: Make msg_queue timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

[PATCH 4/6] ipc: sem: Make sem_array timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interface themselves

[PATCH 4/6] ipc: sem: Make sem_array timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interface themselves

[PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

struct timespec is not y2038 safe. Replace all uses of timespec by y2038 safe struct timespec64. Even though timespec is used here to represent timeouts, replace these with timespec64 so that it facilitates in verification by creating a y2038 safe kernel image that is free of timespec. The

[PATCH 2/6] ipc: mqueue: Replace timespec with timespec64

struct timespec is not y2038 safe. Replace all uses of timespec by y2038 safe struct timespec64. Even though timespec is used here to represent timeouts, replace these with timespec64 so that it facilitates in verification by creating a y2038 safe kernel image that is free of timespec. The

[PATCH 5/6] ipc: shm: Make shmid_kernel timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

[PATCH 6/6] utimes: Make utimes y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interfaces. This will be part of a separate series. Signed-off-by: Deepa Dinamani ---

[PATCH 5/6] ipc: shm: Make shmid_kernel timestamps y2038 safe

time_t is not y2038 safe. Replace all uses of time_t by y2038 safe time64_t. Similarly, replace the calls to get_seconds() with y2038 safe ktime_get_real_seconds(). Note that this preserves fast access on 64 bit systems, but 32 bit systems need sequence counters. The syscall interfaces

[PATCH 6/6] utimes: Make utimes y2038 safe

struct timespec is not y2038 safe on 32 bit machines. Replace timespec with y2038 safe struct timespec64. Note that the patch only changes the internals without modifying the syscall interfaces. This will be part of a separate series. Signed-off-by: Deepa Dinamani --- fs/utimes.c | 23

[no subject]

Subject: [PATCH 0/6] Make ipc y2038 safe The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with

[no subject]

Subject: [PATCH 0/6] Make ipc y2038 safe The series aims to transition internal workings of ipc subsystem to use y2038-safe types and apis. The series is based on Al Viro's #work.ipc branch. Deepa Dinamani (6): ipc: Make sys_semtimedop() y2038 safe ipc: mqueue: Replace timespec with

Re: [PATCH] net/mlx5: fix spelling mistake: "alloated" -> "allocated"

On Tue, 2017-06-27 at 14:39 +0300, Tariq Toukan wrote: > > On 27/06/2017 10:40 AM, Colin King wrote: > > From: Colin Ian King > > > > Trivial fix to spelling mistake in mlx5_ib_dbg message > > > > Signed-off-by: Colin Ian King > > --- > >

Re: [PATCH] net/mlx5: fix spelling mistake: "alloated" -> "allocated"

On Tue, 2017-06-27 at 14:39 +0300, Tariq Toukan wrote: > > On 27/06/2017 10:40 AM, Colin King wrote: > > From: Colin Ian King > > > > Trivial fix to spelling mistake in mlx5_ib_dbg message > > > > Signed-off-by: Colin Ian King > > --- > > drivers/infiniband/hw/mlx5/main.c | 2 +- > > 1

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