Time stamp value in printk records

Hi All, From Qualcomm side, we would like to check with upstream team about adding Raw time stamp value to printk records. On Qualcomm soc, there are various DSPs subsystems are there - for example audio, video and modem DSPs. Adding raw timer value(along with sched_clock()) in the printk

Re: [PATCH] kernel/panic: Use SYSTEM_RESET2 command for warm reset

On 2019-05-16 11:29, Aaro Koskinen wrote: Hi, On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote: Some platforms may need warm reboot support when kernel crashed for post mortem analysis instead of cold reboot. So use config CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci

Re: PSCI version 1.1 and SYSTEM_RESET2

On 2019-05-02 02:05, Sudeep Holla wrote: On Wed, May 01, 2019 at 11:43:00AM -0700, Sodagudi Prasad wrote: On 2019-05-01 02:49, Sudeep Holla wrote: > On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote: > > On 2019-04-30 14:44, Sodagudi Prasad wrote: [...] > > &g

Re: PSCI version 1.1 and SYSTEM_RESET2

On 2019-05-01 02:49, Sudeep Holla wrote: On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote: On 2019-04-30 14:44, Sodagudi Prasad wrote: +Sudeep > Hi Mark/Will, > > I would like to understand whether ARM linux community have plans to > support PSCI version 1.1 or not

Re: PSCI version 1.1 and SYSTEM_RESET2

On 2019-04-30 14:44, Sodagudi Prasad wrote: +Sudeep Hi Mark/Will, I would like to understand whether ARM linux community have plans to support PSCI version 1.1 or not. PSCI_1_1 specification introduced support for SYSTEM_RESET2 command and this new command helps mobile devices

PSCI version 1.1 and SYSTEM_RESET2

Hi Mark/Will, I would like to understand whether ARM linux community have plans to support PSCI version 1.1 or not. PSCI_1_1 specification introduced support for SYSTEM_RESET2 command and this new command helps mobile devices to SYSTEM_WARM_RESET support. Rebooting devices with warm reboot

Re: [PATCH] genirq: call cancel_work_sync from irq_set_affinity_notifier

On 2019-03-21 09:19, Thomas Gleixner wrote: Prasad, On Wed, 20 Mar 2019, Prasad Sodagudi wrote: Subject: [PATCH] genirq: call cancel_work_sync from irq_set_affinity_notifier Please do not decribe WHAT the code change is. Give a consice explanation WHY this change is done. The above is like

Re: [PATCH] perf: Change PMCR write to read-modify-write

On 2019-03-21 06:34, Julien Thierry wrote: Hi Prasad, On 21/03/2019 02:07, Prasad Sodagudi wrote: Preserves the bitfields of PMCR_EL0(AArch64) during PMU reset. Reset routine should write a 1 to PMCR.C and PMCR.P fields only to reset the counters. Other fields should not be changed as they

Re: protected pins and debugfs

On 2018-10-10 12:40, Sodagudi Prasad wrote: On 2018-10-07 23:04, Stephen Boyd wrote: Quoting Sodagudi Prasad (2018-10-03 05:38:24) for (i = 0; i < chip->ngpio; i++, gpio++) { + label = gpiochip_is_requested(chip, i); + if (

Re: protected pins and debugfs

On 2018-10-10 12:40, Sodagudi Prasad wrote: On 2018-10-07 23:04, Stephen Boyd wrote: Quoting Sodagudi Prasad (2018-10-03 05:38:24) for (i = 0; i < chip->ngpio; i++, gpio++) { + label = gpiochip_is_requested(chip, i); + if (

Re: livelock with hrtimer cpu_base->lock

On 2018-10-10 09:49, Will Deacon wrote: Hi Prasad, On Tue, Oct 09, 2018 at 01:56:14PM -0700, Sodagudi Prasad wrote: This is regarding - thread "try to fix contention between expire_timers and try_to_del_timer_sync". https://lkml.org/lkml/2017/7/28/172 I think this live lo

Re: livelock with hrtimer cpu_base->lock

On 2018-10-10 09:49, Will Deacon wrote: Hi Prasad, On Tue, Oct 09, 2018 at 01:56:14PM -0700, Sodagudi Prasad wrote: This is regarding - thread "try to fix contention between expire_timers and try_to_del_timer_sync". https://lkml.org/lkml/2017/7/28/172 I think this live lo

Re: protected pins and debugfs

On 2018-10-07 23:04, Stephen Boyd wrote: Quoting Sodagudi Prasad (2018-10-03 05:38:24) for (i = 0; i < chip->ngpio; i++, gpio++) { + label = gpiochip_is_requested(chip, i); + if (!label) + co

Re: protected pins and debugfs

On 2018-10-07 23:04, Stephen Boyd wrote: Quoting Sodagudi Prasad (2018-10-03 05:38:24) for (i = 0; i < chip->ngpio; i++, gpio++) { + label = gpiochip_is_requested(chip, i); + if (!label) + co

livelock with hrtimer cpu_base->lock

Hi Will, This is regarding - thread "try to fix contention between expire_timers and try_to_del_timer_sync". https://lkml.org/lkml/2017/7/28/172 I think this live lockup issue was discussed earlier but the final set of changes were not concluded. I would like to check whether you have new

livelock with hrtimer cpu_base->lock

Hi Will, This is regarding - thread "try to fix contention between expire_timers and try_to_del_timer_sync". https://lkml.org/lkml/2017/7/28/172 I think this live lockup issue was discussed earlier but the final set of changes were not concluded. I would like to check whether you have new

protected pins and debugfs

Hi All, This is regarding the protected pins configuration reading and printing from non-secure operating systems. GPIO framework is checking whether pin is in use(flag FLAG_REQUESTED) or not in gpiolib_dbg_show(). If GPIO chip drivers are overriding the dbg_show callback, drivers are not

protected pins and debugfs

Hi All, This is regarding the protected pins configuration reading and printing from non-secure operating systems. GPIO framework is checking whether pin is in use(flag FLAG_REQUESTED) or not in gpiolib_dbg_show(). If GPIO chip drivers are overriding the dbg_show callback, drivers are not

EDAC polling

Hi All, While adding edac_device control info using edac_device_add_device(), changed the poll_msec at client driver level. For example -. https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/edac/qcom_llcc_edac.c?h=msm-4.9#n385 I see that client driver request is not

EDAC polling

Hi All, While adding edac_device control info using edac_device_add_device(), changed the poll_msec at client driver level. For example -. https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/edac/qcom_llcc_edac.c?h=msm-4.9#n385 I see that client driver request is not

KASAN errors from unwind_frame

Hi All, I have observed following KASAN error with 4.14.56 kernel. Can you please copy change-[1](kasan: add no_sanitize attribute for clang builds) into stable kernels? [1] -

KASAN errors from unwind_frame

Hi All, I have observed following KASAN error with 4.14.56 kernel. Can you please copy change-[1](kasan: add no_sanitize attribute for clang builds) into stable kernels? [1] -

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-08-10 00:10, Rafael J. Wysocki wrote: On Fri, Aug 10, 2018 at 12:30 AM, wrote: On 2018-08-06 01:53, Rafael J. Wysocki wrote: On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad wrote: From: RAFAEL J. WYSOCKI Date: Wed, Aug 1, 2018 at 2:21 PM Subject: Re: [PATCH] dd: Invoke one

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-08-10 00:10, Rafael J. Wysocki wrote: On Fri, Aug 10, 2018 at 12:30 AM, wrote: On 2018-08-06 01:53, Rafael J. Wysocki wrote: On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad wrote: From: RAFAEL J. WYSOCKI Date: Wed, Aug 1, 2018 at 2:21 PM Subject: Re: [PATCH] dd: Invoke one

Re: cpu stopper threads and setaffinity leads to deadlock

On 2018-08-03 04:41, Thomas Gleixner wrote: Prasad. On Thu, 2 Aug 2018, Peter Zijlstra wrote: So why didn't you do the 'obvious' parallel to what you did for cpu_stop_queue_two_works(), namely: Is that patch fixing the issue for you? Hi Thomas and Peter, Yes. Tested both versions of

Re: cpu stopper threads and setaffinity leads to deadlock

On 2018-08-03 04:41, Thomas Gleixner wrote: Prasad. On Thu, 2 Aug 2018, Peter Zijlstra wrote: So why didn't you do the 'obvious' parallel to what you did for cpu_stop_queue_two_works(), namely: Is that patch fixing the issue for you? Hi Thomas and Peter, Yes. Tested both versions of

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

From: RAFAEL J. WYSOCKI Date: Wed, Aug 1, 2018 at 2:21 PM Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level To: Rishabh Bhatnagar Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , Linux Kernel Mailing List , ckad...@codeaurora.org, ts...@codeaurora.org, Vikram

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

From: RAFAEL J. WYSOCKI Date: Wed, Aug 1, 2018 at 2:21 PM Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level To: Rishabh Bhatnagar Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , Linux Kernel Mailing List , ckad...@codeaurora.org, ts...@codeaurora.org, Vikram

Re: Remounting filesystem read-only

On 2018-07-28 00:47, Darrick J. Wong wrote: On Fri, Jul 27, 2018 at 08:18:23PM -0400, Theodore Y. Ts'o wrote: On Fri, Jul 27, 2018 at 01:34:31PM -0700, Sodagudi Prasad wrote: > > The error should be pretty clear: "Inode table for bg 0 marked as > > needing zeroing". Th

Re: Remounting filesystem read-only

On 2018-07-28 00:47, Darrick J. Wong wrote: On Fri, Jul 27, 2018 at 08:18:23PM -0400, Theodore Y. Ts'o wrote: On Fri, Jul 27, 2018 at 01:34:31PM -0700, Sodagudi Prasad wrote: > > The error should be pretty clear: "Inode table for bg 0 marked as > > needing zeroing". Th

cpu stopper threads and setaffinity leads to deadlock

Hi Peter and Tglx, We are observing another deadlock issue due to commit 0b26351b91(stop_machine, sched: Fix migrate_swap() vs. active_balance() deadlock), even after taking the following fix https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1740526.html on the Linux-4.14.56

cpu stopper threads and setaffinity leads to deadlock

Hi Peter and Tglx, We are observing another deadlock issue due to commit 0b26351b91(stop_machine, sched: Fix migrate_swap() vs. active_balance() deadlock), even after taking the following fix https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1740526.html on the Linux-4.14.56

Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads

On 2018-07-30 14:07, Peter Zijlstra wrote: On Mon, Jul 30, 2018 at 10:12:43AM -0700, Sodagudi Prasad wrote: How about including below change as well? Currently, there is no way to identify thread migrations completed or not. When we observe this issue, the symptom was work queue lock up

Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads

On 2018-07-30 14:07, Peter Zijlstra wrote: On Mon, Jul 30, 2018 at 10:12:43AM -0700, Sodagudi Prasad wrote: How about including below change as well? Currently, there is no way to identify thread migrations completed or not. When we observe this issue, the symptom was work queue lock up

Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads

On 2018-07-30 05:41, Thomas Gleixner wrote: On Mon, 30 Jul 2018, Peter Zijlstra wrote: On Mon, Jul 30, 2018 at 12:20:57PM +0200, Thomas Gleixner wrote: > On Tue, 24 Jul 2018, Sebastian Andrzej Siewior wrote: > > On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote: > > > Hi all, > > Hi,

Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads

On 2018-07-30 05:41, Thomas Gleixner wrote: On Mon, 30 Jul 2018, Peter Zijlstra wrote: On Mon, Jul 30, 2018 at 12:20:57PM +0200, Thomas Gleixner wrote: > On Tue, 24 Jul 2018, Sebastian Andrzej Siewior wrote: > > On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote: > > > Hi all, > > Hi,

Re: Remounting filesystem read-only

On 2018-07-27 12:52, Theodore Y. Ts'o wrote: On Fri, Jul 27, 2018 at 12:26:25PM -0700, Sodagudi Prasad wrote: On 2018-07-26 18:04, Sodagudi Prasad wrote: > Hi All, > +linux-kernel@vger.kernel.org list. Hi All, Observing the following issue with one of the partition on android

Re: Remounting filesystem read-only

On 2018-07-27 12:52, Theodore Y. Ts'o wrote: On Fri, Jul 27, 2018 at 12:26:25PM -0700, Sodagudi Prasad wrote: On 2018-07-26 18:04, Sodagudi Prasad wrote: > Hi All, > +linux-kernel@vger.kernel.org list. Hi All, Observing the following issue with one of the partition on android

Re: Remounting filesystem read-only

On 2018-07-26 18:04, Sodagudi Prasad wrote: Hi All, +linux-kernel@vger.kernel.org list. Hi All, Observing the following issue with one of the partition on android device with 4.14.56 kernel. When I try to remount this partition using the command - mount -o rw,remount /vendor/dsp

Re: Remounting filesystem read-only

On 2018-07-26 18:04, Sodagudi Prasad wrote: Hi All, +linux-kernel@vger.kernel.org list. Hi All, Observing the following issue with one of the partition on android device with 4.14.56 kernel. When I try to remount this partition using the command - mount -o rw,remount /vendor/dsp

Re: [PATCH] stop_machine: Remove cpu swap from stop_two_cpus

On 2018-06-27 00:15, Sebastian Andrzej Siewior wrote: On 2018-06-26 14:28:26 [-0700], Isaac J. Manjarres wrote: Remove CPU ID swapping in stop_two_cpus() so that the source CPU's stopper thread is added to the wake queue last, so that the source CPU's stopper thread is woken up last, ensuring

Re: [PATCH] stop_machine: Remove cpu swap from stop_two_cpus

On 2018-06-27 00:15, Sebastian Andrzej Siewior wrote: On 2018-06-26 14:28:26 [-0700], Isaac J. Manjarres wrote: Remove CPU ID swapping in stop_two_cpus() so that the source CPU's stopper thread is added to the wake queue last, so that the source CPU's stopper thread is woken up last, ensuring

Re: write_lock_irq(_lock)

On 2018-05-24 06:51, Boqun Feng wrote: On Thu, May 24, 2018 at 01:49:31PM +0100, Will Deacon wrote: On Wed, May 23, 2018 at 09:26:35AM -0700, Linus Torvalds wrote: > On Wed, May 23, 2018 at 8:35 AM Will Deacon wrote: > > > In other words, qrwlock requires consistent

Re: write_lock_irq(_lock)

On 2018-05-24 06:51, Boqun Feng wrote: On Thu, May 24, 2018 at 01:49:31PM +0100, Will Deacon wrote: On Wed, May 23, 2018 at 09:26:35AM -0700, Linus Torvalds wrote: > On Wed, May 23, 2018 at 8:35 AM Will Deacon wrote: > > > In other words, qrwlock requires consistent locking order wrt

write_lock_irq(_lock)

Hi All, When following test is executed on 4.14.41 stable kernel, observed that one of the core is waiting for tasklist_lock for long time with IRQs disabled. ./stress-ng-64 --get 8 -t 3h --times --metrics-brief Every time when device is crashed, I observed that one the task stuck at fork

write_lock_irq(_lock)

Hi All, When following test is executed on 4.14.41 stable kernel, observed that one of the core is waiting for tasklist_lock for long time with IRQs disabled. ./stress-ng-64 --get 8 -t 3h --times --metrics-brief Every time when device is crashed, I observed that one the task stuck at fork

bpf: mismatch between inode->i_private and inode->i_op

Hi All, Trying to boot 4.14.19 kernel with Android and observed a crash in bpf system. From the call stack netd process is trying to access the /sys/fs/bfp/traffic_cookie_uid_map file. After checking call stack further observed that, inode->i_private is pointing to (struct bpf_map *) but

bpf: mismatch between inode->i_private and inode->i_op

Hi All, Trying to boot 4.14.19 kernel with Android and observed a crash in bpf system. From the call stack netd process is trying to access the /sys/fs/bfp/traffic_cookie_uid_map file. After checking call stack further observed that, inode->i_private is pointing to (struct bpf_map *) but

Re: [PATCH] perf: Add support for creating offline events

On 2018-02-13 10:23, Peter Zijlstra wrote: On Fri, Feb 09, 2018 at 03:07:00PM -0800, Raghavendra Rao Ananta wrote: Perf framework doesn't allow creation of hardware events if the requested CPU is offline. However, creation of an event is achievable if the event is attached to the PMU as soon as

Re: [PATCH] perf: Add support for creating offline events

On 2018-02-13 10:23, Peter Zijlstra wrote: On Fri, Feb 09, 2018 at 03:07:00PM -0800, Raghavendra Rao Ananta wrote: Perf framework doesn't allow creation of hardware events if the requested CPU is offline. However, creation of an event is achievable if the event is attached to the PMU as soon as

Re: [PATCH] kbuild: clang: Disable -Wunused-const-variable warnings

On 2018-01-28 08:22, Segher Boessenkool wrote: On Fri, Jan 26, 2018 at 04:59:46PM -0800, Prasad Sodagudi wrote: Disable -Wunused-const-variable warnings instead of disabling -Wunused-variable warnings, So that in both clang and GCC -Wunused-const-variable gets disabled. Why would you disable

Re: [PATCH] kbuild: clang: Disable -Wunused-const-variable warnings

On 2018-01-28 08:22, Segher Boessenkool wrote: On Fri, Jan 26, 2018 at 04:59:46PM -0800, Prasad Sodagudi wrote: Disable -Wunused-const-variable warnings instead of disabling -Wunused-variable warnings, So that in both clang and GCC -Wunused-const-variable gets disabled. Why would you disable

Re: unused-variable warning is getting disabled with clang

On 2017-12-06 22:26, Greg Kroah-Hartman wrote: On Wed, Dec 06, 2017 at 01:24:51PM -0800, Sodagudi Prasad wrote: Hi All, When kernel compiled with clang, following line is disabling the unused-variable warning. This is not the case with gcc. KBUILD_CFLAGS += $(call cc-disable-warning, unused

Re: unused-variable warning is getting disabled with clang

On 2017-12-06 22:26, Greg Kroah-Hartman wrote: On Wed, Dec 06, 2017 at 01:24:51PM -0800, Sodagudi Prasad wrote: Hi All, When kernel compiled with clang, following line is disabling the unused-variable warning. This is not the case with gcc. KBUILD_CFLAGS += $(call cc-disable-warning, unused

unused-variable warning is getting disabled with clang

Hi All, When kernel compiled with clang, following line is disabling the unused-variable warning. This is not the case with gcc. KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable) Are there any specific reasons for disabling unused-variable with clang? -- The Qualcomm Innovation

unused-variable warning is getting disabled with clang

Hi All, When kernel compiled with clang, following line is disabling the unused-variable warning. This is not the case with gcc. KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable) Are there any specific reasons for disabling unused-variable with clang? -- The Qualcomm Innovation

Re: [PATCH] Clockevents: Always call clockevents_program_event

On 2017-10-24 01:37, Thomas Gleixner wrote: On Tue, 24 Oct 2017, Prasad Sodagudi wrote: Currently tick_program_event function is not calling clockevents_program_event when 'expires == KTIME_MAX', it is just updating clockevent state to CLOCK_EVT_STATE_ONESHOT_STOPPED.

Re: [PATCH] Clockevents: Always call clockevents_program_event

On 2017-10-24 01:37, Thomas Gleixner wrote: On Tue, 24 Oct 2017, Prasad Sodagudi wrote: Currently tick_program_event function is not calling clockevents_program_event when 'expires == KTIME_MAX', it is just updating clockevent state to CLOCK_EVT_STATE_ONESHOT_STOPPED.

Re: clock event device’s next_event

On 2017-10-24 00:23, Thomas Gleixner wrote: On Mon, 23 Oct 2017, Sodagudi Prasad wrote: Hi Viresh and Thomas, In the functions tick_nohz_stop_sched_tick(), when expires = KTIME_MAX we are canceling the tick_sched_timer timer but we are not updating the clock event device’s next_event

Re: clock event device’s next_event

On 2017-10-24 00:23, Thomas Gleixner wrote: On Mon, 23 Oct 2017, Sodagudi Prasad wrote: Hi Viresh and Thomas, In the functions tick_nohz_stop_sched_tick(), when expires = KTIME_MAX we are canceling the tick_sched_timer timer but we are not updating the clock event device’s next_event

clock event device’s next_event

Hi Viresh and Thomas, In the functions tick_nohz_stop_sched_tick(), when expires = KTIME_MAX we are canceling the tick_sched_timer timer but we are not updating the clock event device’s next_event to KTIME_MAX. Due to that broadcast device’s next_event is not programmed properly and resulting

clock event device’s next_event

Hi Viresh and Thomas, In the functions tick_nohz_stop_sched_tick(), when expires = KTIME_MAX we are canceling the tick_sched_timer timer but we are not updating the clock event device’s next_event to KTIME_MAX. Due to that broadcast device’s next_event is not programmed properly and resulting

__ubsan_handle_type_mismatch converted to __ubsan_handle_type_mismatch_v1

Hi All, Based on below links __ubsan_handle_type_mismatch has been renamed to __ubsan_handle_type_mismatch_v1. https://github.com/llvm-mirror/compiler-rt/commit/56faee71af1888ba12ab076b3d1f9bbe223493df#diff-21369cc6f3917b27df3ced8de89cf134

__ubsan_handle_type_mismatch converted to __ubsan_handle_type_mismatch_v1

Hi All, Based on below links __ubsan_handle_type_mismatch has been renamed to __ubsan_handle_type_mismatch_v1. https://github.com/llvm-mirror/compiler-rt/commit/56faee71af1888ba12ab076b3d1f9bbe223493df#diff-21369cc6f3917b27df3ced8de89cf134

Re: [PATCH] arch_topology: Fix section miss match warning due to free_raw_capacity()

On 2017-09-25 16:20, Viresh Kumar wrote: On 25-09-17, 15:51, Prasad Sodagudi wrote: Remove the __init annotation from free_raw_capacity() to avoid the following warning. The function init_cpu_capacity_callback() references the function __init free_raw_capacity(). WARNING:

Re: [PATCH] arch_topology: Fix section miss match warning due to free_raw_capacity()

On 2017-09-25 16:20, Viresh Kumar wrote: On 25-09-17, 15:51, Prasad Sodagudi wrote: Remove the __init annotation from free_raw_capacity() to avoid the following warning. The function init_cpu_capacity_callback() references the function __init free_raw_capacity(). WARNING:

variable length array in structure

Hi Arnd Bergmann, Following commit have introduced compilation issue. commit 2df2c3402fc81918a888e1ec711369f6014471f2 Author: Arnd Bergmann Date: Sat Aug 5 21:57:46 2017 -0400 ext4: fix warning about stack corruption Observed following error - /fs/ext4/mballoc.c:2303:17:

variable length array in structure

Hi Arnd Bergmann, Following commit have introduced compilation issue. commit 2df2c3402fc81918a888e1ec711369f6014471f2 Author: Arnd Bergmann Date: Sat Aug 5 21:57:46 2017 -0400 ext4: fix warning about stack corruption Observed following error - /fs/ext4/mballoc.c:2303:17: error: fields

Re: [PATCH] llist: clang: introduce member_address_is_nonnull()

Hi All, Observed boot up crash with clang in kerne/sched/core.c file sched_ttwu_pending() function, because it is using llist_for_each_entry_safe(). After pulling patch from “https://lkml.org/lkml/2017/7/19/1169, no crash observed. Tested-by: Sodagudi Prasad <psoda...@codeaurora.

Re: [PATCH] llist: clang: introduce member_address_is_nonnull()

Hi All, Observed boot up crash with clang in kerne/sched/core.c file sched_ttwu_pending() function, because it is using llist_for_each_entry_safe(). After pulling patch from “https://lkml.org/lkml/2017/7/19/1169, no crash observed. Tested-by: Sodagudi Prasad -Thanks, Prasad

Re: [patch resend 4.12] compiler, clang: always inline when CONFIG_OPTIMIZE_INLINING is disabled

d inlining behavior and work toward moving arm64, and other architectures, toward CONFIG_OPTIMIZE_INLINING behavior. Reported-by: Sodagudi Prasad <psoda...@codeaurora.org> Tested-by: Matthias Kaehlcke <m...@chromium.org> Signed-off-by: David Rientjes <rient...@google.com> --- Resend

Re: [patch resend 4.12] compiler, clang: always inline when CONFIG_OPTIMIZE_INLINING is disabled

d inlining behavior and work toward moving arm64, and other architectures, toward CONFIG_OPTIMIZE_INLINING behavior. Reported-by: Sodagudi Prasad Tested-by: Matthias Kaehlcke Signed-off-by: David Rientjes --- Resend of http://marc.info/?l=linux-kernel=149681501816319 for 4.12 inclusion. Prasad,

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-22 02:43, Mark Rutland wrote: On Tue, Jun 20, 2017 at 04:12:32PM -0700, David Rientjes wrote: On Tue, 20 Jun 2017, Mark Rutland wrote: > As with my reply to David, my preference would be that we: > > 1) Align compiler-clang.h with the compiler-gcc.h inlining behaviour, so >that

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-22 02:43, Mark Rutland wrote: On Tue, Jun 20, 2017 at 04:12:32PM -0700, David Rientjes wrote: On Tue, 20 Jun 2017, Mark Rutland wrote: > As with my reply to David, my preference would be that we: > > 1) Align compiler-clang.h with the compiler-gcc.h inlining behaviour, so >that

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-19 14:42, David Rientjes wrote: On Mon, 19 Jun 2017, Sodagudi Prasad wrote: > > Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused > > static inline functions") re-defining the 'inline' macro but > > __attribute__((always_inline)) is

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-19 14:42, David Rientjes wrote: On Mon, 19 Jun 2017, Sodagudi Prasad wrote: > > Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused > > static inline functions") re-defining the 'inline' macro but > > __attribute__((always_inline)) is

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-19 13:25, David Rientjes wrote: On Mon, 19 Jun 2017, Prasad Sodagudi wrote: Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused static inline functions") re-defining the 'inline' macro but __attribute__((always_inline)) is missing. Some compilers may not honor inline

Re: [PATCH] compiler, clang: Add always_inline attribute to inline

On 2017-06-19 13:25, David Rientjes wrote: On Mon, 19 Jun 2017, Prasad Sodagudi wrote: Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused static inline functions") re-defining the 'inline' macro but __attribute__((always_inline)) is missing. Some compilers may not honor inline

Re: Using __always_inline attribute

On 2017-06-14 15:33, Sodagudi Prasad wrote: On 2017-06-14 03:06, Will Deacon wrote: Hi Prasad, On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote: With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. How are you building the kernel

Re: Using __always_inline attribute

On 2017-06-14 15:33, Sodagudi Prasad wrote: On 2017-06-14 03:06, Will Deacon wrote: Hi Prasad, On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote: With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. How are you building the kernel

Re: Using __always_inline attribute

On 2017-06-14 03:06, Will Deacon wrote: Hi Prasad, On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote: With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. How are you building the kernel with clang, btw? I'd be keen to try the same thing

Re: Using __always_inline attribute

On 2017-06-14 03:06, Will Deacon wrote: Hi Prasad, On Tue, Jun 13, 2017 at 03:39:37PM -0700, Sodagudi Prasad wrote: With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. How are you building the kernel with clang, btw? I'd be keen to try the same thing

Using __always_inline attribute

Hi All, With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. net/built-in.o: In function `__xchg_mb': arch/arm64/include/asm/cmpxchg.h:99: \ undefined reference to `__compiletime_assert_99' arch/arm64/include/asm/cmpxchg.h:99: \

Using __always_inline attribute

Hi All, With a variant of a CLANG(based on 4.0) following errors observed on Linux 4.12-rc5 tag. net/built-in.o: In function `__xchg_mb': arch/arm64/include/asm/cmpxchg.h:99: \ undefined reference to `__compiletime_assert_99' arch/arm64/include/asm/cmpxchg.h:99: \

deadlock due to circular dependency between threads

Hi all, I am working on a platform, which is using the Linux version 4.4. I have observed a DEADLOCK between couple of threads and looking for suggestions/comments. Here is my understanding from the call stacks of these blocked tasks. 0) CPU3 is getting hot plugged from a kthread and which

deadlock due to circular dependency between threads

Hi all, I am working on a platform, which is using the Linux version 4.4. I have observed a DEADLOCK between couple of threads and looking for suggestions/comments. Here is my understanding from the call stacks of these blocked tasks. 0) CPU3 is getting hot plugged from a kthread and which

gic_write_grpen1 in hotplug flow

Hi All, This is regarding the usage of gic_write_grpen1 API usage in irq-gic-v3 driver. Here my understanding about ICC_IGRPEN1_EL1. ICC_IGRPEN1_EL1 is banked between secure and non-secure states. If two secure states are implemented, Secure side Group bit is set by the platform firmware

gic_write_grpen1 in hotplug flow

Hi All, This is regarding the usage of gic_write_grpen1 API usage in irq-gic-v3 driver. Here my understanding about ICC_IGRPEN1_EL1. ICC_IGRPEN1_EL1 is banked between secure and non-secure states. If two secure states are implemented, Secure side Group bit is set by the platform firmware

Re: Schedule affinity_notify work while migrating IRQs during hot plug

On 2017-03-13 13:19, Thomas Gleixner wrote: On Mon, 13 Mar 2017, Sodagudi Prasad wrote: On 2017-02-27 09:21, Thomas Gleixner wrote: > On Mon, 27 Feb 2017, Sodagudi Prasad wrote: > > So I am thinking that, adding following sched_work() would notify clients. > > And break the worl

Re: Schedule affinity_notify work while migrating IRQs during hot plug

On 2017-03-13 13:19, Thomas Gleixner wrote: On Mon, 13 Mar 2017, Sodagudi Prasad wrote: On 2017-02-27 09:21, Thomas Gleixner wrote: > On Mon, 27 Feb 2017, Sodagudi Prasad wrote: > > So I am thinking that, adding following sched_work() would notify clients. > > And break the worl

Re: Schedule affinity_notify work while migrating IRQs during hot plug

On 2017-02-27 09:21, Thomas Gleixner wrote: On Mon, 27 Feb 2017, Sodagudi Prasad wrote: So I am thinking that, adding following sched_work() would notify clients. And break the world and some more. diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 6b66959..5e4766b 100644

Re: Schedule affinity_notify work while migrating IRQs during hot plug

On 2017-02-27 09:21, Thomas Gleixner wrote: On Mon, 27 Feb 2017, Sodagudi Prasad wrote: So I am thinking that, adding following sched_work() would notify clients. And break the world and some more. diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 6b66959..5e4766b 100644

opaque types instead of union epoll_data

Hi All, uapi structs epoll_data are more opaque than user space expects. kernel have defined as __u64 instead of the union epoll_data. Because of this libc have redefined struct epoll_event with union data member.

opaque types instead of union epoll_data

Hi All, uapi structs epoll_data are more opaque than user space expects. kernel have defined as __u64 instead of the union epoll_data. Because of this libc have redefined struct epoll_event with union data member.

Re: Schedule affinity_notify work while migrating IRQs during hot plug

On 2017-02-21 12:59, Sodagudi Prasad wrote: Hi Thomas, Currently irq_set_affinity() is called to migrate irqs from migrate_one_irq() during cpu hot plug and clients which are interested to know the irq affinity change not getting notified take_cpu_down () --> __cpu_disa

Re: Schedule affinity_notify work while migrating IRQs during hot plug

On 2017-02-21 12:59, Sodagudi Prasad wrote: Hi Thomas, Currently irq_set_affinity() is called to migrate irqs from migrate_one_irq() during cpu hot plug and clients which are interested to know the irq affinity change not getting notified take_cpu_down () --> __cpu_disa

Re: Free after use in fw_pm_notify()->kill_requests_without_uevent() due pending_fw_head

On 2017-01-03 07:19, Greg KH wrote: On Tue, Jan 03, 2017 at 06:44:03AM -0800, Sodagudi Prasad wrote: Hi All, Device has crashed due to memory access after free while pending_fw_head list accessed. Kernel 4.4 stable version is used to reproduce this use after free

Re: Free after use in fw_pm_notify()->kill_requests_without_uevent() due pending_fw_head

On 2017-01-03 07:19, Greg KH wrote: On Tue, Jan 03, 2017 at 06:44:03AM -0800, Sodagudi Prasad wrote: Hi All, Device has crashed due to memory access after free while pending_fw_head list accessed. Kernel 4.4 stable version is used to reproduce this use after free

Schedule affinity_notify work while migrating IRQs during hot plug

Hi Thomas, Currently irq_set_affinity() is called to migrate irqs from migrate_one_irq() during cpu hot plug and clients which are interested to know the irq affinity change not getting notified take_cpu_down () --> __cpu_disable() --> irq_migrate_all_off_this_cpu(); irq_set_affinity() is

Schedule affinity_notify work while migrating IRQs during hot plug

Hi Thomas, Currently irq_set_affinity() is called to migrate irqs from migrate_one_irq() during cpu hot plug and clients which are interested to know the irq affinity change not getting notified take_cpu_down () --> __cpu_disable() --> irq_migrate_all_off_this_cpu(); irq_set_affinity() is

  1   2   >