[RFC PATCH v2 2/5] tracing: add TRACE_EVENT_MAP

This macro allows to create an alias of an existing TRACE_EVENT. A TRACE_EVENT_MAP connects a new probe to an existing tracepoint, so we can use it to create another output of the same tracepoint without changing the instrumented code. This allows to create alternate versions of existing

[RFC PATCH v2 1/5] sched: get effective policy and rt_prio

Helper functions to get the effective policy and rt_priority from the prio and policy values. This is useful in PI situations because these fields are not updated in the task, only the sched_class is temporarily modified. Cc: Peter Zijlstra Cc: Steven Rostedt (Red Hat) Cc: Thomas Gleixner Cc:

Re: [PATCH] fs/select: add vmalloc fallback for select(2)

Hi, On 09/23/2016 03:24 AM, Nicholas Piggin wrote: On Fri, 23 Sep 2016 14:42:53 +0800 "Hillf Danton" wrote: The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows with the number of fds passed. We had a customer report page allocation failures

Re: [PATCH] fs/select: add vmalloc fallback for select(2)

Hi, On 09/23/2016 03:24 AM, Nicholas Piggin wrote: On Fri, 23 Sep 2016 14:42:53 +0800 "Hillf Danton" wrote: The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows with the number of fds passed. We had a customer report page allocation failures of order-4 for this

Re: [PATCHv3 2/2] x86/vmd: Add PCI domain specific LED option

On Fri, Sep 23, 2016 at 09:34:41AM -0500, Bjorn Helgaas wrote: > I made the necessary changes to match the renaming I did in the first > patch, and I also used plain old "#ifdef" instead of "#if IS_ENABLED" > since the rest of the file uses the former style. If there's a reason > to switch, we

Re: [PATCHv3 2/2] x86/vmd: Add PCI domain specific LED option

On Fri, Sep 23, 2016 at 09:34:41AM -0500, Bjorn Helgaas wrote: > I made the necessary changes to match the renaming I did in the first > patch, and I also used plain old "#ifdef" instead of "#if IS_ENABLED" > since the rest of the file uses the former style. If there's a reason > to switch, we

[PATCH 2/3] drm/vmwgfx: Use memdup_user() rather than duplicating its implementation

From: Markus Elfring Date: Fri, 23 Sep 2016 17:26:02 +0200 * Reuse existing functionality from memdup_user() instead of keeping duplicate source code. * Try this copy operation before allocating memory for the data structure member "offsets". * Delete the

[PATCH 2/3] drm/vmwgfx: Use memdup_user() rather than duplicating its implementation

From: Markus Elfring Date: Fri, 23 Sep 2016 17:26:02 +0200 * Reuse existing functionality from memdup_user() instead of keeping duplicate source code. * Try this copy operation before allocating memory for the data structure member "offsets". * Delete the local variable "user_sizes" which

Re: [PATCH V3] clocksource/timer-imx-gpt: Preventing resource leakage in error case.

On Fri, 23 Sep 2016, Arvind Yadav wrote: So last time (V2) you had a almost perfect subject line: clocksrouce/timer-imz-gpt: Prevent resource leaks in error path The only issue was the clocksrcouce typo. Now you made it: clocksource/timer-imx-gpt: Preventing resource leakage in error case.

Re: [PATCH V3] clocksource/timer-imx-gpt: Preventing resource leakage in error case.

On Fri, 23 Sep 2016, Arvind Yadav wrote: So last time (V2) you had a almost perfect subject line: clocksrouce/timer-imz-gpt: Prevent resource leaks in error path The only issue was the clocksrcouce typo. Now you made it: clocksource/timer-imx-gpt: Preventing resource leakage in error case.

[PATCH 1/3] drm/vmwgfx: Use kmalloc_array() in vmw_surface_define_ioctl()

From: Markus Elfring Date: Thu, 22 Sep 2016 21:54:33 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected by

[PATCH 1/3] drm/vmwgfx: Use kmalloc_array() in vmw_surface_define_ioctl()

From: Markus Elfring Date: Thu, 22 Sep 2016 21:54:33 +0200 Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected by using the Coccinelle software.

[PATCH 3/3] drm/vmwgfx: Adjust checks for null pointers in 13 functions

From: Markus Elfring Date: Fri, 23 Sep 2016 17:53:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script "checkpatch.pl" can point information out like the following. Comparison to NULL could be written !…

[PATCH 3/3] drm/vmwgfx: Adjust checks for null pointers in 13 functions

From: Markus Elfring Date: Fri, 23 Sep 2016 17:53:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script "checkpatch.pl" can point information out like the following. Comparison to NULL could be written !… Thus fix the affected source code

Re: [ANNOUNCE] linux-4.7-ck5

On 09/22/2016 06:36 PM, Con Kolivas wrote: Announcing the latest release of the -ck patchset for improved responsiveness and interactivity.

Re: [ANNOUNCE] linux-4.7-ck5

On 09/22/2016 06:36 PM, Con Kolivas wrote: Announcing the latest release of the -ck patchset for improved responsiveness and interactivity.

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

On Wed, Sep 21, 2016 at 03:55:34PM +0200, Jiri Olsa wrote: > The trinity syscall fuzzer triggered following WARN on powerpc: > WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278 > ... > NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0 > LR [c093aed8]

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

On Wed, Sep 21, 2016 at 03:55:34PM +0200, Jiri Olsa wrote: > The trinity syscall fuzzer triggered following WARN on powerpc: > WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278 > ... > NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0 > LR [c093aed8]

[PATCH 0/3] drm/vmwgfx: Fine-tuning for 13 function implementations

From: Markus Elfring Date: Fri, 23 Sep 2016 18:24:32 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Use kmalloc_array() in vmw_surface_define_ioctl() Use memdup_user() rather than duplicating its

[PATCH 0/3] drm/vmwgfx: Fine-tuning for 13 function implementations

From: Markus Elfring Date: Fri, 23 Sep 2016 18:24:32 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (3): Use kmalloc_array() in vmw_surface_define_ioctl() Use memdup_user() rather than duplicating its implementation Adjust checks

Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

On Friday, September 23, 2016 4:13:30 PM CEST Robin Murphy wrote: > On 23/09/16 15:44, Arnd Bergmann wrote: > > On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote: > >> On 23/09/16 15:01, Stuart Yoder wrote: > >> Otherwise you can > >> always simply run your own shim at EL2 to drive

Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms

On Friday, September 23, 2016 4:13:30 PM CEST Robin Murphy wrote: > On 23/09/16 15:44, Arnd Bergmann wrote: > > On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote: > >> On 23/09/16 15:01, Stuart Yoder wrote: > >> Otherwise you can > >> always simply run your own shim at EL2 to drive

Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

Peter Zijlstra writes: > On Fri, Sep 23, 2016 at 05:27:22PM +0300, Alexander Shishkin wrote: >> > Afaict there's no actual need to hide the AUX buffer for this sampling >> > stuff; the user knows about all this and can simply mmap() the AUX part. >> >> Yes, you're right

Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

Peter Zijlstra writes: > On Fri, Sep 23, 2016 at 05:27:22PM +0300, Alexander Shishkin wrote: >> > Afaict there's no actual need to hide the AUX buffer for this sampling >> > stuff; the user knows about all this and can simply mmap() the AUX part. >> >> Yes, you're right here. We could also

RE: [patch v5] i2c: mux: mellanox: add driver

> -Original Message- > From: Peter Rosin [mailto:p...@axentia.se] > Sent: Friday, September 23, 2016 12:36 PM > To: Vadim Pasternak ; w...@the-dreams.de > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; j...@resnulli.us; > Michael Shych

RE: [patch v5] i2c: mux: mellanox: add driver

> -Original Message- > From: Peter Rosin [mailto:p...@axentia.se] > Sent: Friday, September 23, 2016 12:36 PM > To: Vadim Pasternak ; w...@the-dreams.de > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; j...@resnulli.us; > Michael Shych > Subject: Re: [patch v5] i2c: mux:

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

Am 23.09.2016 um 17:35 schrieb Mauro Carvalho Chehab : > Em Fri, 23 Sep 2016 09:15:01 -0600 > Jonathan Corbet escreveu: >> I'm not sure I see the value of including it in >> the docs? What am I missing here? > > It is part of the REPORTING-BUGS

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

Am 23.09.2016 um 17:35 schrieb Mauro Carvalho Chehab : > Em Fri, 23 Sep 2016 09:15:01 -0600 > Jonathan Corbet escreveu: >> I'm not sure I see the value of including it in >> the docs? What am I missing here? > > It is part of the REPORTING-BUGS procedure to check MAINTAINERS and > find to

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

On Fri, 2016-09-23 at 12:07 -0300, Mauro Carvalho Chehab wrote: > So, let's use an unusual approach: manually convert the > text at the MAINTAINERS file head, adding it at a new > Documentation/user/MAINTAINERS.rst, and include, as a code > block, the rest of MAINTAINERS contents, with only the >

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

On Fri, 2016-09-23 at 12:07 -0300, Mauro Carvalho Chehab wrote: > So, let's use an unusual approach: manually convert the > text at the MAINTAINERS file head, adding it at a new > Documentation/user/MAINTAINERS.rst, and include, as a code > block, the rest of MAINTAINERS contents, with only the >

Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges

Hello, On Fri, Sep 23, 2016 at 11:41:33PM +0800, zijun_hu wrote: > 1. ioremap_page_range() is not a kernel internal function What matters is whether the input is from userland or easy to get wrong (IOW the checks serve practical purposes). Whether a function is exported via EXPORT_SYMBOL

Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges

Hello, On Fri, Sep 23, 2016 at 11:41:33PM +0800, zijun_hu wrote: > 1. ioremap_page_range() is not a kernel internal function What matters is whether the input is from userland or easy to get wrong (IOW the checks serve practical purposes). Whether a function is exported via EXPORT_SYMBOL

Re: [PATCH v3 2/2] Documentation/filesystems/proc.txt: Add more description for maps/smaps

On 09/23/2016 06:12 AM, Robert Ho wrote: > +Note: for both /proc/PID/maps and /proc/PID/smaps readings, it's > +possible in race conditions, that the mappings printed may not be that > +up-to-date, because during each read walking, the task's mappings may have > +changed, this typically happens in

Re: [PATCH v3 2/2] Documentation/filesystems/proc.txt: Add more description for maps/smaps

On 09/23/2016 06:12 AM, Robert Ho wrote: > +Note: for both /proc/PID/maps and /proc/PID/smaps readings, it's > +possible in race conditions, that the mappings printed may not be that > +up-to-date, because during each read walking, the task's mappings may have > +changed, this typically happens in

Re: [PATCH] cpupower: Correct return type of cpu_power_is_cpu_online in cpufreq

Hi, On 09/09/2016 10:55 PM, Laura Abbott wrote: > When converting to a shared library in ac5a181d065d ("cpupower: Add > cpuidle parts into library"), cpu_freq_cpu_exists was converted to > cpupower_is_cpu_online. cpu_req_cpu_exists returned 0 on success and > -ENOSYS on failure whereas

Re: [PATCH] cpupower: Correct return type of cpu_power_is_cpu_online in cpufreq

Hi, On 09/09/2016 10:55 PM, Laura Abbott wrote: > When converting to a shared library in ac5a181d065d ("cpupower: Add > cpuidle parts into library"), cpu_freq_cpu_exists was converted to > cpupower_is_cpu_online. cpu_req_cpu_exists returned 0 on success and > -ENOSYS on failure whereas

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On 2016-09-23 23:10, Mike Galbraith wrote: I did some experiments to see when the problem first appeared. Thousands of kworker processes start to show up in 4.7.0-rc5. kernel version | kworker count after boot --- 4.6.3 > > 37 4.6.4 >

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On 2016-09-23 23:10, Mike Galbraith wrote: I did some experiments to see when the problem first appeared. Thousands of kworker processes start to show up in 4.7.0-rc5. kernel version | kworker count after boot --- 4.6.3 > > 37 4.6.4 >

Re: [PATCH 4.7 000/184] 4.7.5-stable review

On Fri, Sep 23, 2016 at 10:03:45AM -0600, Shuah Khan wrote: > On 09/22/2016 11:38 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.7.5 release. > > There are 184 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.7 000/184] 4.7.5-stable review

On Fri, Sep 23, 2016 at 10:03:45AM -0600, Shuah Khan wrote: > On 09/22/2016 11:38 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.7.5 release. > > There are 184 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH v5 1/6] of: Add vendor prefix for Engicam s.r.l company

On Fri, Sep 16, 2016 at 12:46:50AM +0530, Jagan Teki wrote: > Engicam providing design services of electronic systems with > high content of technology, relying on a long experience in > electronic design. > > For more info visit > http://www.engicam.com/en/ > > Cc: Sascha Hauer

Re: [PATCH v5 1/6] of: Add vendor prefix for Engicam s.r.l company

On Fri, Sep 16, 2016 at 12:46:50AM +0530, Jagan Teki wrote: > Engicam providing design services of electronic systems with > high content of technology, relying on a long experience in > electronic design. > > For more info visit > http://www.engicam.com/en/ > > Cc: Sascha Hauer > Cc: Fabio

Re: [PATCH] of: Prevent unaligned access in of_alias_scan()

On Fri, Sep 23, 2016 at 4:38 PM, Paul Burton wrote: > When allocating a struct alias_prop, of_alias_scan() only requested that > it be aligned on a 4 byte boundary. The struct contains pointers which > leads to us attempting 64 bit writes on 64 bit systems, and if the CPU

Re: [PATCH] of: Prevent unaligned access in of_alias_scan()

On Fri, Sep 23, 2016 at 4:38 PM, Paul Burton wrote: > When allocating a struct alias_prop, of_alias_scan() only requested that > it be aligned on a 4 byte boundary. The struct contains pointers which > leads to us attempting 64 bit writes on 64 bit systems, and if the CPU > doesn't support

Re: [PATCH] cfq: fix starvation of asynchronous writes

On 09/22/2016 08:10 PM, Jens Axboe wrote: On 09/22/2016 06:59 PM, Glauber Costa wrote: While debugging timeouts happening in my application workload (ScyllaDB), I have observed calls to open() taking a long time, ranging everywhere from 2 seconds - the first ones that are enough to time out my

Re: [PATCH] cfq: fix starvation of asynchronous writes

On 09/22/2016 08:10 PM, Jens Axboe wrote: On 09/22/2016 06:59 PM, Glauber Costa wrote: While debugging timeouts happening in my application workload (ScyllaDB), I have observed calls to open() taking a long time, ranging everywhere from 2 seconds - the first ones that are enough to time out my

Re: [PATCH 4.4 000/118] 4.4.22-stable review

On 09/22/2016 11:28 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.22 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 000/118] 4.4.22-stable review

On 09/22/2016 11:28 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.22 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH] usb: xhci: mark xhci_unmap_td_bounce_buffer() static

On Friday, September 23, 2016 5:08:37 PM CEST Greg KH wrote: > On Fri, Sep 23, 2016 at 09:46:13PM +0800, Baoyou Xie wrote: > > We get 1 warning when building kernel with W=1: > > drivers/usb/host/xhci-ring.c:608:6: warning: no previous prototype for > > 'xhci_unmap_td_bounce_buffer'

Re: [PATCH] usb: xhci: mark xhci_unmap_td_bounce_buffer() static

On Friday, September 23, 2016 5:08:37 PM CEST Greg KH wrote: > On Fri, Sep 23, 2016 at 09:46:13PM +0800, Baoyou Xie wrote: > > We get 1 warning when building kernel with W=1: > > drivers/usb/host/xhci-ring.c:608:6: warning: no previous prototype for > > 'xhci_unmap_td_bounce_buffer'

[PATCH] netns: move {inc,dec}_net_namespaces into #ifdef

With the newly enforced limit on the number of namespaces, we get a build warning if CONFIG_NETNS is disabled: net/core/net_namespace.c:273:13: error: 'dec_net_namespaces' defined but not used [-Werror=unused-function] net/core/net_namespace.c:268:24: error: 'inc_net_namespaces' defined but not

[PATCH] netns: move {inc,dec}_net_namespaces into #ifdef

With the newly enforced limit on the number of namespaces, we get a build warning if CONFIG_NETNS is disabled: net/core/net_namespace.c:273:13: error: 'dec_net_namespaces' defined but not used [-Werror=unused-function] net/core/net_namespace.c:268:24: error: 'inc_net_namespaces' defined but not

Re: [PATCH 4/7] arm64: tlbflush.h: add __tlbi() macro

On Tue, Sep 13, 2016 at 11:16:06AM +0100, Punit Agrawal wrote: > From: Mark Rutland > > As with dsb() and isb(), add a __tlbi() helper so that we can avoid > distracting asm boilerplate every time we want a TLBI. As some TLBI > operations take an argument while others do

Re: [PATCH 4/7] arm64: tlbflush.h: add __tlbi() macro

On Tue, Sep 13, 2016 at 11:16:06AM +0100, Punit Agrawal wrote: > From: Mark Rutland > > As with dsb() and isb(), add a __tlbi() helper so that we can avoid > distracting asm boilerplate every time we want a TLBI. As some TLBI > operations take an argument while others do not, some pre-processor

[PATCH] btrfs: fix btrfs_no_printk stub helper

The addition of btrfs_no_printk() caused a build failure when CONFIG_PRINTK is disabled: fs/btrfs/send.c: In function 'send_rename': fs/btrfs/ctree.h:3367:2: error: implicit declaration of function 'btrfs_no_printk' [-Werror=implicit-function-declaration] This moves the helper outside of that

[PATCH] btrfs: fix btrfs_no_printk stub helper

The addition of btrfs_no_printk() caused a build failure when CONFIG_PRINTK is disabled: fs/btrfs/send.c: In function 'send_rename': fs/btrfs/ctree.h:3367:2: error: implicit declaration of function 'btrfs_no_printk' [-Werror=implicit-function-declaration] This moves the helper outside of that

Re: [PATCH 4.7 000/184] 4.7.5-stable review

On 09/22/2016 11:38 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.7.5 release. > There are 184 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.7 000/184] 4.7.5-stable review

On 09/22/2016 11:38 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.7.5 release. > There are 184 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH v3 1/2] mm, proc: Fix region lost in /proc/self/smaps

On 09/23, Michal Hocko wrote: > > On Fri 23-09-16 15:56:36, Oleg Nesterov wrote: > > > > I think we can simplify this patch. And imo make it better. How about > > it is certainly less subtle because it doesn't report "sub-vmas". > > > if (last_addr) { > > vma = find_vma(mm,

Re: [PATCH v3 1/2] mm, proc: Fix region lost in /proc/self/smaps

On 09/23, Michal Hocko wrote: > > On Fri 23-09-16 15:56:36, Oleg Nesterov wrote: > > > > I think we can simplify this patch. And imo make it better. How about > > it is certainly less subtle because it doesn't report "sub-vmas". > > > if (last_addr) { > > vma = find_vma(mm,

[PATCH] of: Prevent unaligned access in of_alias_scan()

When allocating a struct alias_prop, of_alias_scan() only requested that it be aligned on a 4 byte boundary. The struct contains pointers which leads to us attempting 64 bit writes on 64 bit systems, and if the CPU doesn't support unaligned memory accesses then this causes problems - for example

[PATCH] of: Prevent unaligned access in of_alias_scan()

When allocating a struct alias_prop, of_alias_scan() only requested that it be aligned on a 4 byte boundary. The struct contains pointers which leads to us attempting 64 bit writes on 64 bit systems, and if the CPU doesn't support unaligned memory accesses then this causes problems - for example

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Friday, September 23, 2016 2:59:55 PM CEST Gabriele Paoloni wrote: > > > > From the perspective of the indirect IO function the input parameter > > > is an unsigned long addr that (now) can be either: > > > 1) an IO token coming from a legacy pci device > > > 2) a phys address that lives on

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Friday, September 23, 2016 2:59:55 PM CEST Gabriele Paoloni wrote: > > > > From the perspective of the indirect IO function the input parameter > > > is an unsigned long addr that (now) can be either: > > > 1) an IO token coming from a legacy pci device > > > 2) a phys address that lives on

Re: [PATCH] seq_file: don't set read position for invalid iterator

[ adding Al ] On Tue, Aug 23, 2016 at 2:19 AM, Tomasz Majchrzak wrote: > If kernfs file is empty on a first read, successive read operations > using the same file descriptor will return no data, even when data is > available. Default kernfs 'seq_next' implementation

Re: [PATCH] seq_file: don't set read position for invalid iterator

[ adding Al ] On Tue, Aug 23, 2016 at 2:19 AM, Tomasz Majchrzak wrote: > If kernfs file is empty on a first read, successive read operations > using the same file descriptor will return no data, even when data is > available. Default kernfs 'seq_next' implementation advances iterator > position

Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges

On 2016/9/23 22:42, Tejun Heo wrote: > Hello, > > On Wed, Sep 21, 2016 at 12:19:53PM +0800, zijun_hu wrote: >> From: zijun_hu >> >> endless loop maybe happen if either of parameter addr and end is not >> page aligned for kernel API function ioremap_page_range() >> >> in order

Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges

On 2016/9/23 22:42, Tejun Heo wrote: > Hello, > > On Wed, Sep 21, 2016 at 12:19:53PM +0800, zijun_hu wrote: >> From: zijun_hu >> >> endless loop maybe happen if either of parameter addr and end is not >> page aligned for kernel API function ioremap_page_range() >> >> in order to fix this issue

Re: [PATCH 0/2] Ajust lockdep static allocations

On Fri, Sep 23, 2016 at 10:15:46AM -0500, Babu Moger wrote: > >> Correct, We can't boot with lockdep. Sorry I did not make that clear. > >>We have a limit on static size of the kernel. > >This stuff should be in .bss not .data. It should not affect the static > >size at all. Or am I

Re: [PATCH 0/2] Ajust lockdep static allocations

On Fri, Sep 23, 2016 at 10:15:46AM -0500, Babu Moger wrote: > >> Correct, We can't boot with lockdep. Sorry I did not make that clear. > >>We have a limit on static size of the kernel. > >This stuff should be in .bss not .data. It should not affect the static > >size at all. Or am I

Re: [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI

On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote: > Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting > MSI interrupts from the older revision. > > Signed-off-by: Sinan Kaya > --- > Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13

Re: [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI

On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote: > Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting > MSI interrupts from the older revision. > > Signed-off-by: Sinan Kaya > --- > Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 - > 1

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

Em Fri, 23 Sep 2016 09:15:01 -0600 Jonathan Corbet escreveu: > On Fri, 23 Sep 2016 12:07:33 -0300 > Mauro Carvalho Chehab wrote: > > > including MAINTAINERS using ReST is tricky, because all > > maintainer's entries are like: > > So I'm generally in

[PATCH perf/core 4/4] perf-probe: Match linkage name with mangled name

Match linkage name with mangled name if exists. The linkage_name is used for storing mangled name of the object. Thus, this allows perf-probe to find appropriate probe point from mangled symbol as below. E.g. without this fix: $ ./perf probe -x /usr/lib64/libstdc++.so.6 \ -D

[PATCH perf/core 2/4] perf-probe: Skip if the function address is 0

Skip probes if the entry address of the target function is 0. This can happen if we handles c++ debuginfo. E.g. without this fix, below case still fail. $ ./perf probe -x /usr/lib64/libstdc++.so.6 -vD is_open probe-definition(0): is_open symbol:is_open file:(null) line:0 offset:0

[PATCH perf/core 0/4] perf-probe fixes for C++

Hi, Here is a series of patches for fixing several issues when probing on C++ binaries. - Ignore inlined function definition if it has no instance [1/4] - Skip (inlined/normal) functions which entry address is 0 [2/4] - Cut off the filename for group name if it includes characters which can

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

Em Fri, 23 Sep 2016 09:15:01 -0600 Jonathan Corbet escreveu: > On Fri, 23 Sep 2016 12:07:33 -0300 > Mauro Carvalho Chehab wrote: > > > including MAINTAINERS using ReST is tricky, because all > > maintainer's entries are like: > > So I'm generally in favor of moving things over to RST, but I

[PATCH perf/core 4/4] perf-probe: Match linkage name with mangled name

Match linkage name with mangled name if exists. The linkage_name is used for storing mangled name of the object. Thus, this allows perf-probe to find appropriate probe point from mangled symbol as below. E.g. without this fix: $ ./perf probe -x /usr/lib64/libstdc++.so.6 \ -D

[PATCH perf/core 2/4] perf-probe: Skip if the function address is 0

Skip probes if the entry address of the target function is 0. This can happen if we handles c++ debuginfo. E.g. without this fix, below case still fail. $ ./perf probe -x /usr/lib64/libstdc++.so.6 -vD is_open probe-definition(0): is_open symbol:is_open file:(null) line:0 offset:0

[PATCH perf/core 0/4] perf-probe fixes for C++

Hi, Here is a series of patches for fixing several issues when probing on C++ binaries. - Ignore inlined function definition if it has no instance [1/4] - Skip (inlined/normal) functions which entry address is 0 [2/4] - Cut off the filename for group name if it includes characters which can

[PATCH RT 3/8] scsi/fcoe: Fix get_cpu()/put_cpu_light() imbalance in fcoe_recv_frame()

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith During master->rt merge, I stumbled across the buglet below. Fix get_cpu()/put_cpu_light() imbalance. Cc: stable...@vger.kernel.org

[PATCH perf/core 3/4] perf-probe: Fix to cut off incompatible chars from group name

Cut off the characters which can not use for group name of uprobes when making it based on executable filename. For example, if the exec name is libstdc++.so, without this fix perf probe generates "probe_libstdc++" as the group name, but it is failed to set because '+' can not be used for group

[PATCH perf/core 1/4] perf-probe: Ignore the error of finding inline instance

Ignore the error when the perf probe failed to find inline function instances. This can happen when we search a method in c++ debuginfo. If there is completely no instance in target, perf probe can return an error. E.g. without this fix: $ ./perf probe -x /usr/lib64/libstdc++.so.6 -vD

[PATCH perf/core 3/4] perf-probe: Fix to cut off incompatible chars from group name

Cut off the characters which can not use for group name of uprobes when making it based on executable filename. For example, if the exec name is libstdc++.so, without this fix perf probe generates "probe_libstdc++" as the group name, but it is failed to set because '+' can not be used for group

[PATCH perf/core 1/4] perf-probe: Ignore the error of finding inline instance

Ignore the error when the perf probe failed to find inline function instances. This can happen when we search a method in c++ debuginfo. If there is completely no instance in target, perf probe can return an error. E.g. without this fix: $ ./perf probe -x /usr/lib64/libstdc++.so.6 -vD

[PATCH RT 3/8] scsi/fcoe: Fix get_cpu()/put_cpu_light() imbalance in fcoe_recv_frame()

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith During master->rt merge, I stumbled across the buglet below. Fix get_cpu()/put_cpu_light() imbalance. Cc: stable...@vger.kernel.org Signed-off-by: Mike Gabraith

[PATCH RT 1/8] timers: wakeup all timer waiters

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The base lock is dropped during the invocation if the timer. That means it is possible that we have one waiter while timer1 is

[PATCH RT 5/9] net: add back the missing serialization in ip_send_unicast_reply()

3.12.63-rt85-rc2 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Some time ago Sami Pietikainen reported a crash on -RT in ip_send_unicast_reply() which was later fixed by Nicholas Mc Guire

[PATCH RT 1/8] timers: wakeup all timer waiters

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The base lock is dropped during the invocation if the timer. That means it is possible that we have one waiter while timer1 is running and once this one

[PATCH RT 5/9] net: add back the missing serialization in ip_send_unicast_reply()

3.12.63-rt85-rc2 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Some time ago Sami Pietikainen reported a crash on -RT in ip_send_unicast_reply() which was later fixed by Nicholas Mc Guire (v3.12.8-rt11). Later

[PATCH RT 8/8] Linux 3.10.103-rt115-rc1

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (Red Hat)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[PATCH RT 4/8] net: add back the missing serialization in ip_send_unicast_reply()

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Some time ago Sami Pietikainen reported a crash on -RT in ip_send_unicast_reply() which was later fixed by Nicholas Mc Guire

[PATCH RT 7/9] fs/dcache: resched/chill only if we make no progress

3.12.63-rt85-rc2 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Upstream commit 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") changed the condition _when_ cpu_relax() / cond_resched()

[PATCH RT 0/9] Linux 3.12.63-rt85-rc2

Dear RT Folks, This is the RT stable review cycle of patch 3.12.63-rt85-rc2. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 6/8] fs/dcache: resched/chill only if we make no progress

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Upstream commit 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") changed the condition _when_ cpu_relax() /

[PATCH RT 7/8] fs/dcache: incremental fixup of the retry routine

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It has been pointed out by tglx that on UP the non-RT task could spin its entire time slice because the lock owner is preempted.

Re: [PATCH RT 0/9] Linux 3.12.63-rt85-rc2

On Fri, 23 Sep 2016 11:28:26 -0400 Steven Rostedt wrote: > Dear RT Folks, > > This is the RT stable review cycle of patch 3.12.63-rt85-rc2. Bah, it's suppose to be rc1. The patch has the change correct, even though its subject is wrong as well. -- Steve

[PATCH RT 5/8] net: add a lock around icmp_sk()

3.10.103-rt115-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It looks like the this_cpu_ptr() access in icmp_sk() is protected with local_bh_disable(). To avoid missing serialization in -RT I

[PATCH RT 0/8] Linux 3.10.103-rt115-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.10.103-rt115-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 2/9] timers: wakeup all timer waiters without holding the base lock

3.12.63-rt85-rc2 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior There should be no need to hold the base lock during the wakeup. There should be no boosting involved, the wakeup list has its own

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