[tip:x86/mm] x86/mm: Fix dump pagetables for 4 levels of page tables

Commit-ID: 84bbabc3a452e8085cfbd745ff0bff2b89074417 Gitweb: http://git.kernel.org/tip/84bbabc3a452e8085cfbd745ff0bff2b89074417 Author: Juergen Gross AuthorDate: Wed, 12 Apr 2017 16:36:34 +0200 Committer: Thomas Gleixner CommitDate: Thu, 13 Apr 2017 00:26:30 +0200 x86/mm: Fix dump

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote: > We can futz with that and have them specify which chain (or both) > that they want to be added to. Well, I didn't want the atomic chain to be a notifier because we can keep it simple and non-blocking. Only the process context one will

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote: > We can futz with that and have them specify which chain (or both) > that they want to be added to. Well, I didn't want the atomic chain to be a notifier because we can keep it simple and non-blocking. Only the process context one will

[PATCH] kbuild: drop -Wno-unknown-warning-option from clang options

Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), cc-option and friends work correctly for clang. However, the combination of -Werror and -Wno-unknown-warning-option makes clang happy with any unknown warning options. Once -Wno-unknown-warning-option is

[PATCH] kbuild: drop -Wno-unknown-warning-option from clang options

Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), cc-option and friends work correctly for clang. However, the combination of -Werror and -Wno-unknown-warning-option makes clang happy with any unknown warning options. Once -Wno-unknown-warning-option is

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

On Wed, Apr 12, 2017 at 4:47 PM, Eric Dumazet wrote: > On Wed, 2017-04-12 at 13:07 -0700, Cong Wang wrote: >> On Wed, Apr 12, 2017 at 8:39 AM, Willem de Bruijn >> wrote: >> > === >> >> BUG: KASAN: use-after-free in

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, Apr 13, 2017 at 12:16:39AM +0200, Borislav Petkov wrote: > ... and it is midnight here so I could be talking crap but we probably > should really split the reporting "chain" into two: This shouldn't be too painful. Users ask to be put on the chain via the wrapper: void

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

On Wed, Apr 12, 2017 at 4:47 PM, Eric Dumazet wrote: > On Wed, 2017-04-12 at 13:07 -0700, Cong Wang wrote: >> On Wed, Apr 12, 2017 at 8:39 AM, Willem de Bruijn >> wrote: >> > === >> >> BUG: KASAN: use-after-free in ipv4_datagram_support_cmsg >> >> net/ipv4/ip_sockglue.c:500

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, Apr 13, 2017 at 12:16:39AM +0200, Borislav Petkov wrote: > ... and it is midnight here so I could be talking crap but we probably > should really split the reporting "chain" into two: This shouldn't be too painful. Users ask to be put on the chain via the wrapper: void

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 11:47:49PM +0200, Borislav Petkov wrote: > so we need to think about something better to handle events down the > whole chain. Maybe route events from the atomic path to the blocking > path where the sleeping notifier callbacks can sleep as much as they > want to... ...

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 11:47:49PM +0200, Borislav Petkov wrote: > so we need to think about something better to handle events down the > whole chain. Maybe route events from the atomic path to the blocking > path where the sleeping notifier callbacks can sleep as much as they > want to... ...

Re: [PATCH v2 08/17] fs: retrofit old error reporting API onto new infrastructure

On Wed, Apr 12 2017, Jeff Layton wrote: > Now that we have a better way to store and report errors that occur > during writeback, we need to convert the existing codebase to use it. We > could just adapt all of the filesystem code and related infrastructure > to the new API, but that's a lot of

Re: [PATCH v2 08/17] fs: retrofit old error reporting API onto new infrastructure

On Wed, Apr 12 2017, Jeff Layton wrote: > Now that we have a better way to store and report errors that occur > during writeback, we need to convert the existing codebase to use it. We > could just adapt all of the filesystem code and related infrastructure > to the new API, but that's a lot of

Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers

> >>> To give some more background and rational for this change. > >>> > >>> On a platform where we have a parent MDIO bus, backed by the > >>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through > >>> net/dsa/dsa2.c) which is parented to this UniMAC MDIO bus through an > >>>

Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers

> >>> To give some more background and rational for this change. > >>> > >>> On a platform where we have a parent MDIO bus, backed by the > >>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through > >>> net/dsa/dsa2.c) which is parented to this UniMAC MDIO bus through an > >>>

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote: > > > Do you handle funky address translation too ? IE. the fact that the PCI > > addresses aren't the same as the CPU physical addresses for a BAR ? > > No, we use the CPU physical address of the BAR. If it's not mapped that > way we

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote: > > > Do you handle funky address translation too ? IE. the fact that the PCI > > addresses aren't the same as the CPU physical addresses for a BAR ? > > No, we use the CPU physical address of the BAR. If it's not mapped that > way we

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Wednesday, April 12, 2017 2:23 PM > To: Moore, Robert > Cc: Zheng, Lv ; Wysocki, Rafael J > ; Len Brown ; linux- >

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Wednesday, April 12, 2017 2:23 PM > To: Moore, Robert > Cc: Zheng, Lv ; Wysocki, Rafael J > ; Len Brown ; linux- > a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH]

Re: [PATCH v2 07/17] fs: new infrastructure for writeback error handling and reporting

On Wed, Apr 12 2017, Jeff Layton wrote: > +void __filemap_set_wb_error(struct address_space *mapping, int err) I was really hoping that this would be void __set_wb_error(wb_err_t *wb_err, int err) so Then nfs_context_set_write_error could become static void

Re: [PATCH v2 07/17] fs: new infrastructure for writeback error handling and reporting

On Wed, Apr 12 2017, Jeff Layton wrote: > +void __filemap_set_wb_error(struct address_space *mapping, int err) I was really hoping that this would be void __set_wb_error(wb_err_t *wb_err, int err) so Then nfs_context_set_write_error could become static void

Re: [PATCH v2 25/27] ia64: Use generic pci_mmap_resource_range()

On Wed, 12 Apr 2017, Tony Luck wrote: > On Wed, Apr 12, 2017 at 5:26 AM, David Woodhouse wrote: > > From: David Woodhouse > > > > Now that we eliminated the different behaviour in separately-reviewable > > commits, we can switch IA64 to the generic

Re: [PATCH v2 25/27] ia64: Use generic pci_mmap_resource_range()

On Wed, 12 Apr 2017, Tony Luck wrote: > On Wed, Apr 12, 2017 at 5:26 AM, David Woodhouse wrote: > > From: David Woodhouse > > > > Now that we eliminated the different behaviour in separately-reviewable > > commits, we can switch IA64 to the generic implementation. > > > > Signed-off-by: David

Re: [PATCH] iommu/vt-d: Make sure IOMMUs are off when intel_iommu=off

Hi Baoquan, On Wed, Apr 12, 2017 at 09:40:56AM +0800, Baoquan He wrote: > Do you plan to merge this one as urgent? > > There's bug created about this issue on rhel, it would be great if it > can be put in next or merged so that we can back port it. No, I am not sending this for v4.11, because

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, 12 Apr 2017, Borislav Petkov wrote: > On Wed, Apr 12, 2017 at 08:27:05PM +, Verma, Vishal L wrote: > > But isn't the atomic notifier call chain always called in atomic > > context? > > No, it isn't. We're calling it in normal process context in > mce_gen_pool_process() too. > > So

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, 12 Apr 2017, Borislav Petkov wrote: > On Wed, Apr 12, 2017 at 08:27:05PM +, Verma, Vishal L wrote: > > But isn't the atomic notifier call chain always called in atomic > > context? > > No, it isn't. We're calling it in normal process context in > mce_gen_pool_process() too. > > So

Re: [PATCH V3 01/16] block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler

Hi Paolo, [auto build test ERROR on block/for-next] [also build test ERROR on v4.11-rc6 next-20170412] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paolo-Valente/Introduce-the-BFQ-I-O

Re: [PATCH V3 01/16] block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler

Hi Paolo, [auto build test ERROR on block/for-next] [also build test ERROR on v4.11-rc6 next-20170412] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paolo-Valente/Introduce-the-BFQ-I-O

RE: [Regression Linux 4.11] TPM module not loaded anymore

> -Original Message- > From: Paul Menzel [mailto:pmen...@molgen.mpg.de] > Sent: Wednesday, April 12, 2017 2:27 PM > To: Moore, Robert > Cc: Jarkko Sakkinen ; Maciej S. > Szmigiero ;

RE: [Regression Linux 4.11] TPM module not loaded anymore

> -Original Message- > From: Paul Menzel [mailto:pmen...@molgen.mpg.de] > Sent: Wednesday, April 12, 2017 2:27 PM > To: Moore, Robert > Cc: Jarkko Sakkinen ; Maciej S. > Szmigiero ; linux-kernel@vger.kernel.org; > Arthur Heymans ; tpmdd-de...@lists.sourceforge.net; > gnu...@no-log.org;

Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers

On 04/11/2017 04:23 PM, Florian Fainelli wrote: > On 04/11/2017 04:14 PM, Andrew Lunn wrote: >>> To give some more background and rational for this change. >>> >>> On a platform where we have a parent MDIO bus, backed by the >>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through

Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers

On 04/11/2017 04:23 PM, Florian Fainelli wrote: > On 04/11/2017 04:14 PM, Andrew Lunn wrote: >>> To give some more background and rational for this change. >>> >>> On a platform where we have a parent MDIO bus, backed by the >>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 02:19:32PM -0700, Luck, Tony wrote: > On Wed, Apr 12, 2017 at 11:12:21PM +0200, Thomas Gleixner wrote: > > There is another solution: > > > > Convert the notifier to a blocking notifier and in the panic case, ignore > > the locking and invoke the notifier chain directly.

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 02:19:32PM -0700, Luck, Tony wrote: > On Wed, Apr 12, 2017 at 11:12:21PM +0200, Thomas Gleixner wrote: > > There is another solution: > > > > Convert the notifier to a blocking notifier and in the panic case, ignore > > the locking and invoke the notifier chain directly.

Re: [PATCH v2 25/27] ia64: Use generic pci_mmap_resource_range()

On Wed, Apr 12, 2017 at 5:26 AM, David Woodhouse wrote: > From: David Woodhouse > > Now that we eliminated the different behaviour in separately-reviewable > commits, we can switch IA64 to the generic implementation. > > Signed-off-by: David Woodhouse

Re: [PATCH v2 25/27] ia64: Use generic pci_mmap_resource_range()

On Wed, Apr 12, 2017 at 5:26 AM, David Woodhouse wrote: > From: David Woodhouse > > Now that we eliminated the different behaviour in separately-reviewable > commits, we can switch IA64 to the generic implementation. > > Signed-off-by: David Woodhouse Well it builds and boots on my last

Re: [PATCH v2 06/17] mm: doc comment for scary spot in write_one_page

On Wed, Apr 12 2017, Jeff Layton wrote: > On Wed, 2017-04-12 at 07:38 -0700, Matthew Wilcox wrote: >> On Wed, Apr 12, 2017 at 09:01:34AM -0400, Jeff Layton wrote: >> > On Wed, 2017-04-12 at 08:06 -0400, Jeff Layton wrote: >> > > Not sure what to do here just yet. >> > > >> > > Signed-off-by:

Re: [PATCH v2 06/17] mm: doc comment for scary spot in write_one_page

On Wed, Apr 12 2017, Jeff Layton wrote: > On Wed, 2017-04-12 at 07:38 -0700, Matthew Wilcox wrote: >> On Wed, Apr 12, 2017 at 09:01:34AM -0400, Jeff Layton wrote: >> > On Wed, 2017-04-12 at 08:06 -0400, Jeff Layton wrote: >> > > Not sure what to do here just yet. >> > > >> > > Signed-off-by:

RE: [Regression Linux 4.11] TPM module not loaded anymore

Dear Robert, Thank you for looking into this. On 2017-04-12 17:54, Moore, Robert wrote: And probably the dmesg if error messages appear in there. Linux doesn’t log any messages, as the `tpm` module doesn’t load. Please find the output of `sudo acpidump` attached. […] Kind regards,

RE: [Regression Linux 4.11] TPM module not loaded anymore

Dear Robert, Thank you for looking into this. On 2017-04-12 17:54, Moore, Robert wrote: And probably the dmesg if error messages appear in there. Linux doesn’t log any messages, as the `tpm` module doesn’t load. Please find the output of `sudo acpidump` attached. […] Kind regards,

Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update

On Tue, 11 Apr 2017, Vlastimil Babka wrote: > > The fallback was only intended for a cpuset on which boundaries are not > > enforced > > in critical conditions (softwall). A hardwall cpuset (CS_MEM_HARDWALL) > > should fail the allocation. > > Hmm just to clarify - I'm talking about ignoring the

Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update

On Tue, 11 Apr 2017, Vlastimil Babka wrote: > > The fallback was only intended for a cpuset on which boundaries are not > > enforced > > in critical conditions (softwall). A hardwall cpuset (CS_MEM_HARDWALL) > > should fail the allocation. > > Hmm just to clarify - I'm talking about ignoring the

Re: [PATCH] ACPICA: Export mutex functions

On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote: > The ACPICA mutex functions are based on the host OS functions, so they don't > really buy you anything. You should just use the native Linux functions. > You mean they don't really acquire the requested ACPI mutex, and the

Re: [PATCH] ACPICA: Export mutex functions

On Wed, Apr 12, 2017 at 03:29:55PM +, Moore, Robert wrote: > The ACPICA mutex functions are based on the host OS functions, so they don't > really buy you anything. You should just use the native Linux functions. > You mean they don't really acquire the requested ACPI mutex, and the

[PATCH 3/3] f2fs: fix not to set fsync/dentry mark

Otherwise, we can see stale fsync/dentry mark given by previous calls, resulting in giving up roll-forward recovery due to wrong dentry mark. Signed-off-by: Jaegeuk Kim --- fs/f2fs/node.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c

[PATCH 3/3] f2fs: fix not to set fsync/dentry mark

Otherwise, we can see stale fsync/dentry mark given by previous calls, resulting in giving up roll-forward recovery due to wrong dentry mark. Signed-off-by: Jaegeuk Kim --- fs/f2fs/node.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index

[PATCH 2/3] f2fs: allocate hot_data for atomic writes

We'd better allocate atomic writes to hot_data zone. Signed-off-by: Jaegeuk Kim --- fs/f2fs/file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 4731eb587e06..0ac833dd2634 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1531,6

[PATCH 2/3] f2fs: allocate hot_data for atomic writes

We'd better allocate atomic writes to hot_data zone. Signed-off-by: Jaegeuk Kim --- fs/f2fs/file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 4731eb587e06..0ac833dd2634 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1531,6 +1531,7 @@ static

[PATCH 1/3] f2fs: give time to flush dirty pages for checkpoint

If all the threads are waiting for checkpoint, we have no chance to flush required dirty pages. Signed-off-by: Jaegeuk Kim --- fs/f2fs/checkpoint.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index

[PATCH 1/3] f2fs: give time to flush dirty pages for checkpoint

If all the threads are waiting for checkpoint, we have no chance to flush required dirty pages. Signed-off-by: Jaegeuk Kim --- fs/f2fs/checkpoint.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index 9db92990f193..800be94f8cb3 100644 ---

Re: [PATCH v2] f2fs: fix fs corruption due to zero inode page

Change log from v1: o fix some bugs >From 9bb02c3627f46e50246bf7ab957b56ffbef623cb Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Tue, 11 Apr 2017 19:01:26 -0700 Subject: [PATCH] f2fs: fix fs corruption due to zero inode page This patch fixes the following scenario. -

Re: [PATCH v2] f2fs: fix fs corruption due to zero inode page

Change log from v1: o fix some bugs >From 9bb02c3627f46e50246bf7ab957b56ffbef623cb Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Tue, 11 Apr 2017 19:01:26 -0700 Subject: [PATCH] f2fs: fix fs corruption due to zero inode page This patch fixes the following scenario. - f2fs_create/f2fs_mkdir

Re: [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask()

On 12.4.2017 23:16, Christoph Lameter wrote: > On Wed, 12 Apr 2017, Vlastimil Babka wrote: > Well, interleave_nodes() will then potentially return a node outside of the allowed memory policy when its called for the first time after mpol_rebind_.. . But thenn it will find the next

Re: [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask()

On 12.4.2017 23:16, Christoph Lameter wrote: > On Wed, 12 Apr 2017, Vlastimil Babka wrote: > Well, interleave_nodes() will then potentially return a node outside of the allowed memory policy when its called for the first time after mpol_rebind_.. . But thenn it will find the next

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 11:12:21PM +0200, Thomas Gleixner wrote: > There is another solution: > > Convert the notifier to a blocking notifier and in the panic case, ignore > the locking and invoke the notifier chain directly. That needs some minimal > surgery in the notifier code to allow that,

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 11:12:21PM +0200, Thomas Gleixner wrote: > There is another solution: > > Convert the notifier to a blocking notifier and in the panic case, ignore > the locking and invoke the notifier chain directly. That needs some minimal > surgery in the notifier code to allow that,

Re: [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask()

On Wed, 12 Apr 2017, Vlastimil Babka wrote: > >> Well, interleave_nodes() will then potentially return a node outside of > >> the allowed memory policy when its called for the first time after > >> mpol_rebind_.. . But thenn it will find the next node within the > >> nodemask and work correctly

Re: [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask()

On Wed, 12 Apr 2017, Vlastimil Babka wrote: > >> Well, interleave_nodes() will then potentially return a node outside of > >> the allowed memory policy when its called for the first time after > >> mpol_rebind_.. . But thenn it will find the next node within the > >> nodemask and work correctly

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 08:27:05PM +, Verma, Vishal L wrote: > But isn't the atomic notifier call chain always called in atomic > context? No, it isn't. We're calling it in normal process context in mce_gen_pool_process() too. So this early exit will avoid any sleeping in atomic context. And

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 08:27:05PM +, Verma, Vishal L wrote: > But isn't the atomic notifier call chain always called in atomic > context? No, it isn't. We're calling it in normal process context in mce_gen_pool_process() too. So this early exit will avoid any sleeping in atomic context. And

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, 12 Apr 2017, Dan Williams wrote: > On Wed, Apr 12, 2017 at 1:52 PM, Luck, Tony wrote: > > On Wed, Apr 12, 2017 at 01:27:05PM -0700, Verma, Vishal L wrote: > >> > /* We only care about memory errors */ > >> > if (!(mce->status & MCACOD)) > >> >

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, 12 Apr 2017, Dan Williams wrote: > On Wed, Apr 12, 2017 at 1:52 PM, Luck, Tony wrote: > > On Wed, Apr 12, 2017 at 01:27:05PM -0700, Verma, Vishal L wrote: > >> > /* We only care about memory errors */ > >> > if (!(mce->status & MCACOD)) > >> > return NOTIFY_DONE; > >

et8ek8 camera on Nokia N900: trying to understand what is going on with modes

Hi! 5Mpix mode does not work on N900, which is something I'd like to understand. et8ek8_mode contains huge tables of register settings and parameter values, but it seems that they are not really independend. To test that theory, I started with checking values against each other. This is the

et8ek8 camera on Nokia N900: trying to understand what is going on with modes

Hi! 5Mpix mode does not work on N900, which is something I'd like to understand. et8ek8_mode contains huge tables of register settings and parameter values, but it seems that they are not really independend. To test that theory, I started with checking values against each other. This is the

Re: [PATCH v1 1/7] mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index

On Wed, 12 Apr 2017, Sathyanarayanan Kuppuswamy Natarajan wrote: > Hi Lee, > > Thanks. Will remove the code segment in next version. Please always reply inline. Top posting is frowned upon. > On Wed, Apr 12, 2017 at 3:45 AM, Lee Jones wrote: > > On Mon, 10 Apr 2017,

Re: [PATCH v1 1/7] mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index

On Wed, 12 Apr 2017, Sathyanarayanan Kuppuswamy Natarajan wrote: > Hi Lee, > > Thanks. Will remove the code segment in next version. Please always reply inline. Top posting is frowned upon. > On Wed, Apr 12, 2017 at 3:45 AM, Lee Jones wrote: > > On Mon, 10 Apr 2017,

Re: [PATCH v6] lightnvm: physical block device (pblk) target

On 04/12/2017 03:19 PM, Javier González wrote: This patch introduces pblk, a host-side translation layer for Open-Channel SSDs to expose them like block devices. The translation layer allows data placement decisions, and I/O scheduling to be managed by the host, enabling users to optimize the

Re: [PATCH v6] lightnvm: physical block device (pblk) target

On 04/12/2017 03:19 PM, Javier González wrote: This patch introduces pblk, a host-side translation layer for Open-Channel SSDs to expose them like block devices. The translation layer allows data placement decisions, and I/O scheduling to be managed by the host, enabling users to optimize the

Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash

Hi Guochun, Le 05/04/2017 à 10:37, Guochun Mao a écrit : > When nor's size larger than 16MByte, nor's address width maybe > set to 3 or 4, and controller should change address width according > to nor's setting. > > Signed-off-by: Guochun Mao > --- >

Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash

Hi Guochun, Le 05/04/2017 à 10:37, Guochun Mao a écrit : > When nor's size larger than 16MByte, nor's address width maybe > set to 3 or 4, and controller should change address width according > to nor's setting. > > Signed-off-by: Guochun Mao > --- > drivers/mtd/spi-nor/mtk-quadspi.c | 27

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 1:52 PM, Luck, Tony wrote: > On Wed, Apr 12, 2017 at 01:27:05PM -0700, Verma, Vishal L wrote: >> > /* We only care about memory errors */ >> > if (!(mce->status & MCACOD)) >> > return NOTIFY_DONE; > > N.B. that isn't a valid test

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 1:52 PM, Luck, Tony wrote: > On Wed, Apr 12, 2017 at 01:27:05PM -0700, Verma, Vishal L wrote: >> > /* We only care about memory errors */ >> > if (!(mce->status & MCACOD)) >> > return NOTIFY_DONE; > > N.B. that isn't a valid test that this is a memory

[patch V2 09/13] cpufreq/ia64: Replace racy task affinity logic

The get() and target() callbacks must run on the affected cpu. This is achieved by temporarily setting the affinity of the calling thread to the requested CPU and reset it to the original affinity afterwards. That's racy vs. concurrent affinity settings for that thread resulting in code executing

[patch V2 09/13] cpufreq/ia64: Replace racy task affinity logic

The get() and target() callbacks must run on the affected cpu. This is achieved by temporarily setting the affinity of the calling thread to the requested CPU and reset it to the original affinity afterwards. That's racy vs. concurrent affinity settings for that thread resulting in code executing

[PATCH] pwm: fix platform_no_drv_owner.cocci warnings

drivers/pwm/pwm-mediatek.c:210:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: John Crispin Signed-off-by: Fengguang Wu

[PATCH] pwm: fix platform_no_drv_owner.cocci warnings

drivers/pwm/pwm-mediatek.c:210:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: John Crispin Signed-off-by: Fengguang Wu --- pwm-mediatek.c |1 -

[patch V 2 04/13] ia64/sn/hwperf: Replace racy task affinity logic

Subject: ia64/sn/hwperf: Replace racy task affinity logic From: Thomas Gleixner Date: Thu, 06 Apr 2017 14:56:18 +0200 sn_hwperf_op_cpu() which is invoked from an ioctl requires to run code on the requested cpu. This is achieved by temporarily setting the affinity of the

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On 12.4.2017 8:46, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm-current tree got conflicts in: > > drivers/block/nbd.c > drivers/scsi/iscsi_tcp.c > net/core/dev.c > net/core/sock.c > > between commit: > > 717a94b5fc70 ("sched/core: Remove 'task'

[patch V 2 04/13] ia64/sn/hwperf: Replace racy task affinity logic

Subject: ia64/sn/hwperf: Replace racy task affinity logic From: Thomas Gleixner Date: Thu, 06 Apr 2017 14:56:18 +0200 sn_hwperf_op_cpu() which is invoked from an ioctl requires to run code on the requested cpu. This is achieved by temporarily setting the affinity of the calling user space thread

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On 12.4.2017 8:46, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm-current tree got conflicts in: > > drivers/block/nbd.c > drivers/scsi/iscsi_tcp.c > net/core/dev.c > net/core/sock.c > > between commit: > > 717a94b5fc70 ("sched/core: Remove 'task'

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 01:27:05PM -0700, Verma, Vishal L wrote: > >   /* We only care about memory errors */ > >   if (!(mce->status & MCACOD)) > >   return NOTIFY_DONE; N.B. that isn't a valid test that this is a memory error. You need if (!(m->status & 0xef80) ==

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, Apr 12, 2017 at 01:27:05PM -0700, Verma, Vishal L wrote: > >   /* We only care about memory errors */ > >   if (!(mce->status & MCACOD)) > >   return NOTIFY_DONE; N.B. that isn't a valid test that this is a memory error. You need if (!(m->status & 0xef80) ==

Re: [PATCH v2 2/3] net: macb: Remove CONFIG_OF around DT match table

On Tue, Apr 11, 2017 at 11:41 PM, Florian Fainelli wrote: > A subsequent patch is going to make of_match_node() an inline stub when > CONFIG_OF is disabled, which will let the compiler eliminate unused variables. > In order not to clutter the code more, remove the CONFIG_OF

Re: [PATCH v2 2/3] net: macb: Remove CONFIG_OF around DT match table

On Tue, Apr 11, 2017 at 11:41 PM, Florian Fainelli wrote: > A subsequent patch is going to make of_match_node() an inline stub when > CONFIG_OF is disabled, which will let the compiler eliminate unused variables. > In order not to clutter the code more, remove the CONFIG_OF #ifdef such that >

Re: [PATCH v2] libnvdimm: fix btt vs clear poison locking

On Wed, Apr 12, 2017 at 5:49 AM, Jeff Moyer wrote: > Dan Williams writes: > >> As a minimal fix, disable error clearing when the BTT is enabled for the >> namespace. For the final fix a larger rework of the poison list locking >> is needed. > > I

Re: [PATCH v2] libnvdimm: fix btt vs clear poison locking

On Wed, Apr 12, 2017 at 5:49 AM, Jeff Moyer wrote: > Dan Williams writes: > >> As a minimal fix, disable error clearing when the BTT is enabled for the >> namespace. For the final fix a larger rework of the poison list locking >> is needed. > > I think "fix" is a strong word for this patch. ;-)

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

On Wed, 2017-04-12 at 13:07 -0700, Cong Wang wrote: > On Wed, Apr 12, 2017 at 8:39 AM, Willem de Bruijn > wrote: > > === > >> BUG: KASAN: use-after-free in ipv4_datagram_support_cmsg > >> net/ipv4/ip_sockglue.c:500 [inline] at addr 880059be0128

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

On Wed, 2017-04-12 at 13:07 -0700, Cong Wang wrote: > On Wed, Apr 12, 2017 at 8:39 AM, Willem de Bruijn > wrote: > > === > >> BUG: KASAN: use-after-free in ipv4_datagram_support_cmsg > >> net/ipv4/ip_sockglue.c:500 [inline] at addr 880059be0128 > > > > Thanks for the report.

Re: [PATCH net-next v1 1/1] L2TP device MTU setup - tunnel socket needs a lock

Hi Guillaume, Please see inline: On Wed, Apr 12, 2017 at 12:53 AM, Guillaume Nault wrote: > On Tue, Apr 11, 2017 at 08:14:37PM -0700, R. Parameswaran wrote: >> >> The MTU overhead calculation in L2TP device set-up >> merged via commit

Re: [PATCH net-next v1 1/1] L2TP device MTU setup - tunnel socket needs a lock

Hi Guillaume, Please see inline: On Wed, Apr 12, 2017 at 12:53 AM, Guillaume Nault wrote: > On Tue, Apr 11, 2017 at 08:14:37PM -0700, R. Parameswaran wrote: >> >> The MTU overhead calculation in L2TP device set-up >> merged via commit b784e7ebfce8cfb16c6f95e14e8532d0768ab7ff >> needs to be

Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

On 4/12/2017 9:22 AM, Djalal Harouni wrote: > On Tue, Apr 11, 2017 at 6:43 AM, Kees Cook wrote: >> On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni wrote: >>> On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler >>> wrote: I

Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

On 4/12/2017 9:22 AM, Djalal Harouni wrote: > On Tue, Apr 11, 2017 at 6:43 AM, Kees Cook wrote: >> On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni wrote: >>> On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler >>> wrote: I think that would be the prudent approach. There is still the

Re: [PATCH] kbuild: use -Oz instead of -Os when using clang

2017-04-12 12:38 GMT+09:00 Masahiro Yamada : > Hi Matthias, > > > 2017-04-11 3:08 GMT+09:00 Matthias Kaehlcke : >> Hi Masahiro, >> >> El Fri, Mar 31, 2017 at 02:57:43AM +0900 Masahiro Yamada ha dit: >> >>> 2017-03-31 1:41 GMT+09:00 Matthias

Re: [PATCH] kbuild: use -Oz instead of -Os when using clang

2017-04-12 12:38 GMT+09:00 Masahiro Yamada : > Hi Matthias, > > > 2017-04-11 3:08 GMT+09:00 Matthias Kaehlcke : >> Hi Masahiro, >> >> El Fri, Mar 31, 2017 at 02:57:43AM +0900 Masahiro Yamada ha dit: >> >>> 2017-03-31 1:41 GMT+09:00 Matthias Kaehlcke : >>> > El Fri, Mar 31, 2017 at 01:03:02AM +0900

Re: [PATCH net-next v1 1/1] L2TP device MTU setup - tunnel socket needs a lock

Hi Dave, Please see inline: On Wed, Apr 12, 2017 at 7:13 AM, David Miller wrote: > From: "R. Parameswaran" > Date: Tue, 11 Apr 2017 20:14:37 -0700 (PDT) > >> >> The MTU overhead calculation in L2TP device set-up >> merged via commit

Re: [PATCH net-next v1 1/1] L2TP device MTU setup - tunnel socket needs a lock

Hi Dave, Please see inline: On Wed, Apr 12, 2017 at 7:13 AM, David Miller wrote: > From: "R. Parameswaran" > Date: Tue, 11 Apr 2017 20:14:37 -0700 (PDT) > >> >> The MTU overhead calculation in L2TP device set-up >> merged via commit b784e7ebfce8cfb16c6f95e14e8532d0768ab7ff >> needs to be

[PATCH nf-next] ip_vs_sync: change comparison on sync_refresh_period

The sync_refresh_period variable is unsigned, so it can never be < 0. Signed-off-by: Aaron Conole --- net/netfilter/ipvs/ip_vs_sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c index

[PATCH nf-next] ip_vs_sync: change comparison on sync_refresh_period

The sync_refresh_period variable is unsigned, so it can never be < 0. Signed-off-by: Aaron Conole --- net/netfilter/ipvs/ip_vs_sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c index b03c280..123dc0f

[PATCH resend 1/4] uapi glibc compat: add libc compat code when not build for kernel

Instead of checking if this header file is used in the glibc, check if iti is not used in kernel context, this way it will also work with other libc implementations like musl. Acked-by: Mikko Rapeli Signed-off-by: Hauke Mehrtens ---

[PATCH nf-next] nf_conntrack: remove double assignment

The protonet pointer will unconditionally be rewritten, so just do the needed assignment first. Signed-off-by: Aaron Conole --- net/netfilter/nf_conntrack_proto.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/netfilter/nf_conntrack_proto.c

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