[PATCH 02/19] perf thread_map: Use readdir() instead of deprecated readdir_r()

From: Arnaldo Carvalho de Melo The readdir() function is thread safe as long as just one thread uses a DIR, which is the case in thread_map, so, to avoid breaking the build with glibc-2.23.90 (upcoming 2.24), use it instead of readdir_r(). See:

[PATCH 19/19] perf trace: Print unresolved symbol names as addresses

From: Arnaldo Carvalho de Melo Instead of having "[unknown]" as the name used for unresolved symbols, use the address in the callchain, in hexadecimal form: 28.801 ( 0.007 ms): qemu-system-x8/10065 ppoll(ufds: 0x55c98b39e400, nfds: 72, tsp: 0x7fffe4e4fe60, sigsetsize: 8) = 0 Timeout

[PATCH 16/19] perf evsel: Rename config_callgraph() to config_callchain() and make it public

From: Arnaldo Carvalho de Melo The rename is for consistency with the parameter name. Make it public for fine grained control of which evsels should have callchains enabled, like, for instance, will be done in the next changesets in 'perf trace', to enable callchains just on

[PATCH 10/19] perf trace: Add support for printing call chains on sys_exit events.

From: Milian Wolff Now, one can print the call chain for every encountered sys_exit event, e.g.: $ perf trace -e nanosleep --call-graph dwarf path/to/ex_sleep 1005.757 (1000.090 ms): ex_sleep/13167 nanosleep(...) = 0

[PATCH 13/19] perf trace: Exclude the kernel part of the callchain leading to a syscall

From: Arnaldo Carvalho de Melo The kernel parts are not that useful: # trace -m 512 -e nanosleep --call dwarf usleep 1 0.065 ( 0.065 ms): usleep/18732 nanosleep(rqtp: 0x7ffc4ee4e200) = 0 syscall_slow_exit_work ([kernel.kallsyms])

[PATCH 05/19] perf dwarf: Guard !x86_64 definitions under #ifdef else clause

From: Arnaldo Carvalho de Melo To fix the build on Fedora Rawhide (gcc 6.0.0 20160311 (Red Hat 6.0.0-0.17): CC /tmp/build/perf/arch/x86/util/dwarf-regs.o arch/x86/util/dwarf-regs.c:66:36: error: 'x86_32_regoffset_table' defined but not used

[PATCH 13/19] perf trace: Exclude the kernel part of the callchain leading to a syscall

From: Arnaldo Carvalho de Melo The kernel parts are not that useful: # trace -m 512 -e nanosleep --call dwarf usleep 1 0.065 ( 0.065 ms): usleep/18732 nanosleep(rqtp: 0x7ffc4ee4e200) = 0 syscall_slow_exit_work ([kernel.kallsyms])

[PATCH 05/19] perf dwarf: Guard !x86_64 definitions under #ifdef else clause

From: Arnaldo Carvalho de Melo To fix the build on Fedora Rawhide (gcc 6.0.0 20160311 (Red Hat 6.0.0-0.17): CC /tmp/build/perf/arch/x86/util/dwarf-regs.o arch/x86/util/dwarf-regs.c:66:36: error: 'x86_32_regoffset_table' defined but not used [-Werror=unused-const-variable=]

[PATCH 16/19] perf evsel: Rename config_callgraph() to config_callchain() and make it public

From: Arnaldo Carvalho de Melo The rename is for consistency with the parameter name. Make it public for fine grained control of which evsels should have callchains enabled, like, for instance, will be done in the next changesets in 'perf trace', to enable callchains just on the

[PATCH 10/19] perf trace: Add support for printing call chains on sys_exit events.

From: Milian Wolff Now, one can print the call chain for every encountered sys_exit event, e.g.: $ perf trace -e nanosleep --call-graph dwarf path/to/ex_sleep 1005.757 (1000.090 ms): ex_sleep/13167 nanosleep(...) = 0 syscall_slow_exit_work

[PATCH 18/19] perf evsel: Allow unresolved symbol names to be printed as addresses

From: Arnaldo Carvalho de Melo The fprintf_sym() and fprintf_callchain() methods now allow users to change the existing behaviour of showing "[unknown]" as the name of unresolved symbols to instead show "[0x123456]", i.e. its address. The current patch doesn't change tools to

[PATCH 15/19] perf evlist: Add (reset,set)_sample_bit methods

From: Arnaldo Carvalho de Melo For fiddling with sample_type fields in all evsels in an evlist. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim

[GIT PULL 00/19] perf/core improvements

-04-08 09:58:15 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160411 for you to fetch changes up to 00768a2bd3245eace0690fcf2c02776a256b66d7: perf trace: Print unresolved symbol names as addresses (2016

[PATCH 18/19] perf evsel: Allow unresolved symbol names to be printed as addresses

From: Arnaldo Carvalho de Melo The fprintf_sym() and fprintf_callchain() methods now allow users to change the existing behaviour of showing "[unknown]" as the name of unresolved symbols to instead show "[0x123456]", i.e. its address. The current patch doesn't change tools to use this facility,

[PATCH 15/19] perf evlist: Add (reset,set)_sample_bit methods

From: Arnaldo Carvalho de Melo For fiddling with sample_type fields in all evsels in an evlist. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-dg6yavctt0hzl2tsgfb43...@git.kernel.org Signed-off-by: Arnaldo

[GIT PULL 00/19] perf/core improvements

-04-08 09:58:15 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160411 for you to fetch changes up to 00768a2bd3245eace0690fcf2c02776a256b66d7: perf trace: Print unresolved symbol names as addresses (2016

Re: [PATCH 4.5 079/238] crypto: ccp - Dont assume export/import areas are aligned

On Sun, 2016-04-10 at 11:34 -0700, Greg Kroah-Hartman wrote: > 4.5-stable review patch.  If anyone has any objections, please let me know. I object, because this introduces an information leak. [...] > --- a/drivers/crypto/ccp/ccp-crypto-sha.c > +++ b/drivers/crypto/ccp/ccp-crypto-sha.c > @@

[PATCH 11/19] perf evsel: Rename print_ip() to fprintf_sym()

From: Arnaldo Carvalho de Melo As it receives a FILE, and its more than just the IP, which can even be requested not to be printed. For consistency with other similar methods in tools/perf/, name it as perf_evsel__fprintf_sym() and make it return the number of bytes printed,

[PATCH 14/19] perf evsel: Do not use globals in config()

From: Arnaldo Carvalho de Melo Instead receive a callchain_param pointer to configure callchain aspects, not doing so if NULL is passed. This will allow fine grained control over which evsels in an evlist gets callchains enabled. Cc: Adrian Hunter Cc:

Re: [PATCH 4.5 079/238] crypto: ccp - Dont assume export/import areas are aligned

On Sun, 2016-04-10 at 11:34 -0700, Greg Kroah-Hartman wrote: > 4.5-stable review patch.  If anyone has any objections, please let me know. I object, because this introduces an information leak. [...] > --- a/drivers/crypto/ccp/ccp-crypto-sha.c > +++ b/drivers/crypto/ccp/ccp-crypto-sha.c > @@

[PATCH 11/19] perf evsel: Rename print_ip() to fprintf_sym()

From: Arnaldo Carvalho de Melo As it receives a FILE, and its more than just the IP, which can even be requested not to be printed. For consistency with other similar methods in tools/perf/, name it as perf_evsel__fprintf_sym() and make it return the number of bytes printed, just like

[PATCH 14/19] perf evsel: Do not use globals in config()

From: Arnaldo Carvalho de Melo Instead receive a callchain_param pointer to configure callchain aspects, not doing so if NULL is passed. This will allow fine grained control over which evsels in an evlist gets callchains enabled. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian

[PATCH 03/19] perf tools: Use readdir() instead of deprecated readdir_r()

From: Arnaldo Carvalho de Melo The readdir() function is thread safe as long as just one thread uses a DIR, which is the case when synthesizing events for pre-existing threads by traversing /proc, so, to avoid breaking the build with glibc-2.23.90 (upcoming 2.24), use it instead

[PATCH 03/19] perf tools: Use readdir() instead of deprecated readdir_r()

From: Arnaldo Carvalho de Melo The readdir() function is thread safe as long as just one thread uses a DIR, which is the case when synthesizing events for pre-existing threads by traversing /proc, so, to avoid breaking the build with glibc-2.23.90 (upcoming 2.24), use it instead of readdir_r().

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 08:23:00PM -0500, Eric W. Biederman wrote: > Perhaps I am reading the code wrong but as I read it that information is > simply not available in get_super. Correct. For a very good reason - the same superblock can bloody well end up in many places; having it tied to _the_

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 08:23:00PM -0500, Eric W. Biederman wrote: > Perhaps I am reading the code wrong but as I read it that information is > simply not available in get_super. Correct. For a very good reason - the same superblock can bloody well end up in many places; having it tied to _the_

Re: [PATCH v2 4/4] ACPI: PCI: Add generic PCI host controller

Hi Jayachandran, [auto build test ERROR on pci/next] [also build test ERROR on v4.6-rc3 next-20160411] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Jayachandran-C/ACPI-based-PCI-host-driver

Re: [PATCH v2 4/4] ACPI: PCI: Add generic PCI host controller

Hi Jayachandran, [auto build test ERROR on pci/next] [also build test ERROR on v4.6-rc3 next-20160411] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Jayachandran-C/ACPI-based-PCI-host-driver

Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY

On Tue, Apr 12, 2016 at 3:23 AM, Florian Fainelli wrote: > On 04/04/16 09:22, Chen-Yu Tsai wrote: >> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and >> configured through a memory mapped hardware register. >> >> This same register also configures the

Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY

On Tue, Apr 12, 2016 at 3:23 AM, Florian Fainelli wrote: > On 04/04/16 09:22, Chen-Yu Tsai wrote: >> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and >> configured through a memory mapped hardware register. >> >> This same register also configures the MAC interface mode and

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 07:10:47PM -0500, Eric W. Biederman wrote: > Actually for me this is about keeping the semantics simpler, and coming > up with a higher performance implementation. > > A dentry that does an automount is already well defined. > > Making the rule that accessing /dev/ptmx

Re: [PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote: > Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy > mixes the bus clock with the display controllers pixel clock. Tests > have shown that the gates in CCM_CCGR3/9 registers do not control > the DCU pixel clock, but

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 07:10:47PM -0500, Eric W. Biederman wrote: > Actually for me this is about keeping the semantics simpler, and coming > up with a higher performance implementation. > > A dentry that does an automount is already well defined. > > Making the rule that accessing /dev/ptmx

Re: [PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote: > Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy > mixes the bus clock with the display controllers pixel clock. Tests > have shown that the gates in CCM_CCGR3/9 registers do not control > the DCU pixel clock, but

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

"H. Peter Anvin" writes: > On April 11, 2016 5:10:47 PM PDT, ebied...@xmission.com wrote: >>Linus Torvalds writes: >> >>> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman >>> wrote: My practical concern if we

Re: [PATCH 4.5 058/238] USB: iowarrior: fix oops with malicious USB descriptors

On Sun, 2016-04-10 at 11:33 -0700, Greg Kroah-Hartman wrote: > 4.5-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Josh Boyer > > commit 4ec0ef3a82125efc36173062a50624550a900ae0 upstream. > > The iowarrior

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

"H. Peter Anvin" writes: > On April 11, 2016 5:10:47 PM PDT, ebied...@xmission.com wrote: >>Linus Torvalds writes: >> >>> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman >>> wrote: My practical concern if we worked through the implementation details would be how would it

Re: [PATCH 4.5 058/238] USB: iowarrior: fix oops with malicious USB descriptors

On Sun, 2016-04-10 at 11:33 -0700, Greg Kroah-Hartman wrote: > 4.5-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Josh Boyer > > commit 4ec0ef3a82125efc36173062a50624550a900ae0 upstream. > > The iowarrior driver expects at least one

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 07:48:28AM -0700, H. Peter Anvin wrote: > Here is an entire different approach, I don't know if it is sane or not: when > *mounting* the devpts filesystem, it could automagically create the bins > mount for ptmx in the parent of its mount point. Presumably the would be

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 07:48:28AM -0700, H. Peter Anvin wrote: > Here is an entire different approach, I don't know if it is sane or not: when > *mounting* the devpts filesystem, it could automagically create the bins > mount for ptmx in the parent of its mount point. Presumably the would be

Re: [GIT PULL] ext4 bug fixes for 4.6

Linus, Thanks for reverting the broken commit. I'll work on a proper fix for the readdir() issue for the next merge cycle, and make sure it gets proper testing. I'll also take care of packaging up Greg's test program and getting it submitted to xfstests so we have a proper regression test case.

Re: [GIT PULL] ext4 bug fixes for 4.6

Linus, Thanks for reverting the broken commit. I'll work on a proper fix for the readdir() issue for the next merge cycle, and make sure it gets proper testing. I'll also take care of packaging up Greg's test program and getting it submitted to xfstests so we have a proper regression test case.

Re: [PATCH 0/9] RxRPC: 2nd rewrite part 1

From: David Howells Date: Mon, 11 Apr 2016 23:01:39 +0100 > David Miller wrote: > >> Series applied, but I had to fix up some trailing whitespace (reported by >> GIT) by hand. > > Do you perchance have a git hook script for checking for trailing

Re: [PATCH 0/9] RxRPC: 2nd rewrite part 1

From: David Howells Date: Mon, 11 Apr 2016 23:01:39 +0100 > David Miller wrote: > >> Series applied, but I had to fix up some trailing whitespace (reported by >> GIT) by hand. > > Do you perchance have a git hook script for checking for trailing whitespace? Just try to apply the series

Re: i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

Hi, > > We've fixed piles of those in recent kernels, but didn't backport all the > > fixes (since usually it's a silent failure, but it can correlate with > > black screens). > > Not quite completely, it seems ... > > I have built drm-intel-nightly (f261f82359), and I'm getting this: [...]

Re: i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

Hi, > > We've fixed piles of those in recent kernels, but didn't backport all the > > fixes (since usually it's a silent failure, but it can correlate with > > black screens). > > Not quite completely, it seems ... > > I have built drm-intel-nightly (f261f82359), and I'm getting this: [...]

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 6:06 PM, H. Peter Anvin wrote: > > Why bother with an automount? You can look up ../ptmx from the devpts > get_super method and just do the bind mount once. No fuss, no muss. What's > wrong with that? Ehh. What if somebody wants to mount the same

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 6:06 PM, H. Peter Anvin wrote: > > Why bother with an automount? You can look up ../ptmx from the devpts > get_super method and just do the bind mount once. No fuss, no muss. What's > wrong with that? Ehh. What if somebody wants to mount the same devpts in multiple

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

On Monday, April 11, 2016 10:58:06 AM Eric Paris wrote: > I'm all for a way to shut up unsolicited audit messages, especially > seccomp with errno or trap. I think it would be best to default 'KILL' > to on and everything else to off. I'm no so sure a sysctl is the right > way though. Enabling

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

On Monday, April 11, 2016 10:58:06 AM Eric Paris wrote: > I'm all for a way to shut up unsolicited audit messages, especially > seccomp with errno or trap. I think it would be best to default 'KILL' > to on and everything else to off. I'm no so sure a sysctl is the right > way though. Enabling

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 11, 2016 5:10:47 PM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman >> wrote: >>> >>> My practical concern if we worked through the implementation details >>> would be

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 11, 2016 5:10:47 PM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman >> wrote: >>> >>> My practical concern if we worked through the implementation details >>> would be how would it interact with people who bind mount

[PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

Add a binding to Documentation/devicetree/bindings/powerpc/opal (oppanel-opal.txt) for the operator panel which is present on IBM pseries machines with FSPs. Signed-off-by: Suraj Jitindar Singh --- .../devicetree/bindings/powerpc/opal/oppanel-opal.txt | 14

[PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

Add a binding to Documentation/devicetree/bindings/powerpc/opal (oppanel-opal.txt) for the operator panel which is present on IBM pseries machines with FSPs. Signed-off-by: Suraj Jitindar Singh --- .../devicetree/bindings/powerpc/opal/oppanel-opal.txt | 14 ++ 1 file changed,

[PATCH V2 2/2] powerpc/drivers: Add driver for operator panel on FSP machines

Implement new character device driver to allow access from user space to the 2x16 character operator panel display present on IBM Power Systems machines with FSPs. This will allow status information to be presented on the display which is visible to a user. The driver implements a 32 character

[PATCH V2 2/2] powerpc/drivers: Add driver for operator panel on FSP machines

Implement new character device driver to allow access from user space to the 2x16 character operator panel display present on IBM Power Systems machines with FSPs. This will allow status information to be presented on the display which is visible to a user. The driver implements a 32 character

Re: [PATCH 04/15] task_diag: add a new interface to get information about tasks (v4)

Hi Andrey, [auto build test ERROR on v4.6-rc3] [also build test ERROR on next-20160411] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Andrey-Vagin/task_diag-add-a-new-interface-to-get

Re: [PATCH 04/15] task_diag: add a new interface to get information about tasks (v4)

Hi Andrey, [auto build test ERROR on v4.6-rc3] [also build test ERROR on next-20160411] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Andrey-Vagin/task_diag-add-a-new-interface-to-get

Re: [PATCH v2] ARM: dts: imx6: Add dts for Embest MarS Board

Hi Sergio, On Mon, Apr 11, 2016 at 9:25 PM, Sergio Prado wrote: > Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 > Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC > and with a 4MB SPI flash. > > [1]

Re: [PATCH v2] ARM: dts: imx6: Add dts for Embest MarS Board

Hi Sergio, On Mon, Apr 11, 2016 at 9:25 PM, Sergio Prado wrote: > Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 > Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC > and with a 4MB SPI flash. > > [1]

Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

On Tue, Apr 05, 2016 at 01:31:41PM +0530, Laxman Dewangan wrote: > On Friday 01 April 2016 09:41 PM, Mark Brown wrote: > >>As per datasheet, There is no direct equation for ramp time deviation when > >>regulator output current cross the regulator current limit. > >OK, so it's really a current

Re: [PATCH 2/2] powerpc/drivers: Add driver for operator panel on FSP machines

On 11/04/16 15:27, Andrew Donnellan wrote: > On 11/04/16 11:41, Suraj Jitindar Singh wrote: >> Implement new character device driver to allow access from user space >> to the 2x16 character operator panel display present on powernv machines. > > Specifically, on IBM Power Systems machines with

Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

On Tue, Apr 05, 2016 at 01:31:41PM +0530, Laxman Dewangan wrote: > On Friday 01 April 2016 09:41 PM, Mark Brown wrote: > >>As per datasheet, There is no direct equation for ramp time deviation when > >>regulator output current cross the regulator current limit. > >OK, so it's really a current

Re: [PATCH 2/2] powerpc/drivers: Add driver for operator panel on FSP machines

On 11/04/16 15:27, Andrew Donnellan wrote: > On 11/04/16 11:41, Suraj Jitindar Singh wrote: >> Implement new character device driver to allow access from user space >> to the 2x16 character operator panel display present on powernv machines. > > Specifically, on IBM Power Systems machines with

[PATCH] media: remove Managed Media Interfaces

Remove Managed Media Interfaces: media_device_get_devres() media_device_find_devres() Using these interfaces leads to use-after-free race conditions on the shared media device during media device unregister by drivers using it. Signed-off-by: Shuah Khan ---

[PATCH] media: remove Managed Media Interfaces

Remove Managed Media Interfaces: media_device_get_devres() media_device_find_devres() Using these interfaces leads to use-after-free race conditions on the shared media device during media device unregister by drivers using it. Signed-off-by: Shuah Khan --- drivers/media/media-device.c | 26

[RFC 2/2] time: double check if watchdog clocksource is correct

We use watchdog clocksource to detect unstable clocksource. This assumes watchdog clocksource is correct. But it's possible watchdog clocksource is crappy, please see previous patch. Double check if watchdog interval is too long and bypass potential wrong watchdog clocksource. Signed-off-by:

[RFC 2/2] time: double check if watchdog clocksource is correct

We use watchdog clocksource to detect unstable clocksource. This assumes watchdog clocksource is correct. But it's possible watchdog clocksource is crappy, please see previous patch. Double check if watchdog interval is too long and bypass potential wrong watchdog clocksource. Signed-off-by:

[RFC 1/2] time: workaround crappy hpet

Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making clocksource switching to hpet. We found similar symptom in another machine. Here is an example: [8224517.520885] timekeeping watchdog: Marking clocksource 'tsc' as unstable, because the skew is too large: [8224517.540032]

[RFC 1/2] time: workaround crappy hpet

Calvin found 'perf record -a --call-graph dwarf -- sleep 5' making clocksource switching to hpet. We found similar symptom in another machine. Here is an example: [8224517.520885] timekeeping watchdog: Marking clocksource 'tsc' as unstable, because the skew is too large: [8224517.540032]

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 5:22 PM, Eric W. Biederman wrote: > > I meant the one where I conceded that the only think that it could > possible protect against was a denial of service attack, from which we > probably don't care. Yeah, that's the same email I was talking about,

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 5:22 PM, Eric W. Biederman wrote: > > I meant the one where I conceded that the only think that it could > possible protect against was a denial of service attack, from which we > probably don't care. Yeah, that's the same email I was talking about, I was just quoting

RE: [PATCH 13/14] staging: fsl-mc: return -EINVAL for all fsl_mc_portal_allocate() failures

> -Original Message- > From: Stuart Yoder > Date: Mon, Apr 11, 2016 at 11:56 AM > Subject: [PATCH 13/14] staging: fsl-mc: return -EINVAL for all > fsl_mc_portal_allocate() failures > To: gre...@linuxfoundation.org, german.riv...@nxp.com > Cc:

RE: [PATCH 13/14] staging: fsl-mc: return -EINVAL for all fsl_mc_portal_allocate() failures

> -Original Message- > From: Stuart Yoder > Date: Mon, Apr 11, 2016 at 11:56 AM > Subject: [PATCH 13/14] staging: fsl-mc: return -EINVAL for all > fsl_mc_portal_allocate() failures > To: gre...@linuxfoundation.org, german.riv...@nxp.com > Cc: de...@driverdev.osuosl.org,

Re: [PATCH v2 3/4] PCI: generic, thunder: update to use generic ECAM API

On 04/11/2016 03:45 PM, Jayachandran C wrote: Use functions provided by drivers/pci/ecam.h for mapping the config space in drivers/pci/host/pci-host-common.c, and update its users to use 'struct pci_config_window' and 'struct pci_generic_ecam_ops' The changes are mostly to use 'struct

Re: [PATCH v2 3/4] PCI: generic, thunder: update to use generic ECAM API

On 04/11/2016 03:45 PM, Jayachandran C wrote: Use functions provided by drivers/pci/ecam.h for mapping the config space in drivers/pci/host/pci-host-common.c, and update its users to use 'struct pci_config_window' and 'struct pci_generic_ecam_ops' The changes are mostly to use 'struct

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

Linus Torvalds writes: > On Mon, Apr 11, 2016 at 4:49 PM, Eric W. Biederman > wrote: >> >> I replied earlier. Did you not see my reply? > > > Are you talking about the one where you agreed that the scenario was > made up and insane? The one

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

Linus Torvalds writes: > On Mon, Apr 11, 2016 at 4:49 PM, Eric W. Biederman > wrote: >> >> I replied earlier. Did you not see my reply? > > > Are you talking about the one where you agreed that the scenario was > made up and insane? The one where you said that you're worried about > breaking

Re: sched: tweak select_idle_sibling to look for idle threads

On Mon, Apr 11, 2016 at 06:54:21AM +0200, Mike Galbraith wrote: > On Sun, 2016-04-10 at 15:55 -0400, Chris Mason wrote: > > On Sun, Apr 10, 2016 at 12:04:21PM +0200, Mike Galbraith wrote: > > > On Sat, 2016-04-09 at 15:05 -0400, Chris Mason wrote: > > > > > > > This does preserve the existing

Re: sched: tweak select_idle_sibling to look for idle threads

On Mon, Apr 11, 2016 at 06:54:21AM +0200, Mike Galbraith wrote: > On Sun, 2016-04-10 at 15:55 -0400, Chris Mason wrote: > > On Sun, Apr 10, 2016 at 12:04:21PM +0200, Mike Galbraith wrote: > > > On Sat, 2016-04-09 at 15:05 -0400, Chris Mason wrote: > > > > > > > This does preserve the existing

Re: [PATCH 4.5 036/238] aacraid: Set correct msix count for EEH recovery

On Sun, 2016-04-10 at 11:33 -0700, Greg Kroah-Hartman wrote: > 4.5-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Raghava Aditya Renukunta > > commit ecc479e00db8eb110b200afe1effcb3df20ca7ae upstream. >

Re: [PATCH 4.5 036/238] aacraid: Set correct msix count for EEH recovery

On Sun, 2016-04-10 at 11:33 -0700, Greg Kroah-Hartman wrote: > 4.5-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Raghava Aditya Renukunta > > commit ecc479e00db8eb110b200afe1effcb3df20ca7ae upstream. > > During EEH recovery number of

[PATCH v2] ARM: dts: imx6: Add dts for Embest MarS Board

Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC and with a 4MB SPI flash. [1] http://www.embest-tech.com/shop/star/marsboard.html Signed-off-by: Sergio Prado --- Changes

[PATCH v2] ARM: dts: imx6: Add dts for Embest MarS Board

Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC and with a 4MB SPI flash. [1] http://www.embest-tech.com/shop/star/marsboard.html Signed-off-by: Sergio Prado --- Changes v1 -> v2: - Makefile entry

Re: [PATCH v2 2/4] PCI: Provide common functions for ECAM mapping

On 04/11/2016 03:45 PM, Jayachandran C wrote: Add config option PCI_GENERIC_ECAM and file drivers/pci/ecam.c to provide generic functions for accessing memory mapped PCI config space. The API is defined in drivers/pci/ecam.h and is written to replace the API in

Re: [PATCH v2 2/4] PCI: Provide common functions for ECAM mapping

On 04/11/2016 03:45 PM, Jayachandran C wrote: Add config option PCI_GENERIC_ECAM and file drivers/pci/ecam.c to provide generic functions for accessing memory mapped PCI config space. The API is defined in drivers/pci/ecam.h and is written to replace the API in

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

Hello, On Mon, Apr 11, 2016 at 10:04:42AM +0200, Jakob Unterwurzacher wrote: > What seems to be happening in the kernel is that the estimated device bandwith > drops to zero. I'm not even sure how this works for FUSE, but that's what I > gathered from some printk debugging. Yeah, writeback bw

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

Hello, On Mon, Apr 11, 2016 at 10:04:42AM +0200, Jakob Unterwurzacher wrote: > What seems to be happening in the kernel is that the estimated device bandwith > drops to zero. I'm not even sure how this works for FUSE, but that's what I > gathered from some printk debugging. Yeah, writeback bw

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

Linus Torvalds writes: > On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman > wrote: >> >> My practical concern if we worked through the implementation details >> would be how would it interact with people who bind mount /dev/pts/ptmx >> on

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

Linus Torvalds writes: > On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman > wrote: >> >> My practical concern if we worked through the implementation details >> would be how would it interact with people who bind mount /dev/pts/ptmx >> on top of /dev/ptmx. We might get some strange new

RE: [PATCH] IOSF: Add interface for the cases requiring fid

> In subject better to use x86/platform/iosf_mbi prefix. Will update commit message. >> Some implementations may require an additional step for setting the >> FID > What FID stands for? Function ID defined in IOSF specification. Will add more detail in the updated commit message. >> Change-Id:

RE: [PATCH] IOSF: Add interface for the cases requiring fid

> In subject better to use x86/platform/iosf_mbi prefix. Will update commit message. >> Some implementations may require an additional step for setting the >> FID > What FID stands for? Function ID defined in IOSF specification. Will add more detail in the updated commit message. >> Change-Id:

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 4:49 PM, Eric W. Biederman wrote: > > I replied earlier. Did you not see my reply? Are you talking about the one where you agreed that the scenario was made up and insane? The one where you said that you're worried about breaking out "extension"

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 4:49 PM, Eric W. Biederman wrote: > > I replied earlier. Did you not see my reply? Are you talking about the one where you agreed that the scenario was made up and insane? The one where you said that you're worried about breaking out "extension" where ptmx is non-0666?

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman wrote: > > My practical concern if we worked through the implementation details > would be how would it interact with people who bind mount /dev/pts/ptmx > on top of /dev/ptmx. We might get some strange new errors. Yes,

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman wrote: > > My practical concern if we worked through the implementation details > would be how would it interact with people who bind mount /dev/pts/ptmx > on top of /dev/ptmx. We might get some strange new errors. Yes, please don't let's play

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

Linus Torvalds writes: > On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote: >> >> >> What we *do* want to do, though, is to prevent the following: > > I don't see the point. Why do you bring up this insane scenario that > nobody can possibly

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

Linus Torvalds writes: > On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote: >> >> >> What we *do* want to do, though, is to prevent the following: > > I don't see the point. Why do you bring up this insane scenario that > nobody can possibly care about? > > So you actually have any reason to

Re: MAINTAINERS: correct entry for LVM

On Mon, Apr 11 2016 at 11:20am -0400, Sudip Mukherjee wrote: > The entry of dm-de...@redhat.com was duplicated and the duplicate entry > was marked as a Maintainer but it appears from the email address that it > is a List. So remove the entry of M and only keep the L

Re: MAINTAINERS: correct entry for LVM

On Mon, Apr 11 2016 at 11:20am -0400, Sudip Mukherjee wrote: > The entry of dm-de...@redhat.com was duplicated and the duplicate entry > was marked as a Maintainer but it appears from the email address that it > is a List. So remove the entry of M and only keep the L entry. > > Signed-off-by:

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