[PATCH v2 10/24] fs: cifs: Replace CURRENT_TIME by current_time()

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. 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 macro

[PATCH v2 01/24] vfs: Add current_time() api

current_fs_time() is used for inode timestamps. Change the signature of the function to take inode pointer instead of superblock as per Linus's suggestion. Also, move the api under vfs as per the discussion on the thread: https://lkml.org/lkml/2016/6/9/36 . As per Arnd's suggestion on the

[PATCH v2 10/24] fs: cifs: Replace CURRENT_TIME by current_time()

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. 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 macro

[PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. Thanks to Arnd Bergmann for all the guidance and

[PATCH v2 09/24] fs: udf: Replace CURRENT_TIME with current_time()

CURRENT_TIME is not y2038 safe. CURRENT_TIME macro is also not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Logical Volume Integrity format is described to have the same timestamp format for "Recording Date and time" as the other

[PATCH v2 06/24] fs: ext4: Use current_time() for inode timestamps

CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe. current_time() will be transitioned to be y2038 safe along with vfs. current_time() returns timestamps according to the granularities set in the super_block. The granularity check in ext4_current_time() to call current_time() or

[PATCH v2 09/24] fs: udf: Replace CURRENT_TIME with current_time()

CURRENT_TIME is not y2038 safe. CURRENT_TIME macro is also not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Logical Volume Integrity format is described to have the same timestamp format for "Recording Date and time" as the other

[PATCH v2 06/24] fs: ext4: Use current_time() for inode timestamps

CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe. current_time() will be transitioned to be y2038 safe along with vfs. current_time() returns timestamps according to the granularities set in the super_block. The granularity check in ext4_current_time() to call current_time() or

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Fri, Jun 17, 2016 at 05:28:47PM -0400, Steven Rostedt wrote: > Ah, due to traveling I never got around to finishing this. What about > this patch? > > From 7bf19b58ba02e66014efce6c051acba2c6cbd861 Mon Sep 17 00:00:00 2001 > From: "Steven Rostedt (Red Hat)" > Date: Mon, 23

Re: [RFC][PATCH] ftracetest: Fix hist unsupported result in hist selftests

On Fri, Jun 17, 2016 at 05:28:47PM -0400, Steven Rostedt wrote: > Ah, due to traveling I never got around to finishing this. What about > this patch? > > From 7bf19b58ba02e66014efce6c051acba2c6cbd861 Mon Sep 17 00:00:00 2001 > From: "Steven Rostedt (Red Hat)" > Date: Mon, 23 May 2016 15:06:30

Re: [PATCH] tracing: Add *iter check for NULL

On Fri, Jun 17, 2016 at 02:24:57PM -0400, Steven Rostedt wrote: > I tried your patch and it works until you remove the module and try > reading the trace again. As I said, you left out later processing. This > should not exit on error. Below is a patch I wrote, and it works well. > > I'll add you

Re: [PATCH] tracing: Add *iter check for NULL

On Fri, Jun 17, 2016 at 02:24:57PM -0400, Steven Rostedt wrote: > I tried your patch and it works until you remove the module and try > reading the trace again. As I said, you left out later processing. This > should not exit on error. Below is a patch I wrote, and it works well. > > I'll add you

Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression

On Fri, Jun 17, 2016 at 12:26:51PM -0700, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Jun 16, 2016 at 03:27:44PM -0700, Huang, Ying wrote: > >> Minchan Kim writes: > >> > >> > On Thu, Jun 16, 2016 at 07:52:26AM +0800, Huang, Ying wrote: > >>

Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression

On Fri, Jun 17, 2016 at 12:26:51PM -0700, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Jun 16, 2016 at 03:27:44PM -0700, Huang, Ying wrote: > >> Minchan Kim writes: > >> > >> > On Thu, Jun 16, 2016 at 07:52:26AM +0800, Huang, Ying wrote: > >> >> "Kirill A. Shutemov" writes: > >> >>

actualizar su cuenta de correo electrónico de inmediato

Hola, por favor verificar su dirección de correo electrónico . Por favor, siga este enlace https://formcrafts.com/a/20226 para completar el proceso de verificación Su correo electrónico no estará en la lista hasta que haya comprobado o significaba estar cerca Saludos, Webmaster Equipo 2016

actualizar su cuenta de correo electrónico de inmediato

Hola, por favor verificar su dirección de correo electrónico . Por favor, siga este enlace https://formcrafts.com/a/20226 para completar el proceso de verificación Su correo electrónico no estará en la lista hasta que haya comprobado o significaba estar cerca Saludos, Webmaster Equipo 2016

Re: [PATCH] MADVISE_FREE, THP: Fix madvise_free_huge_pmd return value after splitting

On Fri, Jun 17, 2016 at 08:59:31AM -0700, Huang, Ying wrote: > Minchan Kim writes: > > > Hi, > > > > On Thu, Jun 16, 2016 at 08:03:54PM -0700, Huang, Ying wrote: > >> From: Huang Ying > >> > >> madvise_free_huge_pmd should return 0 if the fallback PTE

Re: [PATCH] MADVISE_FREE, THP: Fix madvise_free_huge_pmd return value after splitting

On Fri, Jun 17, 2016 at 08:59:31AM -0700, Huang, Ying wrote: > Minchan Kim writes: > > > Hi, > > > > On Thu, Jun 16, 2016 at 08:03:54PM -0700, Huang, Ying wrote: > >> From: Huang Ying > >> > >> madvise_free_huge_pmd should return 0 if the fallback PTE operations are > >> required. In

Re: [PATCH 1/3] toshiba_acpi: Add IIO interface for accelerometer axis data

Hi, Thanks for the feedback, I just did a respin of the series with the changes you mentioned. Cheers Azael 2016-06-19 14:16 GMT-06:00 Jonathan Cameron : > On 11/06/16 19:57, Azael Avalos wrote: >> This patch adds the accelerometer axis data to the IIO subsystem. >> >>

Re: [PATCH 1/3] toshiba_acpi: Add IIO interface for accelerometer axis data

Hi, Thanks for the feedback, I just did a respin of the series with the changes you mentioned. Cheers Azael 2016-06-19 14:16 GMT-06:00 Jonathan Cameron : > On 11/06/16 19:57, Azael Avalos wrote: >> This patch adds the accelerometer axis data to the IIO subsystem. >> >> Currently reporting the

[PATCH v2 1/3] toshiba_acpi: Add IIO interface for accelerometer axis data

This patch adds the accelerometer axis data to the IIO subsystem. Currently reporting the X, Y and Z values, as no other data can be queried given the fact that the accelerometer chip itself is hidden behind the Toshiba proprietary interface. Signed-off-by: Azael Avalos

[PATCH v2 1/3] toshiba_acpi: Add IIO interface for accelerometer axis data

This patch adds the accelerometer axis data to the IIO subsystem. Currently reporting the X, Y and Z values, as no other data can be queried given the fact that the accelerometer chip itself is hidden behind the Toshiba proprietary interface. Signed-off-by: Azael Avalos ---

[PATCH v2 2/3] toshiba_acpi: Remove the position sysfs entry

Now that we have proper support for the acceleromeer under the IIO subsystem, the _position_ sysfs file is now deprecated. This patch removes all code related to the position sysfs entry. Signed-off-by: Azael Avalos --- drivers/platform/x86/toshiba_acpi.c | 25

[PATCH v2 0/3] toshiba_acpi: Accelerometer updates

These series of patches update the accelerometer axis data reporting to use the IIO subsystem, deprecating the custom position sysfs entry, and finally bumping the driver version to 0.24. Changes since v1: - Small format and style changes - Changed the iio code according to feedback from Jonathan

[PATCH v2 3/3] toshiba_acpi: Bump driver version and update copyright year

After several fixes, and added support for more features (WWAN, Cooling Method and IIO accelometer axis data), bump the driver version to 0.24. Also update the copyright year. Signed-off-by: Azael Avalos --- drivers/platform/x86/toshiba_acpi.c | 4 ++-- 1 file changed,

[PATCH v2 2/3] toshiba_acpi: Remove the position sysfs entry

Now that we have proper support for the acceleromeer under the IIO subsystem, the _position_ sysfs file is now deprecated. This patch removes all code related to the position sysfs entry. Signed-off-by: Azael Avalos --- drivers/platform/x86/toshiba_acpi.c | 25 - 1 file

[PATCH v2 0/3] toshiba_acpi: Accelerometer updates

These series of patches update the accelerometer axis data reporting to use the IIO subsystem, deprecating the custom position sysfs entry, and finally bumping the driver version to 0.24. Changes since v1: - Small format and style changes - Changed the iio code according to feedback from Jonathan

[PATCH v2 3/3] toshiba_acpi: Bump driver version and update copyright year

After several fixes, and added support for more features (WWAN, Cooling Method and IIO accelometer axis data), bump the driver version to 0.24. Also update the copyright year. Signed-off-by: Azael Avalos --- drivers/platform/x86/toshiba_acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH 1/2] net: ethernet: bcmsysport: use phydev from struct net_device

From: Philippe Reynes Date: Sun, 19 Jun 2016 20:39:08 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one

Re: [PATCH 2/2] net: ethernet: bcmsysport: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 19 Jun 2016 20:39:09 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 1/2] net: ethernet: bcmsysport: use phydev from struct net_device

From: Philippe Reynes Date: Sun, 19 Jun 2016 20:39:08 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one contained in struct

Re: [PATCH 2/2] net: ethernet: bcmsysport: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 19 Jun 2016 20:39:09 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, Jun 15, 2016 at 10:59:08PM +0800, Herbert Xu wrote: > I think you should be accessing this through the crypto API rather > than going direct. We already have at least one accelerated > implementation of chacha20 and there may well be more of them > in future. Going through the crypto API

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, Jun 15, 2016 at 10:59:08PM +0800, Herbert Xu wrote: > I think you should be accessing this through the crypto API rather > than going direct. We already have at least one accelerated > implementation of chacha20 and there may well be more of them > in future. Going through the crypto API

[PATCH 0/3] nvme: Don't add namespaces for locked drives

Hi all, If an NVMe drive is locked with ATA Security, most commands sent to the drive will fail. This includes commands sent by the kernel upon discovery to probe for partitions. The failing happens in such a way that trying to do anything with the drive (e.g. sending an unlock command;

[PATCH 3/3] nvme: Check if drive is locked using ATA Security

Signed-off-by: Jethro Beekman --- drivers/nvme/host/core.c | 49 +- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index da027ed..0164122 100644 ---

[PATCH 2/3] nvme: Add function for NVMe security receive command

Signed-off-by: Jethro Beekman --- drivers/nvme/host/core.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 3a0d48c..da027ed 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@

[PATCH 1/3] nvme: When scanning namespaces, make sure the drive is not locked

Signed-off-by: Jethro Beekman --- drivers/nvme/host/core.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 643f457..3a0d48c 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@

[PATCH 2/3] nvme: Add function for NVMe security receive command

Signed-off-by: Jethro Beekman --- drivers/nvme/host/core.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 3a0d48c..da027ed 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1377,6 +1377,18 @@

[PATCH 1/3] nvme: When scanning namespaces, make sure the drive is not locked

Signed-off-by: Jethro Beekman --- drivers/nvme/host/core.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 643f457..3a0d48c 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1377,6 +1377,12 @@

[PATCH 0/3] nvme: Don't add namespaces for locked drives

Hi all, If an NVMe drive is locked with ATA Security, most commands sent to the drive will fail. This includes commands sent by the kernel upon discovery to probe for partitions. The failing happens in such a way that trying to do anything with the drive (e.g. sending an unlock command;

[PATCH 3/3] nvme: Check if drive is locked using ATA Security

Signed-off-by: Jethro Beekman --- drivers/nvme/host/core.c | 49 +- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index da027ed..0164122 100644 --- a/drivers/nvme/host/core.c +++

[PATCH 1/2] net: ethernet: bgmac: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH 1/2] net: ethernet: bgmac: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH] rcutorture: Remove outdated config option description

CONFIG_RCU_TORTURE_TEST_RUNNABLE has removed by commit 4e9a073f60367 ("torture: Remove CONFIG_RCU_TORTURE_TEST_RUNNABLE, simplify code") entirely but the document has not updated. This commit updates the document to remove the description for the config option and adding a description for the

[PATCH] rcutorture: Remove outdated config option description

CONFIG_RCU_TORTURE_TEST_RUNNABLE has removed by commit 4e9a073f60367 ("torture: Remove CONFIG_RCU_TORTURE_TEST_RUNNABLE, simplify code") entirely but the document has not updated. This commit updates the document to remove the description for the config option and adding a description for the

Re: [PULL] seccomp update (next)

On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski wrote: > On Jun 18, 2016 12:02 AM, "Kees Cook" wrote: >> >> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski >> wrote: >> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris

Re: [PULL] seccomp update (next)

On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski wrote: > On Jun 18, 2016 12:02 AM, "Kees Cook" wrote: >> >> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski >> wrote: >> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris wrote: >> >> On Tue, 14 Jun 2016, Kees Cook wrote: >> >> >> >>> Hi, >>

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > Let me first thank Pedro who has already replied! > > And I have to admit I will need to re-read his explanations after > sleep to (try to) convince myself I fully understans the problems ;) > Too late for me. > > Right now

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > Let me first thank Pedro who has already replied! > > And I have to admit I will need to re-read his explanations after > sleep to (try to) convince myself I fully understans the problems ;) > Too late for me. > > Right now I have nothing to

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

Let me first thank Pedro who has already replied! And I have to admit I will need to re-read his explanations after sleep to (try to) convince myself I fully understans the problems ;) Too late for me. Right now I have nothing to add, but On 06/18, Andy Lutomirski wrote: > > @@ -922,16 +922,7

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

Let me first thank Pedro who has already replied! And I have to admit I will need to re-read his explanations after sleep to (try to) convince myself I fully understans the problems ;) Too late for me. Right now I have nothing to add, but On 06/18, Andy Lutomirski wrote: > > @@ -922,16 +922,7

Re: [PATCH] staging: dgnc: add __exit macro to dgnc_driver.c

On Saturday, 18 June 2016 19:42:07 UTC Joshua Houghton wrote: > Add the __exit macro to the dgnc_cleanup_module(void) function > in dgnc_driver.c > > Signed-off-by: Joshua Houghton > --- > drivers/staging/dgnc/dgnc_driver.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH] staging: dgnc: add __exit macro to dgnc_driver.c

On Saturday, 18 June 2016 19:42:07 UTC Joshua Houghton wrote: > Add the __exit macro to the dgnc_cleanup_module(void) function > in dgnc_driver.c > > Signed-off-by: Joshua Houghton > --- > drivers/staging/dgnc/dgnc_driver.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > > On Fri, 17 Jun 2016, Daniel Vetter wrote: > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > > On Thu, 2016-06-16 at 14:29 -0700, James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > > On Fri, 17 Jun 2016, Daniel Vetter wrote: > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski wrote: > On Jun 18, 2016 6:56 AM, "Pedro Alves" wrote: >> >> On 06/18/2016 11:21 AM, Andy Lutomirski wrote: >> > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. >> > >> > - If the tracee

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski wrote: > On Jun 18, 2016 6:56 AM, "Pedro Alves" wrote: >> >> On 06/18/2016 11:21 AM, Andy Lutomirski wrote: >> > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. >> > >> > - If the tracee is stopped in a 32-bit syscall, this

Re: [PATCH v2 0/6] x86: Rewrite switch_to()

On Sat, Jun 18, 2016 at 4:56 PM, Brian Gerst wrote: > This patch set simplifies the switch_to() code, by moving the stack switch > code out of line into an asm stub before calling __switch_to(). This ends > up being more readable, and using the C calling convention instead of

Re: [PATCH v2 0/6] x86: Rewrite switch_to()

On Sat, Jun 18, 2016 at 4:56 PM, Brian Gerst wrote: > This patch set simplifies the switch_to() code, by moving the stack switch > code out of line into an asm stub before calling __switch_to(). This ends > up being more readable, and using the C calling convention instead of > clobbering all

Re: [PATCH v2 5/6] x86: Pass kernel thread parameters in fork_frame

On Sun, Jun 19, 2016 at 5:28 PM, Andy Lutomirski wrote: > On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: >> Instead of setting up a fake pt_regs context, put the kernel thread >> function pointer and arg into the unused callee-restored registers >> of

Re: [PATCH v2 5/6] x86: Pass kernel thread parameters in fork_frame

On Sun, Jun 19, 2016 at 5:28 PM, Andy Lutomirski wrote: > On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: >> Instead of setting up a fake pt_regs context, put the kernel thread >> function pointer and arg into the unused callee-restored registers >> of struct fork_frame. > > This seems

Re: [RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost

On Sun 19-06-16 23:35:43, Michal Hocko wrote: > On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote: > > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote: [...] > > > /* > > > + * A safe variant of __get_user for for use_mm() users to have a > > > + * gurantee that the address space

Re: [RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost

On Sun 19-06-16 23:35:43, Michal Hocko wrote: > On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote: > > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote: [...] > > > /* > > > + * A safe variant of __get_user for for use_mm() users to have a > > > + * gurantee that the address space

Re: [RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost

On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote: > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote: [...] > > It seems that vhost usage would suffer from this problem because > > it reads from the userspace to get (status) flags and makes some > > decisions based on the read value.

Re: [RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost

On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote: > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote: [...] > > It seems that vhost usage would suffer from this problem because > > it reads from the userspace to get (status) flags and makes some > > decisions based on the read value.

Re: [PATCH v2 5/6] x86: Pass kernel thread parameters in fork_frame

On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: > Instead of setting up a fake pt_regs context, put the kernel thread > function pointer and arg into the unused callee-restored registers > of struct fork_frame. This seems generally okay. > > Signed-off-by: Brian Gerst

Re: [PATCH v2 5/6] x86: Pass kernel thread parameters in fork_frame

On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: > Instead of setting up a fake pt_regs context, put the kernel thread > function pointer and arg into the unused callee-restored registers > of struct fork_frame. This seems generally okay. > > Signed-off-by: Brian Gerst > @@ -146,19 +147,12

Re: [PATCH v2 4/6] x86: Rewrite switch_to() code

On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: > Move the low-level context switch code to an out-of-line asm stub instead of > using complex inline asm. This allows constructing a new stack frame for the > child process to make it seamlessly flow to ret_from_fork without

Re: [PATCH v2 4/6] x86: Rewrite switch_to() code

On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: > Move the low-level context switch code to an out-of-line asm stub instead of > using complex inline asm. This allows constructing a new stack frame for the > child process to make it seamlessly flow to ret_from_fork without an extra > test

Re: [PATCH v2 3/6] x86: Add struct inactive_task_frame

On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: > Add struct inactive_task_frame, which defines the layout of the stack for > a sleeping process. For now, the only defined field is the BP register > (frame pointer). I like this version. Reviewed-by: Andy Lutomirski

Re: [PATCH v2 3/6] x86: Add struct inactive_task_frame

On Sat, Jun 18, 2016 at 1:56 PM, Brian Gerst wrote: > Add struct inactive_task_frame, which defines the layout of the stack for > a sleeping process. For now, the only defined field is the BP register > (frame pointer). I like this version. Reviewed-by: Andy Lutomirski

Re: Let me know about regressions in 4.7 (was: Re: Linux 4.7-rc1)

Hi! > On 29.05.2016 19:00, Linus Torvalds wrote: > > [???] Anyway, enough blathering. Go out and test. [???] > > And if you find any regressions in 4.7 pre-releases let me know via > regressi...@leemhuis.info I'll try to compile them into a list and post > it on LKML once a week similar to how

Re: Let me know about regressions in 4.7 (was: Re: Linux 4.7-rc1)

Hi! > On 29.05.2016 19:00, Linus Torvalds wrote: > > [???] Anyway, enough blathering. Go out and test. [???] > > And if you find any regressions in 4.7 pre-releases let me know via > regressi...@leemhuis.info I'll try to compile them into a list and post > it on LKML once a week similar to how

Re: [PATCH 2/2] net: ethernet: bcmsysport: use phy_ethtool_{get|set}_link_ksettings

Le 19/06/2016 11:39, Philippe Reynes a écrit : > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Reviewed-by: Florian Fainelli

Re: [PATCH 2/2] net: ethernet: bcmsysport: use phy_ethtool_{get|set}_link_ksettings

Le 19/06/2016 11:39, Philippe Reynes a écrit : > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Reviewed-by: Florian Fainelli -- Florian

Re: [PATCH 1/2] net: ethernet: bcmsysport: use phydev from struct net_device

Le 19/06/2016 11:39, Philippe Reynes a écrit : > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one contained in struct net_device. >

Re: [PATCH 1/2] net: ethernet: bcmsysport: use phydev from struct net_device

Le 19/06/2016 11:39, Philippe Reynes a écrit : > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one contained in struct net_device. >

[PATCH 2/2] net: ethernet: bgmac: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/broadcom/bgmac.c | 20 ++-- 1 files changed, 2 insertions(+),

[PATCH 2/2] net: ethernet: bgmac: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/broadcom/bgmac.c | 20 ++-- 1 files changed, 2 insertions(+), 18 deletions(-)

Re: [PATCH v5 0/7] /dev/random - a new approach

On Sun, Jun 19, 2016 at 3:36 PM, Pavel Machek wrote: >> The following patch set provides a different approach to /dev/random ... > > Dunno. It is very similar to existing rng, AFAICT. I do not think so. A lot of the basic principles are the same of course, but Stephan is

Re: [PATCH v5 0/7] /dev/random - a new approach

On Sun, Jun 19, 2016 at 3:36 PM, Pavel Machek wrote: >> The following patch set provides a different approach to /dev/random ... > > Dunno. It is very similar to existing rng, AFAICT. I do not think so. A lot of the basic principles are the same of course, but Stephan is suggesting some real

[PATCH] checkpatch: remove obsolete CONFIG_EXPERIMENTAL checks

Config EXPERIMENTAL has been removed from kernel in 2013 (see 3d374d0: "final removal of CONFIG_EXPERIMENTAL"), there is no any reason to do these checks now. Signed-off-by: Ruslan Bilovol --- scripts/checkpatch.pl | 13 - 1 file changed, 13 deletions(-)

[PATCH] checkpatch: remove obsolete CONFIG_EXPERIMENTAL checks

Config EXPERIMENTAL has been removed from kernel in 2013 (see 3d374d0: "final removal of CONFIG_EXPERIMENTAL"), there is no any reason to do these checks now. Signed-off-by: Ruslan Bilovol --- scripts/checkpatch.pl | 13 - 1 file changed, 13 deletions(-) diff --git

Re: [PATCH 1/3] toshiba_acpi: Add IIO interface for accelerometer axis data

On 11/06/16 19:57, Azael Avalos wrote: > This patch adds the accelerometer axis data to the IIO subsystem. > > Currently reporting the X, Y and Z values, as no other data can be > queried given the fact that the accelerometer chip itself is hidden > behind the Toshiba proprietary interface. > >

Re: linux-next: manual merge of the staging tree with the staging.current tree

On 14/06/16 06:04, Stephen Rothwell wrote: > Hi Greg, > > Today's linux-next merge of the staging tree got a conflict in: > > drivers/iio/industrialio-trigger.c > > between commit: > > 995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func") > > from the staging.current

Re: [PATCH 1/3] toshiba_acpi: Add IIO interface for accelerometer axis data

On 11/06/16 19:57, Azael Avalos wrote: > This patch adds the accelerometer axis data to the IIO subsystem. > > Currently reporting the X, Y and Z values, as no other data can be > queried given the fact that the accelerometer chip itself is hidden > behind the Toshiba proprietary interface. > >

Re: linux-next: manual merge of the staging tree with the staging.current tree

On 14/06/16 06:04, Stephen Rothwell wrote: > Hi Greg, > > Today's linux-next merge of the staging tree got a conflict in: > > drivers/iio/industrialio-trigger.c > > between commit: > > 995438233579 ("iio: Fix error handling in iio_trigger_attach_poll_func") > > from the staging.current

Re: [PATCH 0/4] ASoC: tpa6130a2: Add support for multiple instances

Hi, On Sat, Jun 18, 2016 at 12:26:27AM -0300, Helen Koike wrote: > The current tpa6130a2 driver supports only a single instance. > This patch series add support for multiple instances by removing the global > variable that holds the instance. > This is performed by using the component API,

Re: [PATCH 0/4] ASoC: tpa6130a2: Add support for multiple instances

Hi, On Sat, Jun 18, 2016 at 12:26:27AM -0300, Helen Koike wrote: > The current tpa6130a2 driver supports only a single instance. > This patch series add support for multiple instances by removing the global > variable that holds the instance. > This is performed by using the component API,

Re: [PATCH 4/4] ASoC: tpa6130a2: Add DAPM support

Hi, On Sun, Jun 19, 2016 at 11:39:15AM +0200, Lars-Peter Clausen wrote: > On 06/19/2016 01:21 AM, Sebastian Reichel wrote: > > On Sat, Jun 18, 2016 at 12:26:31AM -0300, Helen Koike wrote: > >> Add DAPM support and updated rx51 accordingly. > >> As a consequence: > >> - the exported function

Re: [PATCH 4/4] ASoC: tpa6130a2: Add DAPM support

Hi, On Sun, Jun 19, 2016 at 11:39:15AM +0200, Lars-Peter Clausen wrote: > On 06/19/2016 01:21 AM, Sebastian Reichel wrote: > > On Sat, Jun 18, 2016 at 12:26:31AM -0300, Helen Koike wrote: > >> Add DAPM support and updated rx51 accordingly. > >> As a consequence: > >> - the exported function

Re: [RFC] capabilities: add capability cgroup controller

apologies for top posting, this phone doesn't support inline) Where are you preventing less privileged tasks from limiting the caps of a more privileged task? It looks like you are relying on the cgroupfs for that? Overall I'm not a fan of this for several reasons. Can you tell us precisely

Re: [RFC] capabilities: add capability cgroup controller

apologies for top posting, this phone doesn't support inline) Where are you preventing less privileged tasks from limiting the caps of a more privileged task? It looks like you are relying on the cgroupfs for that? Overall I'm not a fan of this for several reasons. Can you tell us precisely

Re: [PATCH 2/3] staging: luster: Checkpatch Cleanup

I did build the kernel 1 for each change, then a final with all changes applied. Apologies if I missed something, Craig On Sat, Jun 18, 2016 at 07:02:35PM -0700, Greg Kroah-Hartman wrote: > On Sat, Jun 18, 2016 at 10:25:55PM +0100, Craig Inches wrote: > > Macros with complex values should be

Re: [PATCH 2/3] staging: luster: Checkpatch Cleanup

I did build the kernel 1 for each change, then a final with all changes applied. Apologies if I missed something, Craig On Sat, Jun 18, 2016 at 07:02:35PM -0700, Greg Kroah-Hartman wrote: > On Sat, Jun 18, 2016 at 10:25:55PM +0100, Craig Inches wrote: > > Macros with complex values should be

Re: [PATCH 1/1] iio: fix config watermark initial value

On 16/06/16 17:19, Lars-Peter Clausen wrote: > On 06/16/2016 06:16 PM, Jonathan Cameron wrote: >> >> >> On 16 June 2016 12:56:11 BST, Daniel Baluta wrote: >>> On Mon, Mar 28, 2016 at 1:02 PM, Jonathan Cameron >>> wrote: On 24/03/16 09:23,

Re: [PATCH 1/1] iio: fix config watermark initial value

On 16/06/16 17:19, Lars-Peter Clausen wrote: > On 06/16/2016 06:16 PM, Jonathan Cameron wrote: >> >> >> On 16 June 2016 12:56:11 BST, Daniel Baluta wrote: >>> On Mon, Mar 28, 2016 at 1:02 PM, Jonathan Cameron >>> wrote: On 24/03/16 09:23, Lars-Peter Clausen wrote: > On 03/24/2016 10:09

Re: [RFC] regmap: Add regmap_pipe_read API

On 17/06/16 09:05, Lars-Peter Clausen wrote: > On 06/17/2016 09:04 AM, Crestez Dan Leonard wrote: >> On 06/16/2016 06:43 PM, Geert Uytterhoeven wrote: >>> Hi Leonard, >>> >>> On Thu, Jun 16, 2016 at 5:24 PM, Crestez Dan Leonard >>> wrote: The regmap API usually

Re: [RFC] regmap: Add regmap_pipe_read API

On 17/06/16 09:05, Lars-Peter Clausen wrote: > On 06/17/2016 09:04 AM, Crestez Dan Leonard wrote: >> On 06/16/2016 06:43 PM, Geert Uytterhoeven wrote: >>> Hi Leonard, >>> >>> On Thu, Jun 16, 2016 at 5:24 PM, Crestez Dan Leonard >>> wrote: The regmap API usually assumes that bulk read

<    1   2   3   4   5   6   >