Re: linux-next: build warning after merge of the akpm-current tree

Hi Josh, On Fri, 29 Apr 2016 09:03:42 -0500 Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote: > > > Hi Andrew, > > > > > > After merging the akpm-current tree,

Re: linux-next: build warning after merge of the akpm-current tree

Hi Josh, On Fri, 29 Apr 2016 09:03:42 -0500 Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote: > > > Hi Andrew, > > > > > > After merging the akpm-current tree, today's linux-next

Re: [PATCH v2 5/7] perf: Introduce address range filtering

Mathieu Poirier writes: > I see two things in this work: [trimmed 700+ lines of context that had no purpose] > 1) A framework to deal with filters described in user space. > 2) An implementation for address filtering that will work for both > Intel and ARM. > > This

Re: [PATCH v2 5/7] perf: Introduce address range filtering

Mathieu Poirier writes: > I see two things in this work: [trimmed 700+ lines of context that had no purpose] > 1) A framework to deal with filters described in user space. > 2) An implementation for address filtering that will work for both > Intel and ARM. > > This will work well for address

Re: [PATCH] Use existing helper to convert "on/off" to boolean

On 04/29/16 at 02:21P, Andrew Morton wrote: > On Fri, 29 Apr 2016 13:47:04 +0800 Minfei Huang wrote: > > > It's more convenient to use existing function helper to convert string > > "on/off" to boolean. > > > > ... > > > > --- a/lib/kstrtox.c > > +++ b/lib/kstrtox.c > > @@

Re: [PATCH] Use existing helper to convert "on/off" to boolean

On 04/29/16 at 02:21P, Andrew Morton wrote: > On Fri, 29 Apr 2016 13:47:04 +0800 Minfei Huang wrote: > > > It's more convenient to use existing function helper to convert string > > "on/off" to boolean. > > > > ... > > > > --- a/lib/kstrtox.c > > +++ b/lib/kstrtox.c > > @@ -326,7 +326,7 @@

[PATCH] Tolerate signal > 32 in sig_fatal (apparent bug detected by UBSAN)

I apologize if there is some more specialized mailing list to which I should have first directed this unreviewed patch. Please feel free to redirect me. The undefined behavior sanitizer ("UBSAN") on 32-bit i386 detected a case in linux-4.6-rc5/kernel/signal/signal.c where complete_signal called

[PATCH] Tolerate signal > 32 in sig_fatal (apparent bug detected by UBSAN)

I apologize if there is some more specialized mailing list to which I should have first directed this unreviewed patch. Please feel free to redirect me. The undefined behavior sanitizer ("UBSAN") on 32-bit i386 detected a case in linux-4.6-rc5/kernel/signal/signal.c where complete_signal called

Re: [PATCH v5 09/21] IB/hns: Add hca support

On Wed, Apr 27, 2016 at 6:34 AM, oulijun wrote: > On 2016/4/26 22:25, Jiri Pirko wrote: >> Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote: I appreciate your keen eye. this code is meant for ARM64bit therefore should run corretly for 64-bit AARCH64.

Re: [PATCH v5 09/21] IB/hns: Add hca support

On Wed, Apr 27, 2016 at 6:34 AM, oulijun wrote: > On 2016/4/26 22:25, Jiri Pirko wrote: >> Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote: I appreciate your keen eye. this code is meant for ARM64bit therefore should run corretly for 64-bit AARCH64. >> The driver

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

> Not doing it for 64-bit constants makes no sense if it just uses the > trivial Booth's algorithm version. AFAICT, gcc 5 *does* optimize 64-bit multiplies by constants. Does the belief that it doesn't date back to some really old version? There's still a threshold where it just punts to the

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

> Not doing it for 64-bit constants makes no sense if it just uses the > trivial Booth's algorithm version. AFAICT, gcc 5 *does* optimize 64-bit multiplies by constants. Does the belief that it doesn't date back to some really old version? There's still a threshold where it just punts to the

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Hi, On Fri, Apr 29, 2016 at 5:31 PM, Peter Hurley wrote: > On 04/29/2016 05:03 PM, Doug Anderson wrote: >> Hi, >> >> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley >> wrote: >> >> On 04/29/2016 04:01 PM, Doug Anderson wrote: >> > *

Re: [PATCH v2] pstore: add lzo/lz4 compression support

On Thu, Feb 18, 2016 at 09:37:26AM -0800, Kees Cook wrote: > On Thu, Feb 18, 2016 at 6:04 AM, Geliang Tang wrote: > > Like zlib compression in pstore, this patch added lzo and lz4 > > compression support so that users can have more options and better > > compression ratio. >

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Hi, On Fri, Apr 29, 2016 at 5:31 PM, Peter Hurley wrote: > On 04/29/2016 05:03 PM, Doug Anderson wrote: >> Hi, >> >> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley >> wrote: >> >> On 04/29/2016 04:01 PM, Doug Anderson wrote: >> > * serial allows numbering devices by alias. >> >>

Re: [PATCH v2] pstore: add lzo/lz4 compression support

On Thu, Feb 18, 2016 at 09:37:26AM -0800, Kees Cook wrote: > On Thu, Feb 18, 2016 at 6:04 AM, Geliang Tang wrote: > > Like zlib compression in pstore, this patch added lzo and lz4 > > compression support so that users can have more options and better > > compression ratio. > > > > The original

[PATCH v2 1/3] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS receives flow control" This only happened after first having enabled

[PATCH v2 1/3] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS transmits active signal" and CRTSCTS=1 => "RTS receives flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS receives flow control" This only happened after first having enabled

[PATCH v2 3/3] USB: serial: cp210x: Cleaned up CRTSCTS flag code.

The CRTSCTS flag code cleared (and inconsistently) bits unrelated to CRTSCTS functionality. It was also harder than necessary to read. Signed-off-by: Konstantin Shkolnyy --- Changes in v2: Improved CRTSCTS fix based on feedback. Dropped get_termios error handling.

[PATCH v2 2/3] USB: serial: cp210x: Added comments to CRTSCTS flag code.

Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy --- Changes in v2: Improved CRTSCTS fix based on feedback. Dropped get_termios error handling. drivers/usb/serial/cp210x.c |

[PATCH v2 3/3] USB: serial: cp210x: Cleaned up CRTSCTS flag code.

The CRTSCTS flag code cleared (and inconsistently) bits unrelated to CRTSCTS functionality. It was also harder than necessary to read. Signed-off-by: Konstantin Shkolnyy --- Changes in v2: Improved CRTSCTS fix based on feedback. Dropped get_termios error handling. drivers/usb/serial/cp210x.c |

[PATCH v2 2/3] USB: serial: cp210x: Added comments to CRTSCTS flag code.

Replaced magic numbers used in the CRTSCTS flag code with symbolic names from the chip specification. Signed-off-by: Konstantin Shkolnyy --- Changes in v2: Improved CRTSCTS fix based on feedback. Dropped get_termios error handling. drivers/usb/serial/cp210x.c | 93

[PATCH 2/6] HSI: omap_ssi: fix module unloading

Removal of ssi controller debugfs directory must happen after the clients have been removed from it. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 2/6] HSI: omap_ssi: fix module unloading

Removal of ssi controller debugfs directory must happen after the clients have been removed from it. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hsi/controllers/omap_ssi.c

[PATCH 5/6] HSI: omap_ssi: built omap_ssi and omap_ssi_port into one module

Merge omap_ssi and omap_ssi_port into one module. This fixes problems with module cycle dependencies introduced by future patches. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/Kconfig | 5 - drivers/hsi/controllers/Makefile

[PATCH 6/6] HSI: omap-ssi: add clk change support

This adds support for frequency changes of the SSI functional clock, which may occur due to DVFS. Signed-off-By: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.h | 6 drivers/hsi/controllers/omap_ssi_core.c | 63 +

[PATCH 5/6] HSI: omap_ssi: built omap_ssi and omap_ssi_port into one module

Merge omap_ssi and omap_ssi_port into one module. This fixes problems with module cycle dependencies introduced by future patches. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/Kconfig | 5 - drivers/hsi/controllers/Makefile|

[PATCH 6/6] HSI: omap-ssi: add clk change support

This adds support for frequency changes of the SSI functional clock, which may occur due to DVFS. Signed-off-By: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.h | 6 drivers/hsi/controllers/omap_ssi_core.c | 63 +

[PATCH 4/6] HSI: omap_ssi: fix removal of port platform device

This avoids removal of the HSI port device when only the platform port device should be removed and clears the POPULATED bit in the DT node, so that a new platform device is created when the driver is probed again. Signed-off-by: Sebastian Reichel ---

[PATCH 4/6] HSI: omap_ssi: fix removal of port platform device

This avoids removal of the HSI port device when only the platform port device should be removed and clears the POPULATED bit in the DT node, so that a new platform device is created when the driver is probed again. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.c | 4

[PATCH 1/6] HSI: omap_ssi_port: switch to gpiod API

Simplify driver by switching to new gpio descriptor based API. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.c | 1 - drivers/hsi/controllers/omap_ssi.h | 4 ++-- drivers/hsi/controllers/omap_ssi_port.c | 31 ++- 3

[PATCH 3/6] HSI: omap_ssi: make sure probe stays available

device can be unbind/rebind, so probe should stay available. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.c | 17 + drivers/hsi/controllers/omap_ssi_port.c | 19 ++- 2 files changed, 19 insertions(+), 17 deletions(-)

[PATCH 1/6] HSI: omap_ssi_port: switch to gpiod API

Simplify driver by switching to new gpio descriptor based API. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.c | 1 - drivers/hsi/controllers/omap_ssi.h | 4 ++-- drivers/hsi/controllers/omap_ssi_port.c | 31 ++- 3 files changed,

[PATCH 3/6] HSI: omap_ssi: make sure probe stays available

device can be unbind/rebind, so probe should stay available. Signed-off-by: Sebastian Reichel --- drivers/hsi/controllers/omap_ssi.c | 17 + drivers/hsi/controllers/omap_ssi_port.c | 19 ++- 2 files changed, 19 insertions(+), 17 deletions(-) diff --git

[PATCH 0/6] omap-ssi cleanups + dvfs support

Hi, The following patches add a few cleanups to the omap-ssi driver, fix module unloading (and reloading) and merge omap-ssi and omap-ssi-port into the same module to avoid a circular dependency introduced by the last patch. P.S.: The last patch has already been sent in this patchset

[PATCH 0/6] omap-ssi cleanups + dvfs support

Hi, The following patches add a few cleanups to the omap-ssi driver, fix module unloading (and reloading) and merge omap-ssi and omap-ssi-port into the same module to avoid a circular dependency introduced by the last patch. P.S.: The last patch has already been sent in this patchset

Re: [RFC PATCH 1/1] clk: imx7d: move clk setting out of imx7d_clocks_init

On 2016-04-29 02:45, Dong Aisheng wrote: > During kernel early booting(e.g. in time_init()), there's only one > init idle task running, and the idle sched class indicates that it's > not valid to schedule for idle task. If it happens the kernel > will complain with a error message as follows: > [

Re: [RFC PATCH 1/1] clk: imx7d: move clk setting out of imx7d_clocks_init

On 2016-04-29 02:45, Dong Aisheng wrote: > During kernel early booting(e.g. in time_init()), there's only one > init idle task running, and the idle sched class indicates that it's > not valid to schedule for idle task. If it happens the kernel > will complain with a error message as follows: > [

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, 2016-04-29 at 16:51 -0700, Linus Torvalds wrote: > There's presumably a few optimal values from a "spread bits out > evenly" standpoint, and they won't have anything to do with random > irrational constants, and will have everything to do with having nice > bitpatterns. > > I'm adding

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, 2016-04-29 at 16:51 -0700, Linus Torvalds wrote: > There's presumably a few optimal values from a "spread bits out > evenly" standpoint, and they won't have anything to do with random > irrational constants, and will have everything to do with having nice > bitpatterns. > > I'm adding

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 5:32 PM, George Spelvin wrote: > > Odd is important. If the multiplier is even, the msbit of the input > doesn't affect the hash result at all. Fair enough. My test-set was incomplete. >> Yeah. gcc will actually do the clever stuff for the 32-bit

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 5:32 PM, George Spelvin wrote: > > Odd is important. If the multiplier is even, the msbit of the input > doesn't affect the hash result at all. Fair enough. My test-set was incomplete. >> Yeah. gcc will actually do the clever stuff for the 32-bit case, afaik. > > It's

Re:Good Day

I am Mr. Hirano Nobuyuki , from Japan, I will like to seek your partnership and mutual understanding regarding a beneficial transaction. Reply Immediately to my email below for Details . ( hiranonobuyuki...@lycos.com ) Regards For Hirano Sincerely, Mr.Nobuyuki Hirano Bank Of Tokyo-Mitsubishi

Re:Good Day

I am Mr. Hirano Nobuyuki , from Japan, I will like to seek your partnership and mutual understanding regarding a beneficial transaction. Reply Immediately to my email below for Details . ( hiranonobuyuki...@lycos.com ) Regards For Hirano Sincerely, Mr.Nobuyuki Hirano Bank Of Tokyo-Mitsubishi

Re: [PATCH 00/14] staging: fsl-mc: misc updates

On Mon, Apr 11, 2016 at 11:48:25AM -0500, Stuart Yoder wrote: > From: Stuart Yoder > > This patch series makes further progress towards completing the fsl-mc > TODO list. I don't seem to have gotten patch 14/14, can you resend just that one? thanks, greg k-h

Re: [PATCH 00/14] staging: fsl-mc: misc updates

On Mon, Apr 11, 2016 at 11:48:25AM -0500, Stuart Yoder wrote: > From: Stuart Yoder > > This patch series makes further progress towards completing the fsl-mc > TODO list. I don't seem to have gotten patch 14/14, can you resend just that one? thanks, greg k-h

[PATCH] x86, perf: Add model numbers for Kabylake CPUs

From: Andi Kleen Everything the same as Skylake, just new model numbers. Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c

[PATCH] x86, perf: Add model numbers for Kabylake CPUs

From: Andi Kleen Everything the same as Skylake, just new model numbers. Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 79b59437f5ee..90ba3ae3074e 100644 ---

Re: [PATCH v2 1/4] drivers: staging: fix parameter alignment

On Mon, Apr 18, 2016 at 10:35:28AM +1000, Tobin C Harding wrote: > drivers/staging/android/ion/ion.c checkpatch produces alignment checks. > > This patch is whitespace only and fixes these checks. > > Signed-off-by: Tobin C Harding > --- > drivers/staging/android/ion/ion.c | 64

Re: [PATCH v2 1/4] drivers: staging: fix parameter alignment

On Mon, Apr 18, 2016 at 10:35:28AM +1000, Tobin C Harding wrote: > drivers/staging/android/ion/ion.c checkpatch produces alignment checks. > > This patch is whitespace only and fixes these checks. > > Signed-off-by: Tobin C Harding > --- > drivers/staging/android/ion/ion.c | 64 >

Re: [PATCH] staging: rts5208: Unnecessary parantheses around chip->sd_card

On Fri, Apr 29, 2016 at 11:15:27AM +0530, Manav Batra wrote: > Removes unnecessary parantheses around chip->sd_card > Signed-off-by: Manav Batra > --- >  drivers/staging/rts5208/sd.c | 6 +++--- >  1 file changed, 3 insertions(+), 3 deletions(-) HTML patches do not work,

Re: [PATCH] staging: rts5208: Unnecessary parantheses around chip->sd_card

On Fri, Apr 29, 2016 at 11:15:27AM +0530, Manav Batra wrote: > Removes unnecessary parantheses around chip->sd_card > Signed-off-by: Manav Batra > --- >  drivers/staging/rts5208/sd.c | 6 +++--- >  1 file changed, 3 insertions(+), 3 deletions(-) HTML patches do not work, sorry :( Also, put a

Re: [PATCH] staging: rts5208: Avoid multiple assignment in one line

On Thu, Apr 28, 2016 at 10:42:07PM -0700, Manav Batra wrote: > Signed-off-by: Manav Batra > > Separates out assignment in one line to two lines. signed-off-by goes at the end of the text, not at the top. Please fix all of these and resend. thanks, greg k-h

Re: [PATCH] staging: rts5208: Avoid multiple assignment in one line

On Thu, Apr 28, 2016 at 10:42:07PM -0700, Manav Batra wrote: > Signed-off-by: Manav Batra > > Separates out assignment in one line to two lines. signed-off-by goes at the end of the text, not at the top. Please fix all of these and resend. thanks, greg k-h

Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES

On 04/29/2016 04:12 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:32:15PM -0700, Dave Hansen wrote: >> The reason I haven't acked this patch is that I want to be _sure_ that >> we've audited all of the call paths that access the XSAVE buffer to >> ensure that they can all either handle the

Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES

On 04/29/2016 04:12 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:32:15PM -0700, Dave Hansen wrote: >> The reason I haven't acked this patch is that I want to be _sure_ that >> we've audited all of the call paths that access the XSAVE buffer to >> ensure that they can all either handle the

Re: [PATCH v2 00/13] De-stage Sync File Framework

On Thu, Apr 28, 2016 at 10:46:47AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > This patchset sits on top of Sync ABI Rework v13: > > https://www.spinics.net/lists/dri-devel/msg105667.html > > The first eight clean up and prepare sync_file

Re: [PATCH v2 00/13] De-stage Sync File Framework

On Thu, Apr 28, 2016 at 10:46:47AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > This patchset sits on top of Sync ABI Rework v13: > > https://www.spinics.net/lists/dri-devel/msg105667.html > > The first eight clean up and prepare sync_file for de-staging. The last four >

Re: [PATCH v4 04/10] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

On 04/29/2016 03:43 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:09:07PM -0700, Dave Hansen wrote: >> On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: >>> +static int may_copy_fpregs_to_sigframe(void) >>> +{ >>> + /* >>> +* In signal handling path, the kernel already checks if >>> +*

Re: [PATCH v4 04/10] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly

On 04/29/2016 03:43 PM, Yu-cheng Yu wrote: > On Fri, Apr 29, 2016 at 01:09:07PM -0700, Dave Hansen wrote: >> On 03/04/2016 10:12 AM, Yu-cheng Yu wrote: >>> +static int may_copy_fpregs_to_sigframe(void) >>> +{ >>> + /* >>> +* In signal handling path, the kernel already checks if >>> +*

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

> At least for my tests, even that seems to actually be a total > non-issue. Yes, odd values *might* be better, but as mentioned in my > crossing email, it doesn't actually seem to matter for any case the > kernel cares about, since we tend to want to hash down to 10-20 bits > of data, so the

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On 04/29/2016 05:03 PM, Doug Anderson wrote: > Hi, > > On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley > wrote: > > On 04/29/2016 04:01 PM, Doug Anderson wrote: > > * serial allows numbering devices by alias. > > Which is in fact a total nightmare. > >

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

> At least for my tests, even that seems to actually be a total > non-issue. Yes, odd values *might* be better, but as mentioned in my > crossing email, it doesn't actually seem to matter for any case the > kernel cares about, since we tend to want to hash down to 10-20 bits > of data, so the

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On 04/29/2016 05:03 PM, Doug Anderson wrote: > Hi, > > On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley > wrote: > > On 04/29/2016 04:01 PM, Doug Anderson wrote: > > * serial allows numbering devices by alias. > > Which is in fact a total nightmare. > > While stable device order

Re: [PATCH 0/2] scop GFP_NOFS api

On Fri, Apr 29, 2016 at 02:04:18PM +0200, Michal Hocko wrote: > I would also like to revisit generic inode/dentry shrinker and see > whether it could be more __GFP_FS friendly. As you say many FS might > even not depend on some FS internal locks so pushing GFP_FS check down > the layers might make

Re: [PATCH 0/2] scop GFP_NOFS api

On Fri, Apr 29, 2016 at 02:04:18PM +0200, Michal Hocko wrote: > I would also like to revisit generic inode/dentry shrinker and see > whether it could be more __GFP_FS friendly. As you say many FS might > even not depend on some FS internal locks so pushing GFP_FS check down > the layers might make

Re: [PATCH v2] ecryptfs: open lower files using kernel creds

On 2016-04-12 03:15:44, Ricky Zhou wrote: > In LSMs such as SELinux, files can be associated with state from the > credentials of the task that opens it. Since ecryptfs shares a single > handle to lower files across tasks that access it, others tasks can > later be denied access to the lower file

Re: [PATCH v2] ecryptfs: open lower files using kernel creds

On 2016-04-12 03:15:44, Ricky Zhou wrote: > In LSMs such as SELinux, files can be associated with state from the > credentials of the task that opens it. Since ecryptfs shares a single > handle to lower files across tasks that access it, others tasks can > later be denied access to the lower file

Re: [RFC][PATCH 14/31] locking,metag: Implement atomic_fetch_{add,sub,and,or,xor}()

Hi Peter, On Fri, Apr 22, 2016 at 11:04:27AM +0200, Peter Zijlstra wrote: > Implement FETCH-OP atomic primitives, these are very similar to the > existing OP-RETURN primitives we already have, except they return the > value of the atomic variable _before_ modification. > > This is especially

Re: [RFC][PATCH 14/31] locking,metag: Implement atomic_fetch_{add,sub,and,or,xor}()

Hi Peter, On Fri, Apr 22, 2016 at 11:04:27AM +0200, Peter Zijlstra wrote: > Implement FETCH-OP atomic primitives, these are very similar to the > existing OP-RETURN primitives we already have, except they return the > value of the atomic variable _before_ modification. > > This is especially

Re: [PATCH 0/2] scop GFP_NOFS api

On Fri, Apr 29, 2016 at 03:35:42PM +1000, NeilBrown wrote: > On Tue, Apr 26 2016, Michal Hocko wrote: > > > Hi, > > we have discussed this topic at LSF/MM this year. There was a general > > interest in the scope GFP_NOFS allocation context among some FS > > developers. For those who are not aware

Re: [PATCH 0/2] scop GFP_NOFS api

On Fri, Apr 29, 2016 at 03:35:42PM +1000, NeilBrown wrote: > On Tue, Apr 26 2016, Michal Hocko wrote: > > > Hi, > > we have discussed this topic at LSF/MM this year. There was a general > > interest in the scope GFP_NOFS allocation context among some FS > > developers. For those who are not aware

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Apr 29, 2016 4:27 PM, "Josh Poimboeuf" wrote: > > On Fri, Apr 29, 2016 at 02:38:02PM -0700, Andy Lutomirski wrote: > > On Fri, Apr 29, 2016 at 1:50 PM, Josh Poimboeuf wrote: > > > On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote: > > >>

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Apr 29, 2016 4:27 PM, "Josh Poimboeuf" wrote: > > On Fri, Apr 29, 2016 at 02:38:02PM -0700, Andy Lutomirski wrote: > > On Fri, Apr 29, 2016 at 1:50 PM, Josh Poimboeuf wrote: > > > On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote: > > >> On Thu, Apr 28, 2016 at 1:44 PM, Josh

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Apr 29, 2016 3:11 PM, "Jiri Kosina" wrote: > > On Fri, 29 Apr 2016, Andy Lutomirski wrote: > > > > NMI, MCE and interrupts aren't a problem because they have dedicated > > > stacks, which are easy to detect. If the tasks' stack is on an > > > exception stack or an irq stack,

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Apr 29, 2016 3:11 PM, "Jiri Kosina" wrote: > > On Fri, 29 Apr 2016, Andy Lutomirski wrote: > > > > NMI, MCE and interrupts aren't a problem because they have dedicated > > > stacks, which are easy to detect. If the tasks' stack is on an > > > exception stack or an irq stack, we consider it

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Apr 29, 2016 3:41 PM, "Josh Poimboeuf" wrote: > > On Fri, Apr 29, 2016 at 02:37:41PM -0700, Andy Lutomirski wrote: > > On Fri, Apr 29, 2016 at 2:25 PM, Josh Poimboeuf wrote: > > > I think the easiest way to make it work would be to modify the idtentry

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Apr 29, 2016 3:41 PM, "Josh Poimboeuf" wrote: > > On Fri, Apr 29, 2016 at 02:37:41PM -0700, Andy Lutomirski wrote: > > On Fri, Apr 29, 2016 at 2:25 PM, Josh Poimboeuf wrote: > > > I think the easiest way to make it work would be to modify the idtentry > > > macro to put all the idt entries in

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 4:31 PM, George Spelvin wrote: > > After researching it, I think that the "high bits of a multiply" is > in fact a decent way to do such a hash. Our emails crossed. Yes. My test harness actually likes the multiplication more than most of the specialized

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 4:31 PM, George Spelvin wrote: > > After researching it, I think that the "high bits of a multiply" is > in fact a decent way to do such a hash. Our emails crossed. Yes. My test harness actually likes the multiplication more than most of the specialized "spread out bits"

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On 04/29/2016 04:01 PM, Doug Anderson wrote: > * serial allows numbering devices by alias. Which is in fact a total nightmare. While stable device order is mandatory in serial because of console command line parameters and existing userspace expectations, it is the number one barrier to

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On 04/29/2016 04:01 PM, Doug Anderson wrote: > * serial allows numbering devices by alias. Which is in fact a total nightmare. While stable device order is mandatory in serial because of console command line parameters and existing userspace expectations, it is the number one barrier to

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

On 04/30/2016 01:36 AM, Dmitry Torokhov wrote: > Hi Ksenija, Hi all, > On Fri, Apr 29, 2016 at 01:49:11PM +0200, Ksenija Stanojevic wrote: >> Add mxs-lradc touchscreen driver. >> >> Signed-off-by: Ksenija Stanojevic >> --- >> drivers/input/touchscreen/Kconfig

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

On 04/30/2016 01:36 AM, Dmitry Torokhov wrote: > Hi Ksenija, Hi all, > On Fri, Apr 29, 2016 at 01:49:11PM +0200, Ksenija Stanojevic wrote: >> Add mxs-lradc touchscreen driver. >> >> Signed-off-by: Ksenija Stanojevic >> --- >> drivers/input/touchscreen/Kconfig| 14 +- >>

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 2:10 PM, Linus Torvalds wrote: > On Thu, Apr 28, 2016 at 11:32 AM, Linus Torvalds > wrote: >> >> hash_long/ptr really shouldn't care about the low bits being zero at >> all, because it should mix in all the

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 2:10 PM, Linus Torvalds wrote: > On Thu, Apr 28, 2016 at 11:32 AM, Linus Torvalds > wrote: >> >> hash_long/ptr really shouldn't care about the low bits being zero at >> all, because it should mix in all the bits (using a prime multiplier >> and taking the high bits). > >

Re: [RFC PATCH v1 13/18] x86: DMA support for memory encryption

On 04/29/2016 11:27 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Apr 29, 2016 at 10:12:45AM -0500, Tom Lendacky wrote: >> On 04/29/2016 02:17 AM, Konrad Rzeszutek Wilk wrote: >>> On Tue, Apr 26, 2016 at 05:58:12PM -0500, Tom Lendacky wrote: Since DMA addresses will effectively look like 48-bit

Re: [RFC PATCH v1 13/18] x86: DMA support for memory encryption

On 04/29/2016 11:27 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Apr 29, 2016 at 10:12:45AM -0500, Tom Lendacky wrote: >> On 04/29/2016 02:17 AM, Konrad Rzeszutek Wilk wrote: >>> On Tue, Apr 26, 2016 at 05:58:12PM -0500, Tom Lendacky wrote: Since DMA addresses will effectively look like 48-bit

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

On Fri, 29 Apr 2016, David Carrillo-Cisneros wrote: When an event is terminated, intel_cqm_event_stop calls pqr_cache_update_rmid and sets state->next_rmid to the rmid of its parent in the RMID hierarchy. That would make next call to __pqr_update to update PQR_ASSOC. What about all the

Re: [PATCH 26/32] perf/x86/intel/cqm: integrate CQM cgroups with scheduler

On Fri, 29 Apr 2016, David Carrillo-Cisneros wrote: When an event is terminated, intel_cqm_event_stop calls pqr_cache_update_rmid and sets state->next_rmid to the rmid of its parent in the RMID hierarchy. That would make next call to __pqr_update to update PQR_ASSOC. What about all the

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Fri, Apr 29, 2016 at 02:12:20PM +0200, Michal Hocko wrote: > On Fri 29-04-16 07:51:45, Dave Chinner wrote: > > On Thu, Apr 28, 2016 at 10:17:59AM +0200, Michal Hocko wrote: > > > [Trim the CC list] > > > On Wed 27-04-16 08:58:45, Dave Chinner wrote: > > > [...] > > > > Often these are to

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Fri, Apr 29, 2016 at 02:12:20PM +0200, Michal Hocko wrote: > On Fri 29-04-16 07:51:45, Dave Chinner wrote: > > On Thu, Apr 28, 2016 at 10:17:59AM +0200, Michal Hocko wrote: > > > [Trim the CC list] > > > On Wed 27-04-16 08:58:45, Dave Chinner wrote: > > > [...] > > > > Often these are to

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

Hi Ksenija, On Fri, Apr 29, 2016 at 01:49:11PM +0200, Ksenija Stanojevic wrote: > Add mxs-lradc touchscreen driver. > > Signed-off-by: Ksenija Stanojevic > --- > drivers/input/touchscreen/Kconfig| 14 +- > drivers/input/touchscreen/Makefile | 1 +

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

Hi Ksenija, On Fri, Apr 29, 2016 at 01:49:11PM +0200, Ksenija Stanojevic wrote: > Add mxs-lradc touchscreen driver. > > Signed-off-by: Ksenija Stanojevic > --- > drivers/input/touchscreen/Kconfig| 14 +- > drivers/input/touchscreen/Makefile | 1 + >

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 9:32 PM, Linus Torvalds wrote: wrote: > For example, that _long_ range of bits set ("7fffc" in the middle) > is effectively just one bit set with a subtraction. And it's *right* > in that bit area that is supposed to shuffle bits 14-40 to

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

On Fri, Apr 29, 2016 at 9:32 PM, Linus Torvalds wrote: wrote: > For example, that _long_ range of bits set ("7fffc" in the middle) > is effectively just one bit set with a subtraction. And it's *right* > in that bit area that is supposed to shuffle bits 14-40 to the high bits > (which is what

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

[+cc Matt, because I'm out of my depth in this UEFI stuff] On Fri, Apr 29, 2016 at 11:52:47PM +0200, Alexander Graf wrote: > On 29.04.16 23:37, Bjorn Helgaas wrote: > > On Fri, Apr 29, 2016 at 10:51:34PM +0200, Alexander Graf wrote: > >> I think the only thing we can really take as granted is

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

[+cc Matt, because I'm out of my depth in this UEFI stuff] On Fri, Apr 29, 2016 at 11:52:47PM +0200, Alexander Graf wrote: > On 29.04.16 23:37, Bjorn Helgaas wrote: > > On Fri, Apr 29, 2016 at 10:51:34PM +0200, Alexander Graf wrote: > >> I think the only thing we can really take as granted is

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Fri, Apr 29, 2016 at 02:38:02PM -0700, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:50 PM, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote: > >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf > >>

Re: [RFC PATCH v2 03/18] x86/asm/head: standardize the bottom of the stack for idle tasks

On Fri, Apr 29, 2016 at 02:38:02PM -0700, Andy Lutomirski wrote: > On Fri, Apr 29, 2016 at 1:50 PM, Josh Poimboeuf wrote: > > On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote: > >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf > >> wrote: > >> > Thanks to all the recent x86

  1   2   3   4   5   6   7   8   9   10   >