Re: [RFC][PATCH 1/8] epoll: remove epmutex from ep_free() & eventpoll_release_file()
Hi, On 2017/10/28 21:58, Davidlohr Bueso wrote: > On Sat, 28 Oct 2017, Hou Tao wrote: > >> Remove the global epmutex from ep_free() and eventpoll_release_file(). >> In the later patches, we will add locks with a smaller granularity >> to serve the same purposes of epmutex. >> >> Signed-off-by: Hou Tao >> --- >> fs/eventpoll.c | 4 >> 1 file changed, 4 deletions(-) >> >> diff --git a/fs/eventpoll.c b/fs/eventpoll.c >> index 2fabd19..26ab0c5 100644 >> --- a/fs/eventpoll.c >> +++ b/fs/eventpoll.c >> @@ -835,7 +835,6 @@ static void ep_free(struct eventpoll *ep) >> * anymore. The only hit might come from eventpoll_release_file() but >> * holding "epmutex" is sufficient here. >> */ > ^^ > What about this comment (and the equivalent one in eventpoll_release_file()? > >> -mutex_lock(&epmutex); > Thanks for your reminder. I will fix the related comments in a v1 patchset. > ...even if you fix it in a later patch, this patch breaks bisection. Now > we just race between ep_free() and eventpoll_release_file(). This patch > should be folded in, no? Yes, the patchset should be squashed into one patch, however it will be difficult to explain the purpose of these modifications, so I break them into little pieces, and hoped that these little patches can explain the reason why the modification is needed in a cleaner way. It also will be fixed in v1 patch. Regards, Tao > Thanks, > Davidlohr > > . >
[PATCH] PM / QoS: Fix default runtime_pm device resume latency
The recent change to the PM QoS framework to introduce a proper
no constraint value overlooked to handle the devices which don't
implement PM QoS OPS. Runtime PM is one of the more severely
impacted subsystems, failing every attempt to runtime suspend
a device. This leads into some nasty second level issues like
probe failures and increased power consumption among other things.
Fix this by adding a proper return value for devices that don't
implement PM QoS implicitly.
Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
Signed-off-by: Tero Kristo
Cc: Rafael J. Wysocki
---
include/linux/pm_qos.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 6737a8c..d68b056 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -175,7 +175,8 @@ static inline s32 dev_pm_qos_requested_flags(struct device
*dev)
static inline s32 dev_pm_qos_raw_read_value(struct device *dev)
{
return IS_ERR_OR_NULL(dev->power.qos) ?
- 0 : pm_qos_read_value(&dev->power.qos->resume_latency);
+ PM_QOS_RESUME_LATENCY_NO_CONSTRAINT :
+ pm_qos_read_value(&dev->power.qos->resume_latency);
}
#else
static inline enum pm_qos_flags_status __dev_pm_qos_flags(struct device *dev,
--
1.9.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] sound: fix kernel-doc build warning
On Mon, 30 Oct 2017 01:08:52 +0100,
Randy Dunlap wrote:
>
> From: Randy Dunlap
>
> Fix kernel-doc build error. A symbol that ends with an underscore
> character ('_') has special meaning in reST (reStructuredText), so add
> a '*' to prevent this error and to indicate that there are several of
> these values to choose from.
>
> ../sound/core/jack.c:312: ERROR: Unknown target name: "snd_jack_btn".
>
> Signed-off-by: Randy Dunlap
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: alsa-de...@alsa-project.org
Thanks, applied.
I vaguely remember that we had this because the asterisk caused an
error with the old kerneldoc before ReST.
Takashi
Re: [lkp-robot] [android/ion] 5fb70554d6: kernel_selftests.android.make_fail
On Sun, Oct 29, 2017 at 7:51 PM, kernel test robot
wrote:
>
> FYI, we noticed the following commit (built with gcc-6):
>
> commit: 5fb70554d68e2ea032b6a28b082801d8b7b76cb8 ("android/ion: userspace
> test utility for ion buffer sharing")
> url:
> https://github.com/0day-ci/linux/commits/Pintu-Agarwal/android-ion-userspace-test-utility-for-ion-buffer-sharing/20171025-022548
>
>
> in testcase: kernel_selftests
> with following parameters:
>
>
> test-description: The kernel contains a set of "self tests" under the
> tools/testing/selftests/ directory. These are intended to be small unit tests
> to exercise individual code paths in the kernel.
> test-url: https://www.kernel.org/doc/Documentation/kselftest.txt
>
>
> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with
> 64G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
>
>
> KERNEL SELFTESTS: linux_headers_dir is
> /usr/src/linux-headers-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8
> 2017-10-26 22:18:16 ln -sf /usr/bin/gcc-5 /usr/bin/gcc
>
> 2017-10-26 22:18:16 make run_tests -C android
> make: Entering directory
> '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/android'
> make[1]: Entering directory
> '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/android/ion'
> gcc -I../../../../../drivers/staging/android/uapi/ -Wall -O2 -g
> ionapp_export.c ipcsocket.c ionutils.c -o ionapp_export
> In file included from ionapp_export.c:28:0:
> ionutils.h:4:17: fatal error: ion.h: No such file or directory
> compilation terminated.
> In file included from ionutils.c:9:0:
> ionutils.h:4:17: fatal error: ion.h: No such file or directory
> compilation terminated.
This utility requires ion.h header file which should be included from
kernel source tree: drivers/staging/android/ion/uapi/
This is already mentioned in the ion/Makefile
Looks like this ion.h is not getting included inside the linux_headers_dir ?
Shall I include the ion.h locally in my selftests?
Or, is there a better way to include the header directly...
> : recipe for target 'ionapp_export' failed
> make[1]: *** [ionapp_export] Error 1
> make[1]: Leaving directory
> '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/android/ion'
> ion_test.sh: No /dev/ion device found
> ion_test.sh: May be CONFIG_ION is not set
> make: Leaving directory
> '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/android'
>
> 2017-10-26 22:18:16 make run_tests -C bpf
> make: Entering directory
> '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/bpf'
> make -C ../../../lib/bpf
> OUTPUT=/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/bpf/
> make[1]: Entering directory
> '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/lib/bpf'
>
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
>
>
> Thanks,
> Xiaolong
[mainline][ppc] sysfs: cannot create duplicate filename '/devices/hv_24x7/events/PM_CAPP1_APC_UOP_SEND_PB_CMD'
Hi, A warning is being triggered while booting mainline kernel on ppc machine. Machine Type: Power 9 Kernel : 4.14.0-rc6 gcc: 4.8.5 Test : Boot Boot logs: -- hv-24x7: found a duplicate event PM_CAPP1_XPT_MSG_SENT_GT_16_LE_64, ct=1 hv-24x7: found a duplicate event PM_CAPP1_XPT_MSG_SENT_TSIZE_GT_64_LE_128, ct=1 hv-24x7: read 1463 catalog entries, created 470 event attrs (0 failures), 253 descs audit: initializing netlink subsys (disabled) audit: type=2000 audit(1509236850.410:1): state=initialized audit_enabled=0 res=1 Kprobe smoke test: started Kprobe smoke test: passed successfully sysfs: cannot create duplicate filename '/devices/hv_24x7/events/PM_CAPP1_APC_UOP_SEND_PB_CMD' [ cut here ] WARNING: CPU: 1 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x80/0xb0 Modules linked in: CPU: 1 PID: 1 Comm: swapper/1 Not tainted 4.14.0-rc6-autotest-autotest #1 task: c000fe9c task.stack: c000fea0 NIP: c03f89c0 LR: c03f89bc CTR: 0073c874 REGS: c000fea03610 TRAP: 0700 Not tainted (4.14.0-rc6-autotest-autotest) MSR: 82029033 CR: 22022022 XER: 000f CFAR: c01692e8 SOFTE: 1 GPR00: c03f89bc c000fea03890 c10c5900 005e GPR04: 0080 000181207e2b5b77 00a2 GPR08: c103d410 c103d410 GPR12: 2000 cfac0a80 c000d168 GPR16: GPR20: GPR24: ee4b c000f0e0d590 c000f0df1c10 GPR28: c0f77090 c000f0e0d590 c000fe039c80 c000fe184000 NIP [c03f89c0] sysfs_warn_dup+0x80/0xb0 LR [c03f89bc] sysfs_warn_dup+0x7c/0xb0 Call Trace: [c000fea03890] [c03f89bc] sysfs_warn_dup+0x7c/0xb0 (unreliable) [c000fea03910] [c03f85b8] sysfs_add_file_mode_ns+0x1f8/0x210 [c000fea03990] [c03f998c] internal_create_group+0x12c/0x3a0 [c000fea03a30] [c03f9e10] sysfs_create_groups+0x70/0x120 [c000fea03a70] [c05fcaa0] device_add+0x3f0/0x760 [c000fea03b30] [c0246c48] pmu_dev_alloc+0xb8/0x140 [c000fea03bb0] [c0c9380c] perf_event_sysfs_init+0x90/0xf4 [c000fea03c40] [c000cf00] do_one_initcall+0x60/0x1c0 [c000fea03d00] [c0c6441c] kernel_init_freeable+0x278/0x358 [c000fea03dc0] [c000d184] kernel_init+0x24/0x140 [c000fea03e30] [c000b4e8] ret_from_kernel_thread+0x5c/0x74 Instruction dump: 7fa3eb78 3880 7fe5fb78 38c01000 4bffa529 6000 3c62ffad 7fe4fb78 38630e38 7fc5f378 4bd708f1 6000 <0fe0> 7fe3fb78 4bf0b1e1 6000 ---[ end trace 537ba3bf9fbd1b58 ]--- Failed to register pmu: hv_24x7, reason -17 [ cut here ] WARNING: CPU: 1 PID: 1 at kernel/events/core.c:11238 perf_event_sysfs_init+0xa8/0xf4 Modules linked in: CPU: 1 PID: 1 Comm: swapper/1 Tainted: GW 4.14.0-rc6-autotest-autotest #1 task: c000fe9c task.stack: c000fea0 NIP: c0c93824 LR: c0c93820 CTR: 0073c874 REGS: c000fea03930 TRAP: 0700 Tainted: GW (4.14.0-rc6-autotest-autotest) MSR: 82029033 CR: 2222 XER: 000c CFAR: c01692e8 SOFTE: 1 GPR00: c0c93820 c000fea03bb0 c10c5900 002b GPR04: 0080 000181207e2ff5a3 00a3 GPR08: c103d410 c103d410 GPR12: cfac0a80 c000d168 GPR16: GPR20: GPR24: c0c637ac c0c4d280 c0b83e00 GPR28: c0f8f8c8 c0f8f8e8 c0f77108 NIP [c0c93824] perf_event_sysfs_init+0xa8/0xf4 LR [c0c93820] perf_event_sysfs_init+0xa4/0xf4 Call Trace: [c000fea03bb0] [c0c93820] perf_event_sysfs_init+0xa4/0xf4 (unreliable) [c000fea03c40] [c000cf00] do_one_initcall+0x60/0x1c0 [c000fea03d00] [c0c6441c] kernel_init_freeable+0x278/0x358 [c000fea03dc0] [c000d184] kernel_init+0x24/0x140 [c000fea03e30] [c000b4e8] ret_from_kernel_thread+0x5c/0x74 Instruction dump: 2fa9 419e0030 813f0030 2f89 419c0024 4b5b3391 7c651b79 41e20018 e89f0028 7f63db78 4b4d5a8d 6000 <0fe0> ebff 4bb8 3921 ---[ end trace 537ba3bf9fbd1b59 ]--- Initialise system trusted keyrings A similar issue was reported on 4.11.0 https://lkml.org/lkml/2017/3/7/763 -- Regard's Abdul Haleem IBM Linux Technology Centre
[PATCH v2] cgroup/cpuset: remove circular dependency deadlock
Remove circular dependency deadlock in a scenario where hotplug of CPU is
being done while there is updation in cgroup and cpuset triggered from
userspace.
Process A => kthreadd => Process B => Process C => Process A
Process A
cpu_subsys_offline();
cpu_down();
_cpu_down();
percpu_down_write(&cpu_hotplug_lock); //held
cpuhp_invoke_callback();
workqueue_offline_cpu();
queue_work_on(); // unbind_work on system_highpri_wq
__queue_work();
insert_work();
wake_up_worker();
flush_work();
wait_for_completion();
worker_thread();
manage_workers();
create_worker();
kthread_create_on_node();
wake_up_process(kthreadd_task);
kthreadd
kthreadd();
kernel_thread();
do_fork();
copy_process();
percpu_down_read(&cgroup_threadgroup_rwsem);
__rwsem_down_read_failed_common(); //waiting
Process B
kernfs_fop_write();
cgroup_file_write();
cgroup_procs_write();
percpu_down_write(&cgroup_threadgroup_rwsem); //held
cgroup_attach_task();
cgroup_migrate();
cgroup_migrate_execute();
cpuset_can_attach();
mutex_lock(&cpuset_mutex); //waiting
Process C
kernfs_fop_write();
cgroup_file_write();
cpuset_write_resmask();
mutex_lock(&cpuset_mutex); //held
update_cpumask();
update_cpumasks_hier();
rebuild_sched_domains_locked();
get_online_cpus();
percpu_down_read(&cpu_hotplug_lock); //waiting
Eliminating deadlock by reversing the locking order for cpuset_mutex and
cpu_hotplug_lock. After inverting the locking sequence of cpu_hotplug_lock
and cpuset_mutex, cpuset_hotplug_workfn() related functionality can be
done synchronously from the context doing cpu hotplug. For memory hotplug
it still gets queued as a work item.
Signed-off-by: Prateek Sood
---
include/linux/cpuset.h | 6
kernel/cgroup/cpuset.c | 94 +++---
kernel/power/process.c | 2 --
kernel/sched/core.c| 1 -
4 files changed, 50 insertions(+), 53 deletions(-)
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index a1e6a33..e74655d 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -51,9 +51,7 @@ static inline void cpuset_dec(void)
extern int cpuset_init(void);
extern void cpuset_init_smp(void);
-extern void cpuset_force_rebuild(void);
extern void cpuset_update_active_cpus(void);
-extern void cpuset_wait_for_hotplug(void);
extern void cpuset_cpus_allowed(struct task_struct *p, struct cpumask *mask);
extern void cpuset_cpus_allowed_fallback(struct task_struct *p);
extern nodemask_t cpuset_mems_allowed(struct task_struct *p);
@@ -166,15 +164,11 @@ static inline void set_mems_allowed(nodemask_t nodemask)
static inline int cpuset_init(void) { return 0; }
static inline void cpuset_init_smp(void) {}
-static inline void cpuset_force_rebuild(void) { }
-
static inline void cpuset_update_active_cpus(void)
{
partition_sched_domains(1, NULL, NULL);
}
-static inline void cpuset_wait_for_hotplug(void) { }
-
static inline void cpuset_cpus_allowed(struct task_struct *p,
struct cpumask *mask)
{
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 4657e29..ec44aaa 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -817,6 +817,18 @@ static int generate_sched_domains(cpumask_var_t **domains,
return ndoms;
}
+static void cpuset_sched_change_begin(void)
+{
+ cpus_read_lock();
+ mutex_lock(&cpuset_mutex);
+}
+
+static void cpuset_sched_change_end(void)
+{
+ mutex_unlock(&cpuset_mutex);
+ cpus_read_unlock();
+}
+
/*
* Rebuild scheduler domains.
*
@@ -826,16 +838,14 @@ static int generate_sched_domains(cpumask_var_t **domains,
* 'cpus' is removed, then call this routine to rebuild the
* scheduler's dynamic sched domains.
*
- * Call with cpuset_mutex held. Takes get_online_cpus().
*/
-static void rebuild_sched_domains_locked(void)
+static void rebuild_sched_domains_cpuslocked(void)
{
struct sched_domain_attr *attr;
cpumask_var_t *doms;
int ndoms;
lockdep_assert_held(&cpuset_mutex);
- get_online_cpus();
/*
* We have raced with CPU hotplug. Don't do anything to avoid
@@ -843,27 +853,25 @@ static void rebuild_sched_domains_locked(void)
* Anyways, hotplug work item will rebuild sched domains.
*/
if (!cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask))
- goto out;
+ return;
/* Generate domain masks and attrs */
ndoms = generate_sched_domains(&doms, &attr);
/* Have scheduler rebuild the domains */
partition_sched_domains(ndoms, doms, attr);
-out:
- put_online_cpus();
}
#else /* !CONFIG_SMP */
-static void rebuild
Re: [lkp-robot] [locking/lockdep] 2dcd5adfb7: WARNING:possible_circular_locking_dependency_detected
On Sun, Oct 29, 2017 at 10:18:55PM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-5):
>
> commit: 2dcd5adfb7401b762ddbe4b86dcacc2f3de6b97b ("locking/lockdep: Remove
> the BROKEN flag from CONFIG_LOCKDEP_CROSSRELEASE and
> CONFIG_LOCKDEP_COMPLETIONS")
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git locking/core
>
> in testcase: boot
>
> on test machine: qemu-system-i386 -enable-kvm -m 256M
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
> +---+++
> | | d141babe42 |
> 2dcd5adfb7 |
> +---+++
> | boot_successes| 20 | 0
> |
> | boot_failures | 0 | 20
> |
> | WARNING:possible_circular_locking_dependency_detected | 0 | 20
> |
> | BUG:kernel_hang_in_test_stage | 0 | 16
> |
> +---+++
>
> [4.442653] WARNING: possible circular locking dependency detected
> [4.443206] 4.14.0-rc6-00050-g2dcd5ad #1 Not tainted
> [4.443648] --
> [4.444200] kworker/0:1/15 is trying to acquire lock:
> [4.444661] (ww_class_mutex){+.+.}, at: []
> test_abba_work+0x3b/0x167
> [4.445354]
> [4.445354] but now in release context of a crosslock acquired at the
> following:
> [4.446160] ((completion)&abba.b_ready){+.+.}, at: []
> wait_for_common+0x1b/0x2b
> [4.446899]
> [4.446899] which lock already depends on the new lock.
> [4.446899]
> [4.447622]
> [4.447622] the existing dependency chain (in reverse order) is:
> [4.448297]
> [4.448297] -> #1 ((completion)&abba.b_ready){+.+.}:
> [4.448912]save_stack_trace+0x1e/0x2e
> [4.449336]__lock_acquire+0x1554/0x1ea3
> [4.449797]save_trace+0x0/0xfc
> [4.450156]lock_acquire+0x25f/0x368
> [4.450414]wait_for_common+0x1b/0x2b
> [4.450414]__wait_for_common+0x72/0x44b
> [4.450414]wait_for_common+0x1b/0x2b
> [4.450414]mark_held_locks+0x98/0xcb
> [4.450414]schedule_timeout+0x0/0x129
> [4.450414]trace_hardirqs_on_caller+0x353/0x3ac
> [4.450414]wait_for_common+0x1b/0x2b
> [4.450414]wait_for_completion+0x1d/0x2c
> [4.450414]test_abba+0x180/0x351
> [4.450414]test_abba_work+0x0/0x167
> [4.450414]test_abba+0x14c/0x351
> [4.450414]complete+0x1d/0x95
> [4.450414]ww_acquire_fini+0x20/0xca
> [4.450414]test_aa+0x161/0x17a
> [4.450414]test_aa+0x4d/0x17a
> [4.450414]test_ww_mutex_init+0x17f/0x694
> [4.450414]_raw_spin_unlock_irqrestore+0xbb/0x13e
> [4.450414]add_device_randomness+0x29d/0x368
> [4.450414]test_ww_mutex_init+0x0/0x694
> [4.450414]do_one_initcall+0x108/0x279
> [4.450414]do_early_param+0xee/0x1a1
> [4.450414]kernel_init_freeable+0x2b6/0x494
> [4.450414]kernel_init_freeable+0x2b6/0x494
> [4.450414]kernel_init_freeable+0x2ed/0x494
> [4.450414]kernel_init+0x0/0x231
> [4.450414]kernel_init+0x13/0x231
> [4.450414]ret_from_fork+0x19/0x30
This stack trace looks weird. It seems to miss the '?' prefix when
unwinding a stack within save_stack_trace().
> [4.450414]
> [4.450414] -> #0 (ww_class_mutex){+.+.}:
> [4.450414]test_abba_work+0x3b/0x167
> [4.450414]
> [4.450414] other info that might help us debug this:
> [4.450414]
> [4.450414] Possible unsafe locking scenario by crosslock:
> [4.450414]
> [4.450414]CPU0CPU1
> [4.450414]
> [4.450414] lock(ww_class_mutex);
> [4.450414] lock((completion)&abba.b_ready);
> [4.450414]lock(ww_class_mutex);
> [4.450414]
> unlock((completion)&abba.b_ready);
> [4.450414]
> [4.450414] *** DEADLOCK ***
IMHO, lockdep reported a real problem _if_ abba.a_mutex and abba.b_mutex
should have the same class "ww_class_mutex", becasue the following is
possible to happen:
test_abba()
schedule_work(&abba.work)
acquire &ww_class_mutex
wait_for_completion(&abba.b_ready)
release &ww_class_mutex
run abba.work(=test_abba_work())
acquire &ww_class_mutex <- stuck here
complete(&adda->b_ready)
release &ww_class_mutex
I need ask you. Should abba.a_mutex have the same class as abba.b_mutex
in the test?
Thanks,
Byungchul
> [4.450414]
> [
[btrfs] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 dio_complete+0x1d4/0x220
CC fsdevel. On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: Hi Linus, Up to now we see the below boot error/warnings when testing v4.14-rc6. They hit the RC release mainly due to various imperfections in 0day's auto bisection. So I manually list them here and CC the likely easy to debug ones to the corresponding maintainers in the followup emails. boot_successes: 4700 boot_failures: 247 [...] WARNING:at_fs/direct-io.c:#dio_complete: 7 WARNING:at_fs/iomap.c:#iomap_dio_complete: 3 WARNING:at_fs/iomap.c:#iomap_dio_rw: 1 The first warning happens on btrfs and is bisected to this commit. The other 2 warnings happen on xfs. commit 332391a9935da939319e473b4680e173df75afcf Author: Lukas Czerner AuthorDate: Thu Sep 21 08:16:29 2017 -0600 Commit: Jens Axboe CommitDate: Mon Sep 25 08:56:05 2017 -0600 fs: Fix page cache inconsistency when mixing buffered and AIO DIO Currently when mixing buffered reads and asynchronous direct writes it is possible to end up with the situation where we have stale data in the page cache while the new data is already written to disk. This is permanent until the affected pages are flushed away. Despite the fact that mixing buffered and direct IO is ill-advised it does pose a thread for a data integrity, is unexpected and should be fixed. Fix this by deferring completion of asynchronous direct writes to a process context in the case that there are mapped pages to be found in the inode. Later before the completion in dio_complete() invalidate the pages in question. This ensures that after the completion the pages in the written area are either unmapped, or populated with up-to-date data. Also do the same for the iomap case which uses iomap_dio_complete() instead. This has a side effect of deferring the completion to a process context for every AIO DIO that happens on inode that has pages mapped. However since the consensus is that this is ill-advised practice the performance implication should not be a problem. This was based on proposal from Jeff Moyer, thanks! Reviewed-by: Jan Kara Reviewed-by: Darrick J. Wong Reviewed-by: Jeff Moyer Signed-off-by: Lukas Czerner Signed-off-by: Jens Axboe --- fs/direct-io.c | 47 ++- fs/iomap.c | 29 - mm/filemap.c | 6 ++ 3 files changed, 64 insertions(+), 18 deletions(-) The call traces are: [ 334.461955] BTRFS info (device vdb): has skinny extents [ 334.463231] BTRFS info (device vdb): flagging fs with big metadata feature [ 334.469746] BTRFS info (device vdb): creating UUID tree [ 336.190840] [ cut here ] [ 336.193338] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 dio_complete+0x1d4/0x220 [ 336.196925] Modules linked in: btrfs xor zstd_decompress zstd_compress xxhash raid6_pq dm_mod rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver sr_mod cdrom sg ata_generic pata_acpi ppdev snd_pcm snd_timer snd soundcore serio_raw parport_pc pcspkr parport floppy ata_piix libata i2c_piix4 ip_tables [ 336.203746] CPU: 0 PID: 6379 Comm: kworker/0:0 Not tainted 4.14.0-rc6 #1 [ 336.204799] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 336.207480] Workqueue: dio/vdb dio_aio_complete_work [ 336.208373] task: 880079094a80 task.stack: c995 [ 336.210495] RIP: 0010:dio_complete+0x1d4/0x220 [ 336.211288] RSP: 0018:c9953e20 EFLAGS: 00010286 [ 336.213145] RAX: fff0 RBX: 8800aae8c780 RCX: c9953c70 [ 336.214232] RDX: 8000 RSI: 02b4 RDI: 81cb9ccb [ 336.216605] RBP: c9953e48 R08: R09: 880079c8b6c0 [ 336.217726] R10: 0074 R11: R12: 2000 [ 336.220141] R13: 2000 R14: 0003 R15: 00074000 [ 336.221232] FS: () GS:88013fc0() knlGS: [ 336.223915] CS: 0010 DS: ES: CR0: 80050033 [ 336.224885] CR2: 55e9eae6b750 CR3: 752c7000 CR4: 06f0 [ 336.227202] Call Trace: [ 336.227750] dio_aio_complete_work+0x19/0x20 [ 336.228536] process_one_work+0x198/0x3e0 [ 336.230396] worker_thread+0x4e/0x3e0 [ 336.231064] kthread+0x114/0x150 [ 336.232489] ? process_one_work+0x3e0/0x3e0 [ 336.233250] ? kthread_create_on_node+0x40/0x40 [ 336.234929] ? kthread_create_on_node+0x40/0x40 [ 336.235754] ret_from_fork+0x25/0x30 [ 336.237322] Code: 8b 78 30 48 83 7f 58 00 0f 84 e9 fe ff ff 4b 8d 54 27 ff 4c 89 fe 48 c1 fe 0c 48 c1 fa 0c e8 64 58 f3 ff 85 c0 0f 84 cc fe ff ff <0f> ff e9 c5 fe ff ff 8b 50 20 f6 c2 10 0f 84 e5 fe ff ff 48 8b [ 336.240031] ---[ end trace 3d29f0720cd16ad3 ]--- [ 378.043462] generic/095 [failed, exit status 1] - output mismatch (see /lkp/benchmarks/xfstests/results//generic/095.out.bad) [ 378.043465] [ 121.160532] run
[f2fs-dev] [PATCH] f2fs: optimize __update_nat_bits
Make three modification for __update_nat_bits:
1. Take the codes of dealing the nat with nid 0 out of the loop
Such nat only needs to be dealt with once at beginning.
2. Use " nat_index == 0" instead of " start_nid == 0" to decide if it's the
first nat block
It's better that we don't assume @start_nid is the first nid of the nat
block it's in.
3. Use " if (nat_blk->entries[i].block_addr != NULL_ADDR)" to explicitly
comfirm the value of block_addr
use constant to make sure the codes is right, even if the value of
NULL_ADDR changes.
Signed-off-by: Fan li
---
fs/f2fs/node.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index ac629d6..b97a031 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -2407,15 +2407,17 @@ static void __update_nat_bits(struct f2fs_sb_info *sbi,
nid_t start_nid,
unsigned int nat_index = start_nid / NAT_ENTRY_PER_BLOCK;
struct f2fs_nat_block *nat_blk = page_address(page);
int valid = 0;
- int i;
+ int i = 0;
if (!enabled_nat_bits(sbi, NULL))
return;
- for (i = 0; i < NAT_ENTRY_PER_BLOCK; i++) {
- if (start_nid == 0 && i == 0)
- valid++;
- if (nat_blk->entries[i].block_addr)
+ if (nat_index == 0) {
+ valid = 1;
+ i = 1;
+ }
+ for (; i < NAT_ENTRY_PER_BLOCK; i++) {
+ if (nat_blk->entries[i].block_addr != NULL_ADDR)
valid++;
}
if (valid == 0) {
--
2.7.4
Crypto Fixes for 4.14
Hi Linus: This push fixes an objtool regression. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Jason A. Donenfeld (1): crypto: x86/chacha20 - satisfy stack validation 2.0 arch/x86/crypto/chacha20-avx2-x86_64.S |4 ++-- arch/x86/crypto/chacha20-ssse3-x86_64.S |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] iio: adc: aspeed: Deassert reset in probe
The ASPEED SoC must deassert a reset in order to use the ADC peripheral.
The device tree bindings are updated to document the resets phandle, and
the example is updated to match what is expected for both the reset and
clock phandle.
Signed-off-by: Joel Stanley
---
.../devicetree/bindings/iio/adc/aspeed_adc.txt | 4 +++-
drivers/iio/adc/aspeed_adc.c| 21 -
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
index 674e133b7cd7..034fc2ba100e 100644
--- a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
@@ -8,6 +8,7 @@ Required properties:
- reg: memory window mapping address and length
- clocks: Input clock used to derive the sample clock. Expected to be the
SoC's APB clock.
+- resets: Reset controller phandle
- #io-channel-cells: Must be set to <1> to indicate channels are selected
by index.
@@ -15,6 +16,7 @@ Example:
adc@1e6e9000 {
compatible = "aspeed,ast2400-adc";
reg = <0x1e6e9000 0xb0>;
- clocks = <&clk_apb>;
+ clocks = <&syscon ASPEED_CLK_APB>;
+ resets = <&syscon ASPEED_RESET_ADC>;
#io-channel-cells = <1>;
};
diff --git a/drivers/iio/adc/aspeed_adc.c b/drivers/iio/adc/aspeed_adc.c
index 8a958d5f1905..0fc9712cdde4 100644
--- a/drivers/iio/adc/aspeed_adc.c
+++ b/drivers/iio/adc/aspeed_adc.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,11 +54,12 @@ struct aspeed_adc_model_data {
};
struct aspeed_adc_data {
- struct device *dev;
- void __iomem*base;
- spinlock_t clk_lock;
- struct clk_hw *clk_prescaler;
- struct clk_hw *clk_scaler;
+ struct device *dev;
+ void __iomem*base;
+ spinlock_t clk_lock;
+ struct clk_hw *clk_prescaler;
+ struct clk_hw *clk_scaler;
+ struct reset_control*rst;
};
#define ASPEED_CHAN(_idx, _data_reg_addr) {\
@@ -217,6 +219,13 @@ static int aspeed_adc_probe(struct platform_device *pdev)
goto scaler_error;
}
+ data->rst = devm_reset_control_get_optional_exclusive(&pdev->dev, NULL);
+ if (IS_ERR(data->rst)) {
+ dev_err(&pdev->dev, "invalid reset controller in device tree");
+ data->rst = NULL;
+ } else
+ reset_control_deassert(data->rst);
+
model_data = of_device_get_match_data(&pdev->dev);
if (model_data->wait_init_sequence) {
@@ -268,6 +277,7 @@ static int aspeed_adc_probe(struct platform_device *pdev)
scaler_error:
clk_hw_unregister_divider(data->clk_prescaler);
+ reset_control_assert(data->rst);
return ret;
}
@@ -282,6 +292,7 @@ static int aspeed_adc_remove(struct platform_device *pdev)
clk_disable_unprepare(data->clk_scaler->clk);
clk_hw_unregister_divider(data->clk_scaler);
clk_hw_unregister_divider(data->clk_prescaler);
+ reset_control_assert(data->rst);
return 0;
}
--
2.14.1
Re: [PATCH v2 1/1] mtd: intel-spi: Add Intel Lewisburg PCH SPI super SKU PCI ID
On Sun, Oct 29, 2017 at 03:17:35PM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > This patch adds Intel Lewisburg PCH SPI serial flash controller super > SKU PCI ID. > > Signed-off-by: Kuppuswamy Sathyanarayanan > Acked-by: Mika Westerberg
Re: [PATCH v4] KVM: arm/arm64: fix the incompatible matching for external abort
On Mon, Oct 30, 2017 at 02:05:18PM +0800, Dongjiu Geng wrote:
> kvm_vcpu_dabt_isextabt() tries to match a full fault syndrome, but
> calls kvm_vcpu_trap_get_fault_type() that only returns the fault class,
> thus reducing the scope of the check. This doesn't cause any observable
> bug yet as we end-up matching a closely related syndrome for which we
> return the same value.
>
> Using kvm_vcpu_trap_get_fault() instead fixes it for good.
>
> Signed-off-by: Dongjiu Geng
> Acked-by: Marc Zyngier
Applied, thanks.
-Christoffer
> ---
> arch/arm/include/asm/kvm_emulate.h | 2 +-
> arch/arm64/include/asm/kvm_emulate.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_emulate.h
> b/arch/arm/include/asm/kvm_emulate.h
> index 98089ff..7571b4e 100644
> --- a/arch/arm/include/asm/kvm_emulate.h
> +++ b/arch/arm/include/asm/kvm_emulate.h
> @@ -203,7 +203,7 @@ static inline u8 kvm_vcpu_trap_get_fault_type(struct
> kvm_vcpu *vcpu)
>
> static inline bool kvm_vcpu_dabt_isextabt(struct kvm_vcpu *vcpu)
> {
> - switch (kvm_vcpu_trap_get_fault_type(vcpu)) {
> + switch (kvm_vcpu_trap_get_fault(vcpu)) {
> case FSC_SEA:
> case FSC_SEA_TTW0:
> case FSC_SEA_TTW1:
> diff --git a/arch/arm64/include/asm/kvm_emulate.h
> b/arch/arm64/include/asm/kvm_emulate.h
> index e5df3fc..8c918c5 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -237,7 +237,7 @@ static inline u8 kvm_vcpu_trap_get_fault_type(const
> struct kvm_vcpu *vcpu)
>
> static inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
> {
> - switch (kvm_vcpu_trap_get_fault_type(vcpu)) {
> + switch (kvm_vcpu_trap_get_fault(vcpu)) {
> case FSC_SEA:
> case FSC_SEA_TTW0:
> case FSC_SEA_TTW1:
> --
> 1.9.1
>
[PATCH] PCI: rcar: Use common error handling code in rcar_pcie_enable_msi()
From: Markus Elfring
Date: Mon, 30 Oct 2017 08:28:06 +0100
Adjust a jump target so that a specific error message is stored only once
at the end of this function implementation.
Replace two calls of the function "dev_err" by goto statements.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/pci/host/pcie-rcar.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 12796eccb2be..38101f8bebf1 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -873,18 +873,14 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
err = devm_request_irq(dev, msi->irq1, rcar_pcie_msi_irq,
IRQF_SHARED | IRQF_NO_THREAD,
rcar_msi_irq_chip.name, pcie);
- if (err < 0) {
- dev_err(dev, "failed to request IRQ: %d\n", err);
- goto err;
- }
+ if (err < 0)
+ goto report_request_failure;
err = devm_request_irq(dev, msi->irq2, rcar_pcie_msi_irq,
IRQF_SHARED | IRQF_NO_THREAD,
rcar_msi_irq_chip.name, pcie);
- if (err < 0) {
- dev_err(dev, "failed to request IRQ: %d\n", err);
- goto err;
- }
+ if (err < 0)
+ goto report_request_failure;
/* setup MSI data target */
msi->pages = __get_free_pages(GFP_KERNEL, 0);
@@ -898,7 +894,8 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
return 0;
-err:
+report_request_failure:
+ dev_err(dev, "failed to request IRQ: %d\n", err);
irq_domain_remove(msi->domain);
return err;
}
--
2.14.3
Re: [PATCH] irqdomain: Update the comments of fwnode field of irq_domain structure
On Mon, Oct 30 2017 at 10:15:00 am GMT, Dou Liyang
wrote:
> Commit:
>
> f110711a6053 ("irqdomain: Convert irqdomain-%3Eof_node to fwnode")
>
> converted of_node field to fwnode, but didn't update its comments.
>
> Update it.
>
> Signed-off-by: Dou Liyang
Queued, thanks.
M.
--
Jazz is not dead. It just smells funny.
Re: [PATCH RFC] random: fix syzkaller fuzzer test int overflow
On Sun, Oct 29, 2017 at 02:25:29PM -0400, Theodore Ts'o wrote: > On Sat, Oct 28, 2017 at 11:22:00AM +0800, Chen Feng wrote: > > > > I checked the ioctl. What's the purpose of RNDADDTOENTCNT ioctl to > > userspace? > > It's a legacy ioctl which is probably not used anywhere; it's been > replaced by RNDADDENTROPY. It previously allows root to bump the > entropy estimate, but the right way to do this by rngd is to > atomically add entropy to the pool land and bump the entropy estimate > at the same time. > > The UBSAN is harmless. The ioctl requires root, and the entropy_total > field, which is involved in the UBSAN, is only used in the first few > seconds of boot, to determine when the entropy pool has been > initialized. In general on desktop and servers this happens before > userspace has a chance to run. > > In any case, here's a fix for this. > > - Ted > > commit 6f7034d0c52e21f30002b95126b6b98e4618dc57 > Author: Theodore Ts'o > Date: Sun Oct 29 14:17:26 2017 -0400 > > random: use a tighter cap in credit_entropy_bits_safe() > > This fixes a harmless UBSAN where root could potentially end up > causing an overflow while bumping the entropy_total field (which is > ignored once the entropy pool has been initialized, and this generally > is completed during the boot sequence). > > This is marginal for the stable kernel series, but it's a really > trivial patch, and it UBSAN warning that might cause security folks to > get overly excited for no reason. > > Signed-off-by: Theodore Ts'o > Cc: sta...@vger.kernel.org No "Reported-by:"? thanks, greg k-h
[pmem_attach_disk] WARNING: CPU: 46 PID: 518 at kernel/memremap.c:363 devm_memremap_pages+0x350/0x4b0
CC nvdimm maintainers. On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: Hi Linus, Up to now we see the below boot error/warnings when testing v4.14-rc6. They hit the RC release mainly due to various imperfections in 0day's auto bisection. So I manually list them here and CC the likely easy to debug ones to the corresponding maintainers in the followup emails. boot_successes: 4700 boot_failures: 247 [...] WARNING:at_kernel/memremap.c:#devm_memremap_pages: 1 Bisect failed, hope it's not hard to debug: Start [ 18.989316] devm_memremap_pages attempted on mixed region [mem 0x68000-0x103dff flags 0x200] [ 19.000802] [ cut here ] [ 19.005965] WARNING: CPU: 46 PID: 518 at kernel/memremap.c:363 devm_memremap_pages+0x350/0x4b0 ing udev Kernel [ 19.017134] Modules linked in: irqbypass nd_pmem(O+) crct10dif_pclmul crc32_pclmul dax_pmem(O) crc32c_intel syscopyarea ahci snd_pcm device_dax(O) nd_btt(O) sysfillrect sysimgblt ghash_clmulni_intel isci snd_timer fb_sys_fops nd_e820(O) pcbc libahci libsas snd scsi_transport_sas aesni_intel crypto_simd soundcore ipmi_si libnvdimm(O) glue_helper drm ipmi_devintf cryptd nfit_test_iomap(O) pcspkr libata shpchp wmi ipmi_msghandler ip_tables Device Manager.. [ 19.061856] CPU: 46 PID: 518 Comm: systemd-udevd Tainted: G O 4.14.0-rc6 #1 . reprocess NFS co [ 19.093600] RIP: 0010:devm_memremap_pages+0x350/0x4b0 nfiguration. ] Reached target [ 19.117685] RDX: 880648596180 RSI: 88064858e018 RDI: 88064858e018 NFS client serv [ 19.127194] RBP: c9000570ba68 R08: R09: 05ba ices. ed udev Kernel D [ 19.155740] FS: 7f831194c8c0() GS:88064858() knlGS: evice Manager. [ 19.166322] CS: 0010 DS: ES: CR0: 80050033 0m] Started Jour [ 19.180217] ata2: SATA link down (SStatus 0 SControl 300) nal Service. [ 19.180248] ata1: SATA link down (SStatus 0 SControl 300) [ 19.180278] ata5: SATA link down (SStatus 0 SControl 300) [ 19.180310] ata4: SATA link down (SStatus 0 SControl 300) [ 19.180338] ata3: SATA link down (SStatus 0 SControl 300) [ 19.181202] ata6: SATA link down (SStatus 0 SControl 300) [ 19.222866] Call Trace: [ 19.222874] __wrap_devm_memremap_pages+0x88/0xa0 [nfit_test_iomap] [ 19.222877] pmem_attach_disk+0x1c4/0x530 [nd_pmem] [ 19.222880] ? kfree_const+0x21/0x30 [ 19.222883] ? kobject_put+0xb8/0x190 [ 19.222886] ? put_device+0x17/0x20 [ 19.222895] ? nd_dax_probe+0x10d/0x140 [libnvdimm] [ 19.222896] Error: Driver 'pcspkr' is already registered, aborting... [ 19.222898] nd_pmem_probe+0x7e/0x170 [nd_pmem] [ 19.222906] nvdimm_bus_probe+0x71/0x120 [libnvdimm] [ 19.222909] driver_probe_device+0x29c/0x450 [ 19.222910] __driver_attach+0xdf/0xf0 [ 19.222912] ? driver_probe_device+0x450/0x450 [ 19.222913] bus_for_each_dev+0x60/0xa0 [ 19.222915] driver_attach+0x1e/0x20 [ 19.222916] bus_add_driver+0x170/0x260 [ 19.222918] driver_register+0x60/0xe0 [ 19.222919] ? 0xa00da000 [ 19.222922] __nd_driver_register+0x3b/0x80 [libnvdimm] [ 19.222924] pmem_init+0x1e/0x1000 [nd_pmem] [ 19.222926] do_one_initcall+0x43/0x170 [ 19.222928] ? __might_sleep+0x4a/0x80 [ 19.222931] ? kmem_cache_alloc_trace+0x16f/0x1c0 [ 19.222933] do_init_module+0x5f/0x1fe [ 19.222935] load_module+0x1586/0x1c90 [ 19.222937] ? kernel_read_file+0x160/0x180 [ 19.222939] SYSC_finit_module+0xbc/0xf0 [ 19.222941] ? SYSC_finit_module+0xbc/0xf0 [ 19.222943] SyS_finit_module+0xe/0x10 [ 19.222944] entry_SYSCALL_64_fastpath+0x1a/0xa5 [ 19.222945] RIP: 0033:0x7f83107c7d49 [ 19.222946] RSP: 002b:7ffe140c4b38 EFLAGS: 0246 ORIG_RAX: 0139 [ 19.222947] RAX: ffda RBX: 55f9dd5843d0 RCX: 7f83107c7d49 [ 19.222948] RDX: RSI: 7f83110e3525 RDI: 0010 [ 19.222948] RBP: 7f83110e3525 R08: R09: 7ffe140c50b0 [ 19.222949] R10: 0010 R11: 0246 R12: [ 19.222949] R13: 55f9dd571640 R14: 0002 R15: 55f9dbfa95b3 [ 19.222951] Code: 00 49 c7 c4 fa ff ff ff 0f 85 02 ff ff ff 48 89 da 48 c7 c6 e0 92 a3 81 48 c7 c7 70 87 cb 81 c6 05 ef 59 e7 00 01 e8 b1 ab f3 ff <0f> ff e9 de fe ff ff 48 8b 7d c8 89 c1 48 c7 c2 e0 92 a3 81 48 [ 19.222966] ---[ end trace 0a5b3bdfcc982038 ]--- [ 19.223193] nd_pmem namespace1.0: unable to guarantee persistence of writes Thanks, Fengguang
Re: [PATCH] netfilter: ipset: ip_set_bitmap_ipmac: use swap macro in bitmap_ipmac_create
Hi, On Sat, 28 Oct 2017, Gustavo A. R. Silva wrote: > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva Please resubmit the tree patches as a single one, they do the same thing. Thanks! Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
Re: [btrfs] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 dio_complete+0x1d4/0x220
Hi Fengguang, On Mon, Oct 30, 2017 at 08:20:21AM +0100, Fengguang Wu wrote: > CC fsdevel. > > On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: > > Hi Linus, > > > > Up to now we see the below boot error/warnings when testing v4.14-rc6. > > > > They hit the RC release mainly due to various imperfections in 0day's > > auto bisection. So I manually list them here and CC the likely easy to > > debug ones to the corresponding maintainers in the followup emails. > > > > boot_successes: 4700 > > boot_failures: 247 > > [...] > > > WARNING:at_fs/direct-io.c:#dio_complete: 7 > > WARNING:at_fs/iomap.c:#iomap_dio_complete: 3 > > WARNING:at_fs/iomap.c:#iomap_dio_rw: 1 > > The first warning happens on btrfs and is bisected to this commit. > The other 2 warnings happen on xfs. I noticed that the warnings are triggered by generic/095 and generic/208, they're known to generate such warnings and I think these warnings are kind of 'known issue', please see comments above _filter_aiodio_dmesg() in fstests/common/filter. Please make sure your local fstests contains the following 3 commits: ca93e26865ab common: move _filter_xfs_dmesg() to common/filter 5aa662733ab0 common: turn _filter_xfs_dmesg() into _filter_aiodio_dmesg() 228aee780f13 generic/036,208: whitelist [iomap_]dio_complete() WARNs we filtered out such warnings in fstests on purpose so the affected tests won't fail because of such dmesg warnings. Thanks, Eryu > > commit 332391a9935da939319e473b4680e173df75afcf > Author: Lukas Czerner > AuthorDate: Thu Sep 21 08:16:29 2017 -0600 > Commit: Jens Axboe > CommitDate: Mon Sep 25 08:56:05 2017 -0600 > >fs: Fix page cache inconsistency when mixing buffered and AIO DIO > >Currently when mixing buffered reads and asynchronous direct writes it >is possible to end up with the situation where we have stale data in the >page cache while the new data is already written to disk. This is >permanent until the affected pages are flushed away. Despite the fact >that mixing buffered and direct IO is ill-advised it does pose a thread >for a data integrity, is unexpected and should be fixed. > >Fix this by deferring completion of asynchronous direct writes to a >process context in the case that there are mapped pages to be found in >the inode. Later before the completion in dio_complete() invalidate >the pages in question. This ensures that after the completion the pages >in the written area are either unmapped, or populated with up-to-date >data. Also do the same for the iomap case which uses >iomap_dio_complete() instead. > >This has a side effect of deferring the completion to a process context >for every AIO DIO that happens on inode that has pages mapped. However >since the consensus is that this is ill-advised practice the performance >implication should not be a problem. > >This was based on proposal from Jeff Moyer, thanks! > >Reviewed-by: Jan Kara >Reviewed-by: Darrick J. Wong >Reviewed-by: Jeff Moyer >Signed-off-by: Lukas Czerner >Signed-off-by: Jens Axboe > --- > fs/direct-io.c | 47 ++- > fs/iomap.c | 29 - > mm/filemap.c | 6 ++ > 3 files changed, 64 insertions(+), 18 deletions(-) > > The call traces are: > > [ 334.461955] BTRFS info (device vdb): has skinny extents > [ 334.463231] BTRFS info (device vdb): flagging fs with big metadata feature > [ 334.469746] BTRFS info (device vdb): creating UUID tree > [ 336.190840] [ cut here ] > [ 336.193338] WARNING: CPU: 0 PID: 6379 at fs/direct-io.c:293 > dio_complete+0x1d4/0x220 > [ 336.196925] Modules linked in: btrfs xor zstd_decompress zstd_compress > xxhash raid6_pq dm_mod rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver sr_mod > cdrom sg ata_generic pata_acpi ppdev snd_pcm snd_timer snd soundcore > serio_raw parport_pc pcspkr parport floppy ata_piix libata i2c_piix4 ip_tables > [ 336.203746] CPU: 0 PID: 6379 Comm: kworker/0:0 Not tainted 4.14.0-rc6 #1 > [ 336.204799] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.10.2-1 04/01/2014 > [ 336.207480] Workqueue: dio/vdb dio_aio_complete_work > [ 336.208373] task: 880079094a80 task.stack: c995 > [ 336.210495] RIP: 0010:dio_complete+0x1d4/0x220 > [ 336.211288] RSP: 0018:c9953e20 EFLAGS: 00010286 > [ 336.213145] RAX: fff0 RBX: 8800aae8c780 RCX: > c9953c70 > [ 336.214232] RDX: 8000 RSI: 02b4 RDI: > 81cb9ccb > [ 336.216605] RBP: c9953e48 R08: R09: > 880079c8b6c0 > [ 336.217726] R10: 0074 R11: R12: > 2000 > [ 336.220141] R13: 2000 R14: 0003 R15: > 00074000 > [ 336.221232] FS: () GS:88013fc0() > knlGS: > [ 336.223915] CS: 00
Re: [locking/paravirt] static_key_disable_cpuslocked(): static key 'virt_spin_lock_key+0x0/0x20' used before call to jump_label_init()
On 30/10/17 08:35, Fengguang Wu wrote: > On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: >> Hi Linus, >> >> Up to now we see the below boot error/warnings when testing v4.14-rc6. >> >> They hit the RC release mainly due to various imperfections in 0day's >> auto bisection. So I manually list them here and CC the likely easy to >> debug ones to the corresponding maintainers in the followup emails. >> >> boot_successes: 4700 >> boot_failures: 247 > > [...] > >> WARNING:at_kernel/jump_label.c:#static_key_disable_cpuslocked: 7 This patch is in the tip tree only, it will be merged in 4.15. So I don't understand why you are reporting this for 4.14-rc6. There is a patch by Dou Liyang pending since 28th October addressing that issue: [PATCH tip v2] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init() Juergen > > The call trace is > > [ 0.00] Booting paravirtualized kernel on bare hardware > [ 0.00] clocksource: refined-jiffies: mask: 0x > max_cycles: 0x, max_idle_ns: 1910969940391419 ns > [ 0.00] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:72 > nr_cpu_ids:72 nr_node_ids:2 > [ 0.00] percpu: Embedded 39 pages/cpu @88103f40 s120088 > r8192 d31464 u262144 > [ 0.00] pcpu-alloc: s120088 r8192 d31464 u262144 alloc=1*2097152 > [ 0.00] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 > 12 13 14 15 [ 0.00] pcpu-alloc: [0] 16 17 36 37 38 39 40 41 [0] > 42 43 44 45 46 47 48 49 [ 0.00] pcpu-alloc: [0] 50 51 52 53 -- -- > -- -- [1] 18 19 20 21 22 23 24 25 [ 0.00] pcpu-alloc: [1] 26 27 > 28 29 30 31 32 33 [1] 34 35 54 55 56 57 58 59 [ 0.00] pcpu-alloc: > [1] 60 61 62 63 64 65 66 67 [1] 68 69 70 71 -- -- -- -- [ 0.00] > static_key_disable_cpuslocked(): static key > 'virt_spin_lock_key+0x0/0x20' used before call to jump_label_init() > [ 0.00] [ cut here ] > [ 0.00] WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:161 > static_key_disable_cpuslocked+0x6c/0x80 > [ 0.00] Modules linked in: > [ 0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > 4.14.0-rc6-00162-g3d6dabc2 #1 > [ 0.00] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS > SE5C610.86B.01.01.0008.021120151325 02/11/2015 > [ 0.00] task: 81e10480 task.stack: 81e0 > [ 0.00] RIP: 0010:static_key_disable_cpuslocked+0x6c/0x80 > [ 0.00] RSP: :81e03e98 EFLAGS: 00010092 ORIG_RAX: > > [ 0.00] RAX: 006f RBX: 81e36fc0 RCX: > 81e60cf8 > [ 0.00] RDX: 0001 RSI: 0092 RDI: > 0047 > [ 0.00] RBP: 81e03ea8 R08: 6b5f636974617473 R09: > 018c > [ 0.00] R10: R11: 006f R12: > 88207ffcf4c0 > [ 0.00] R13: 82170920 R14: 8218b780 R15: > > [ 0.00] FS: () GS:88103f40() > knlGS: > [ 0.00] CS: 0010 DS: ES: CR0: 80050033 > [ 0.00] CR2: 88207f4e CR3: 00207ee09000 CR4: > 000606b0 > [ 0.00] Call Trace: > [ 0.00] static_key_disable+0x1a/0x30 > [ 0.00] native_pv_lock_init+0x1b/0x1e > [ 0.00] native_smp_prepare_boot_cpu+0x32/0x35 > [ 0.00] start_kernel+0x14f/0x421 > [ 0.00] x86_64_start_reservations+0x2a/0x2c > [ 0.00] x86_64_start_kernel+0x72/0x75 > [ 0.00] secondary_startup_64+0xa5/0xb0 > [ 0.00] Code: 85 c0 75 2f 48 c7 c7 20 5e f0 81 e8 df 2a 7b 00 5b > 41 5c 5d c3 48 89 fa 48 c7 c6 40 93 a3 81 48 c7 c7 00 8b cb 81 e8 95 b5 > f3 ff <0f> ff eb a8 0f ff eb b3 48 89 df e8 14 fc ff ff eb c7 66 90 e8 > [ 0.00] ---[ end trace c12d07f00399ce78 ]--- > [ 0.00] Built 2 zonelists, mobility grouping on. Total pages: > 33006159 > [ 0.00] Policy zone: Normal > > which is bisected to > > commit 9043442b43b1fddf202591b84702863286700c1a > Author: Juergen Gross > AuthorDate: Wed Sep 6 19:36:24 2017 +0200 > Commit: Ingo Molnar > CommitDate: Tue Oct 10 11:50:12 2017 +0200 > > locking/paravirt: Use new static key for controlling call of > virt_spin_lock() > > There are cases where a guest tries to switch spinlocks to bare metal > behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this > has the downside of falling back to unfair test and set scheme for > qspinlocks due to virt_spin_lock() detecting the virtualized > environment. > > Add a static key controlling whether virt_spin_lock() should be > called or not. When running on bare metal set the new key to false. > > Signed-off-by: Juergen Gross > Signed-off-by: Peter Zijlstra (Intel) > Acked-by: Waiman Long > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: akata...@vmware.com > Cc: boris.ostrov...@oracle.com > Cc: chr...@
Re: 4.13 (and probably all recent) kernels refuse to boot on one Nokia N950, work or another
Hi! > > I got "uncompressing Linux 4.13" on serial console now, debug LEDs > > blinking, and if I use a flashlight, I see output on the screen, too. > > > > (What do I need to do to get the backlight working?) > > Glad you got it working :) For backlight you can add this > in drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c: > > add the following code at the end of dsicm_probe: > > --- > mutex_unlock(&ddata->lock); > mutex_lock(&ddata->lock); > ddata->in->ops.dsi->bus_lock(ddata->in); > r = dsicm_wake_up(ddata); > if (!r) > r = dsicm_dcs_write_1(ddata, DCS_BRIGHTNESS, 100); > ddata->in->ops.dsi->bus_unlock(ddata->in); > mutex_unlock(&ddata->lock); > --- That one did not work; but after some help from Filip, this did: Best regards, Pavel diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c index b5ea8e5..2cb74cc 100644 --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c @@ -385,7 +385,7 @@ static int dsicm_bl_update_status(struct backlight_device *dev) r = dsicm_wake_up(ddata); if (!r) - r = dsicm_dcs_write_1(ddata, DCS_BRIGHTNESS, level); + r = dsicm_dcs_write_1(ddata, DCS_BRIGHTNESS, 0xff /* level */); in->ops.dsi->bus_unlock(in); } -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v6 0/9] vITS Migration fixes and reset
Hi Christoffer, On 30/10/2017 07:20, Christoffer Dall wrote: > Hi Eric, > > On Thu, Oct 26, 2017 at 05:23:02PM +0200, Eric Auger wrote: >> This series fixes various bugs observed when saving/restoring the >> ITS state before the guest writes the ITS registers (on first boot or >> after reset/reboot). >> >> This is a follow up of Wanghaibin's series [1] plus additional >> patches following additional code review. It also proposes one >> ITS reset implementation. >> >> Currently, the in-kernel emulated ITS is not reset. After a >> reset/reboot, the ITS register values and caches are left >> unchanged. Registers may point to some tables in guest memory >> which do not exist anymore. If an ITS state backup is initiated >> before the guest re-writes the registers, the save fails >> because inconsistencies are detected. Also restore of data saved >> as such moment is failing. >> >> Patches [1-4] are fixes of bugs observed during migration at >> early guets boot stage. >> - handle case where all collection, device and ITT entries are >> invalid on restore (which is not an error) >> - Check the GITS_BASER valid bit before attempting the save >> any table >> - Check the GITS_BASER and GITS_CBASER are valid before enabling >> the ITS >> >> Patches [5-9] allow to empty the caches on reset and implement a >> new ITS reset IOCTL > > I applied patches 1-4 to kvmarm/master and included them in a late pull > request to kvm. > > I also took the remaining patches with the adjusted comment in > kvmarm/next. OK Thanks. > > One question: Don't we have a remaining issue to support saving the > collection table even if the device table is inconsistent and vice > versa? Are you planning on picking up that work? Actually to make it clear, patches 1-4 don't fix all failures but we discussed at KVM forum that we shouldn't try to fix all of them without a proper ITS reset implementation. So indeed even with patches 1-4 you can get the migration failing as the save can happen after a reset, in-between the collection creation and the PCIe device MSI registration. This happens because the caches are not void and the L1 device table entries are not valid. In that case the device table save fails and we get no chance to save the collection as we abort the save immediately. So on restore, guest will not work properly. But on top of kvmarm/next, caches are void and we shouldn't face this issue anymore. So in case the device table save fails, I think it still makes sense to return an error. But this means that the migration of ITS at early guest boot stage only is fixed on kvmarm/next. Thanks Eric > > Thanks, > -Christoffer >
Re: [PATCH 2/8] irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs
On Wed, Oct 25 2017 at 5:37:24 pm BST, Paul Burton
wrote:
> The gic_all_vpes_local_irq_controller chip currently attempts to operate
> on all CPUs/VPs in the system when masking or unmasking an interrupt.
> This has a few drawbacks:
>
> - In multi-cluster systems we may not always have access to all CPUs in
>the system. When all CPUs in a cluster are powered down that
>cluster's GIC may also power down, in which case we cannot configure
>its state.
>
> - Relatedly, if we power down a cluster after having configured
>interrupts for CPUs within it then the cluster's GIC may lose state &
>we need to reconfigure it. The current approach doesn't take this
>into account.
>
> - It's wasteful if we run Linux on fewer VPs than are present in the
>system. For example if we run a uniprocessor kernel on CPU0 of a
>system with 16 CPUs then there's no point in us configuring CPUs
>1-15.
>
> - The implementation is also lacking in that it expects the range
>0..gic_vpes-1 to represent valid Linux CPU numbers which may not
>always be the case - for example if we run on a system with more VPs
>than the kernel is configured to support.
>
> Fix all of these issues by only configuring the affected interrupts for
> CPUs which are online at the time, and recording the configuration in a
> new struct gic_all_vpes_chip_data for later use by CPUs being brought
> online. We register a CPU hotplug state (reusing
> CPUHP_AP_IRQ_GIC_STARTING which the ARM GIC driver uses, and which seems
> suitably generic for reuse with the MIPS GIC) and execute
> irq_cpu_online() in order to configure the interrupts on the newly
> onlined CPU.
>
> Signed-off-by: Paul Burton
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Thomas Gleixner
> Cc: linux-m...@linux-mips.org
> ---
>
> drivers/irqchip/irq-mips-gic.c | 72
> --
> 1 file changed, 56 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
> index 6fdcc1552fab..dd9da773db90 100644
> --- a/drivers/irqchip/irq-mips-gic.c
> +++ b/drivers/irqchip/irq-mips-gic.c
[...]
> @@ -622,6 +653,13 @@ static const struct irq_domain_ops gic_ipi_domain_ops = {
> .match = gic_ipi_domain_match,
> };
>
> +static int gic_cpu_startup(unsigned int cpu)
> +{
> + /* Invoke irq_cpu_online callbacks to enable desired interrupts */
> + irq_cpu_online();
> +
> + return 0;
> +}
>
> static int __init gic_of_init(struct device_node *node,
> struct device_node *parent)
> @@ -768,6 +806,8 @@ static int __init gic_of_init(struct device_node *node,
> }
> }
>
> - return 0;
> + return cpuhp_setup_state(CPUHP_AP_IRQ_GIC_STARTING,
> + "irqchip/mips/gic:starting",
> + gic_cpu_startup, NULL);
I'm wondering about this. CPUHP_AP_IRQ_GIC_STARTING is a symbol that is
used on ARM platforms. You're very welcome to use it (as long as nobody
builds a system with both an ARM GIC and a MIPS GIC...), but I'm a bit
worried that we could end-up breaking things if one of us decides to
reorder it in enum cpuhp_state.
The safest option would be for you to add your own state value, which
would allow the two architecture to evolve independently.
Thoughts?
M.
--
Jazz is not dead. It just smells funny.
Re: [PATCH -mm -V2] mm, swap: Fix false error message in __swp_swapcount()
On Mon 30-10-17 08:57:13, Minchan Kim wrote:
[...]
> Although it's better than old, we can make it simple, still.
>
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index 291c4b534658..f50d5a48f03a 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -41,6 +41,13 @@ static inline unsigned swp_type(swp_entry_t entry)
> return (entry.val >> SWP_TYPE_SHIFT(entry));
> }
>
> +extern struct swap_info_struct *swap_info[];
> +
> +static inline struct swap_info_struct *swp_si(swp_entry_t entry)
> +{
> + return swap_info[swp_type(entry)];
> +}
> +
> /*
> * Extract the `offset' field from a swp_entry_t. The swp_entry_t is in
> * arch-independent format
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 378262d3a197..a0fe2d54ad09 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -554,6 +554,7 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t
> gfp_mask,
> struct vm_area_struct *vma, unsigned long addr)
> {
> struct page *page;
> + struct swap_info_struct *si = swp_si(entry);
Aren't you accessing beyond the array here?
> unsigned long entry_offset = swp_offset(entry);
> unsigned long offset = entry_offset;
> unsigned long start_offset, end_offset;
> @@ -572,6 +573,9 @@ struct page *swapin_readahead(swp_entry_t entry, gfp_t
> gfp_mask,
> if (!start_offset) /* First page is swap header. */
> start_offset++;
>
> + if (end_offset >= si->max)
> + end_offset = si->max - 1;
> +
> blk_start_plug(&plug);
> for (offset = start_offset; offset <= end_offset ; offset++) {
> /* Ok, do the async read-ahead now */
--
Michal Hocko
SUSE Labs
Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules
On Fri, 27 Oct 2017 17:34:44 +0800
Zhou Chengming wrote:
> Fixes: 2cfa197 "ftrace/alternatives: Introducing *_text_reserved
> functions"
>
> We use alternatives_text_reserved() to check if the address is in
> the fixed pieces of alternative reserved, but the problem is that
> we don't hold the smp_alt mutex when call this function. So the list
> traversal may encounter a deleted list_head if another path is doing
> alternatives_smp_module_del().
>
> One solution is that we can hold smp_alt mutex before call this
> function, but the difficult point is that the callers of this
> functions, arch_prepare_kprobe() and arch_prepare_optimized_kprobe(),
> are called inside the text_mutex. So we must hold smp_alt mutex
> before we go into these arch dependent code. But we can't now,
> the smp_alt mutex is the arch dependent part, only x86 has it.
> Maybe we can export another arch dependent callback to solve this.
>
> But there is a simpler way to handle this problem. We can reuse the
> text_mutex to protect smp_alt_modules instead of using another mutex.
> And all the arch dependent checks of kprobes are inside the text_mutex,
> so it's safe now.
OK, I considered other ways but those may introduce unneeded
complexity. So this simple solution is better to fix this bug.
Reviewed-by: Masami Hiramatsu
Thank you,
>
> Signed-off-by: Zhou Chengming
> ---
> arch/x86/kernel/alternative.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 3344d33..55abbaa 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -442,7 +442,6 @@ static void alternatives_smp_lock(const s32 *start, const
> s32 *end,
> {
> const s32 *poff;
>
> - mutex_lock(&text_mutex);
> for (poff = start; poff < end; poff++) {
> u8 *ptr = (u8 *)poff + *poff;
>
> @@ -452,7 +451,6 @@ static void alternatives_smp_lock(const s32 *start, const
> s32 *end,
> if (*ptr == 0x3e)
> text_poke(ptr, ((unsigned char []){0xf0}), 1);
> }
> - mutex_unlock(&text_mutex);
> }
>
> static void alternatives_smp_unlock(const s32 *start, const s32 *end,
> @@ -460,7 +458,6 @@ static void alternatives_smp_unlock(const s32 *start,
> const s32 *end,
> {
> const s32 *poff;
>
> - mutex_lock(&text_mutex);
> for (poff = start; poff < end; poff++) {
> u8 *ptr = (u8 *)poff + *poff;
>
> @@ -470,7 +467,6 @@ static void alternatives_smp_unlock(const s32 *start,
> const s32 *end,
> if (*ptr == 0xf0)
> text_poke(ptr, ((unsigned char []){0x3E}), 1);
> }
> - mutex_unlock(&text_mutex);
> }
>
> struct smp_alt_module {
> @@ -489,8 +485,7 @@ struct smp_alt_module {
> struct list_head next;
> };
> static LIST_HEAD(smp_alt_modules);
> -static DEFINE_MUTEX(smp_alt);
> -static bool uniproc_patched = false; /* protected by smp_alt */
> +static bool uniproc_patched = false; /* protected by text_mutex */
>
> void __init_or_module alternatives_smp_module_add(struct module *mod,
> char *name,
> @@ -499,7 +494,7 @@ void __init_or_module alternatives_smp_module_add(struct
> module *mod,
> {
> struct smp_alt_module *smp;
>
> - mutex_lock(&smp_alt);
> + mutex_lock(&text_mutex);
> if (!uniproc_patched)
> goto unlock;
>
> @@ -526,14 +521,14 @@ void __init_or_module
> alternatives_smp_module_add(struct module *mod,
> smp_unlock:
> alternatives_smp_unlock(locks, locks_end, text, text_end);
> unlock:
> - mutex_unlock(&smp_alt);
> + mutex_unlock(&text_mutex);
> }
>
> void __init_or_module alternatives_smp_module_del(struct module *mod)
> {
> struct smp_alt_module *item;
>
> - mutex_lock(&smp_alt);
> + mutex_lock(&text_mutex);
> list_for_each_entry(item, &smp_alt_modules, next) {
> if (mod != item->mod)
> continue;
> @@ -541,7 +536,7 @@ void __init_or_module alternatives_smp_module_del(struct
> module *mod)
> kfree(item);
> break;
> }
> - mutex_unlock(&smp_alt);
> + mutex_unlock(&text_mutex);
> }
>
> void alternatives_enable_smp(void)
> @@ -551,7 +546,7 @@ void alternatives_enable_smp(void)
> /* Why bother if there are no other CPUs? */
> BUG_ON(num_possible_cpus() == 1);
>
> - mutex_lock(&smp_alt);
> + mutex_lock(&text_mutex);
>
> if (uniproc_patched) {
> pr_info("switching to SMP code\n");
> @@ -563,10 +558,13 @@ void alternatives_enable_smp(void)
> mod->text, mod->text_end);
> uniproc_patched = false;
> }
> - mutex_unlock(&smp_alt);
> + mutex_unlock(&text_mutex);
> }
>
> -/* Return 1 if the address range is reserved for smp-alternatives */
> +/*
> +
[PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen
After guest live migration on xen, steal time in /proc/stat
(cpustat[CPUTIME_STEAL]) might decrease because steal returned by
xen_steal_lock() might be less than this_rq()->prev_steal_time which is
derived from previous return value of xen_steal_clock().
For instance, steal time of each vcpu is 335 before live migration.
cpu 198 0 368 200064 1962 0 0 1340 0 0
cpu0 38 0 81 50063 492 0 0 335 0 0
cpu1 65 0 97 49763 634 0 0 335 0 0
cpu2 38 0 81 50098 462 0 0 335 0 0
cpu3 56 0 107 50138 374 0 0 335 0 0
After live migration, steal time is reduced to 312.
cpu 200 0 370 200330 1971 0 0 1248 0 0
cpu0 38 0 82 50123 500 0 0 312 0 0
cpu1 65 0 97 49832 634 0 0 312 0 0
cpu2 39 0 82 50167 462 0 0 312 0 0
cpu3 56 0 107 50207 374 0 0 312 0 0
Since runstate times are cumulative and cleared during xen live migration
by xen hypervisor, the idea of this patch is to accumulate runstate times
to global percpu variables before live migration suspend. Once guest VM is
resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
runstate times and previously accumulated times stored in global percpu
variables.
Similar and more severe issue would impact prior linux 4.8-4.10 as
discussed by Michael Las at
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
which would overflow steal time and lead to 100% st usage in top command
for linux 4.8-4.10. A backport of this patch would fix that issue.
References:
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
Signed-off-by: Dongli Zhang
---
Changed since v1:
* relocate modification to xen_get_runstate_snapshot_cpu
Changed since v2:
* accumulate runstate times before live migration
Changed since v3:
* do not accumulate times in the case of guest checkpointing
Changed since v4:
* allocate array of vcpu_runstate_info to reduce number of memory allocation
---
drivers/xen/manage.c | 2 ++
drivers/xen/time.c | 68 ++--
include/xen/interface/vcpu.h | 2 ++
include/xen/xen-ops.h| 1 +
4 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index c425d03..3dc085d 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -72,6 +72,7 @@ static int xen_suspend(void *data)
}
gnttab_suspend();
+ xen_accumulate_runstate_time(-1);
xen_arch_pre_suspend();
/*
@@ -84,6 +85,7 @@ static int xen_suspend(void *data)
: 0);
xen_arch_post_suspend(si->cancelled);
+ xen_accumulate_runstate_time(si->cancelled);
gnttab_resume();
if (!si->cancelled) {
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index ac5f23f..cf3afb9 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -19,6 +19,9 @@
/* runstate info updated by Xen */
static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
+static DEFINE_PER_CPU(u64[RUNSTATE_max], old_runstate_time);
+static struct vcpu_runstate_info *runstate_delta;
+
/* return an consistent snapshot of 64-bit time/counter value */
static u64 get64(const u64 *p)
{
@@ -47,8 +50,8 @@ static u64 get64(const u64 *p)
return ret;
}
-static void xen_get_runstate_snapshot_cpu(struct vcpu_runstate_info *res,
- unsigned int cpu)
+static void xen_get_runstate_snapshot_cpu_delta(
+ struct vcpu_runstate_info *res, unsigned int cpu)
{
u64 state_time;
struct vcpu_runstate_info *state;
@@ -66,6 +69,67 @@ static void xen_get_runstate_snapshot_cpu(struct
vcpu_runstate_info *res,
(state_time & XEN_RUNSTATE_UPDATE));
}
+static void xen_get_runstate_snapshot_cpu(struct vcpu_runstate_info *res,
+ unsigned int cpu)
+{
+ int i;
+
+ xen_get_runstate_snapshot_cpu_delta(res, cpu);
+
+ for (i = 0; i < RUNSTATE_max; i++)
+ res->time[i] += per_cpu(old_runstate_time, cpu)[i];
+}
+
+void xen_accumulate_runstate_time(int action)
+{
+ struct vcpu_runstate_info state;
+ int cpu, i;
+
+ switch (action) {
+ case -1: /* backup runstate time before suspend */
+ WARN_ON_ONCE(unlikely(runstate_delta));
+
+ runstate_delta = kcalloc(num_possible_cpus(),
+sizeof(*runstate_delta),
+GFP_KERNEL);
+ if (unlikely(!runstate_delta)) {
+ pr_alert("%s: failed to allocate runstate_delta\n",
+ __func__);
+ return;
+ }
+
+ for_each_possible_cpu(cpu) {
+ xen_get_runstate_snapshot_cpu_delta(&state, cpu);
+ memcpy(runstate_delta[cpu].time, state.time,
+ RUNSTATE_max *
Re: IB/mlx4: Use common error handling code in __mlx4_ib_create_flow()
>>> I mean you aren't really making the code any smaller
>>
>> Would anybody like to check corresponding effects in more detail
>> after a specific function call was replaced by a goto statement?
>
> You are supposed to do it and not "anybody".
I can offer another bit of information for this software development discussion.
The following build settings were active in my “Makefile” for this Linux test
case.
…
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O0
-fomit-frame-pointer -std=gnu89
…
The affected source file can be compiled for the processor architecture “x86_64”
by a tool like “GCC 6.4.1+r251631-1.3” from the software distribution
“openSUSE Tumbleweed” with the following command example.
my_cc=/usr/bin/gcc-6 \
&& my_module=drivers/infiniband/hw/mlx4/main.o \
&& git checkout next-20171009 \
&& make -j4 CC="${my_cc}" HOSTCC="${my_cc}" allmodconfig "${my_module}" \
&& size "${my_module}" \
&& git checkout next_fine-tuning_in_mlx4_1 \
&& make -j4 CC="${my_cc}" HOSTCC="${my_cc}" allmodconfig "${my_module}" \
&& size "${my_module}"
Do you find the following details useful for further clarification?
text: -32
data: 0
bss: 0
Regards,
Markus
Re: [PATCH] Bluetooth: avoid recursive locking in hci_send_to_channel()
Hi Sebastian,
> Mart reported a deadlock in -RT in the call path:
> hci_send_monitor_ctrl_event() -> hci_send_to_channel()
>
> because both functions acquire the same read lock hci_sk_list.lock. This
> is also a mainline issue because the qrwlock implementation is writer
> fair (the traditional rwlock implementation is reader biased).
>
> To avoid the deadlock there is now __hci_send_to_channel() which expects
> the readlock to be held.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Fixes: 38ceaa00d02d ("Bluetooth: Add support for sending MGMT commands and
> events to monitor")
> Reported-by: Mart van de Wege
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> net/bluetooth/hci_sock.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
Re: [PATCH v2 1/3] mtd: spi-nor: stm32-quadspi: Fix uninitialized error return code
thanks Cyrille
indeed, the "Signed-off" on Geert'commit was a mistake
BR
Ludo
On 10/29/2017 06:50 PM, Cyrille Pitchen wrote:
Hi Ludovic,
Le 26/10/2017 à 17:12, Ludovic Barre a écrit :
From: Geert Uytterhoeven
With gcc 4.1.2:
drivers/mtd/spi-nor/stm32-quadspi.c: In function ‘stm32_qspi_tx_poll’:
drivers/mtd/spi-nor/stm32-quadspi.c:230: warning: ‘ret’ may be used
uninitialized in this function
Indeed, if stm32_qspi_cmd.len is zero, ret will be uninitialized.
This length is passed from outside the driver using the
spi_nor.{read,write}{,_reg}() callbacks.
Several functions in drivers/mtd/spi-nor/spi-nor.c (e.g. write_enable(),
write_disable(), and erase_chip()) call spi_nor.write_reg() with a zero
length.
Fix this by returning an explicit zero on success.
Fixes: 0d43d7ab277a048c ("mtd: spi-nor: add driver for STM32 quad spi flash
controller")
Signed-off-by: Geert Uytterhoeven
Acked-by: Ludovic Barre
Signed-off-by: Ludovic Barre
I removed your "Signed-off" because I think this is a mistake but kept
your "Acked-by" tag.
Applied to the spi-nor/next branch of l2-mtd.
Thanks!
---
drivers/mtd/spi-nor/stm32-quadspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/stm32-quadspi.c
b/drivers/mtd/spi-nor/stm32-quadspi.c
index 86c0931..ad6a3e1 100644
--- a/drivers/mtd/spi-nor/stm32-quadspi.c
+++ b/drivers/mtd/spi-nor/stm32-quadspi.c
@@ -240,12 +240,12 @@ static int stm32_qspi_tx_poll(struct stm32_qspi *qspi,
STM32_QSPI_FIFO_TIMEOUT_US);
if (ret) {
dev_err(qspi->dev, "fifo timeout (stat:%#x)\n", sr);
- break;
+ return ret;
}
tx_fifo(buf++, qspi->io_base + QUADSPI_DR);
}
- return ret;
+ return 0;
}
static int stm32_qspi_tx_mm(struct stm32_qspi *qspi,
Re: [PATCH linux-next 1/1] ASoC: rsnd: ssiu: reset SSI_MODE register
Hello Morimoto-san
On 10/30/2017 08:38 AM, Kuninori Morimoto wrote:
Hi Jiada
register SSI_MODE is set when SSI works in TDM Extended or
TDM (Ex-)Split mode, but it isn't reset after SSI stops.
this will cause issue, if SSI starts to work in other modes
which requie SSI_MODE to have different value.
This patch resets SSI_MODE register in .stop callback,
when last stream calls .stop.
Fixes: 186fadc132f0 ("ASoC: rsnd: add TDM Extend Mode support")
Signed-off-by: Jiada Wang
---
sound/soc/sh/rcar/ssiu.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/sh/rcar/ssiu.c b/sound/soc/sh/rcar/ssiu.c
index 4d94875..eff9f3b 100644
--- a/sound/soc/sh/rcar/ssiu.c
+++ b/sound/soc/sh/rcar/ssiu.c
@@ -217,6 +217,8 @@ static int rsnd_ssiu_stop_gen2(struct rsnd_mod *mod,
if (rsnd_ssi_multi_slaves_runtime(io))
rsnd_mod_write(mod, SSI_CONTROL, 0);
+ rsnd_mod_write(mod, SSI_MODE, 0);
+
return 0;
}
Thank you for your patch.
But, I don't want to reset register when stop, because
it might be point-less if SoC has power domain.
How about this or similar (not tested) ?
--
diff --git a/sound/soc/sh/rcar/ssiu.c b/sound/soc/sh/rcar/ssiu.c
index 4d94875..8dc2e92 100644
--- a/sound/soc/sh/rcar/ssiu.c
+++ b/sound/soc/sh/rcar/ssiu.c
@@ -130,14 +130,13 @@ static int rsnd_ssiu_init_gen2(struct rsnd_mod *mod,
if (ret < 0)
return ret;
- if (rsnd_runtime_is_ssi_tdm(io)) {
- /*
-* TDM Extend Mode
-* see
-* rsnd_ssi_config_init()
-*/
- rsnd_mod_write(mod, SSI_MODE, 0x1);
- }
+ /*
+* TDM Extend Mode
+* see
+* rsnd_ssi_config_init()
+*/
+ rsnd_mod_write(mod, SSI_MODE,
+ rsnd_runtime_is_ssi_tdm(io) ? 0x1 : 0x0);
Thanks for your suggestion,
I will do some test for this change,
if it works fine, I will submit ver2 with it
Thanks,
Jiada
if (rsnd_ssi_use_busif(io)) {
rsnd_mod_write(mod, SSI_BUSIF_ADINR,
Best regards
---
Kuninori Morimoto
Re: [PATCH linux-next 1/1] ASoC: rsnd: ssiu: reset SSI_MODE register
Hi Jiada
> > --
> > diff --git a/sound/soc/sh/rcar/ssiu.c b/sound/soc/sh/rcar/ssiu.c
> > index 4d94875..8dc2e92 100644
> > --- a/sound/soc/sh/rcar/ssiu.c
> > +++ b/sound/soc/sh/rcar/ssiu.c
> > @@ -130,14 +130,13 @@ static int rsnd_ssiu_init_gen2(struct rsnd_mod *mod,
> > if (ret < 0)
> > return ret;
> >
> > - if (rsnd_runtime_is_ssi_tdm(io)) {
> > - /*
> > -* TDM Extend Mode
> > -* see
> > -* rsnd_ssi_config_init()
> > -*/
> > - rsnd_mod_write(mod, SSI_MODE, 0x1);
> > - }
> > + /*
> > +* TDM Extend Mode
> > +* see
> > +* rsnd_ssi_config_init()
> > +*/
> > + rsnd_mod_write(mod, SSI_MODE,
> > + rsnd_runtime_is_ssi_tdm(io) ? 0x1 : 0x0);
>
> Thanks for your suggestion,
> I will do some test for this change,
> if it works fine, I will submit ver2 with it
Thanks
Best regards
---
Kuninori Morimoto
Re: [PATCH 10/17] hyper-v: trace vmbus_open()
Greg KH writes: > On Sun, Oct 29, 2017 at 12:21:09PM -0700, k...@exchange.microsoft.com wrote: >> From: Vitaly Kuznetsov >> >> Add tracepoint to CHANNELMSG_OPENCHANNEL sender. >> >> Signed-off-by: Vitaly Kuznetsov >> Signed-off-by: K. Y. Srinivasan >> --- >> drivers/hv/channel.c | 2 ++ >> drivers/hv/hv_trace.h | 27 +++ >> 2 files changed, 29 insertions(+) >> >> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c >> index a406beb10dd0..739b3fe1e0fb 100644 >> --- a/drivers/hv/channel.c >> +++ b/drivers/hv/channel.c >> @@ -185,6 +185,8 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 >> send_ringbuffer_size, >> ret = vmbus_post_msg(open_msg, >> sizeof(struct vmbus_channel_open_channel), true); >> >> +trace_vmbus_open(open_msg, ret); > > Why add tracepoints for things that ftrace can handle automatically? This series adds pretty prints for structures printing what is needed and in the right format significantly simplifying debugging. And it wouldn't make sense to add tracepoints to *some* messages-related functions and skip others where parsing is more trivial. -- Vitaly
Re: net: hns: set correct return value
On 2017-10-29 at 15:35:32 +0100, Pan Bian wrote: > The function of_parse_phandle() returns a NULL pointer if it cannot > resolve a phandle property to a device_node pointer. In function > hns_nic_dev_probe(), its return value is passed to PTR_ERR to extract > the error code. However, in this case, the extracted error code will > always be zero, which is unexpected. > > Signed-off-by: Pan Bian The subject is missing a [PATCH] prefix which causes the patch e.g. to not show up on patchwork [1]. Care to resend with the proper subject? [1] https://patchwork.ozlabs.org/project/netdev/list/ Care to resend with the proper subject? For the patch itself: Reviewed-by: Tobias Klauser
Re: possible deadlock in lru_add_drain_all
[Cc Byungchul. The original full report is http://lkml.kernel.org/r/089e0825eec8955c1f055c83d...@google.com] Could you have a look please? This smells like a false positive to me. On Fri 27-10-17 15:42:34, Michal Hocko wrote: > On Fri 27-10-17 11:44:58, Dmitry Vyukov wrote: > > On Fri, Oct 27, 2017 at 11:34 AM, Michal Hocko wrote: > > > On Fri 27-10-17 02:22:40, syzbot wrote: > > >> Hello, > > >> > > >> syzkaller hit the following crash on > > >> a31cc455c512f3f1dd5f79cac8e29a7c8a617af8 > > >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > > >> compiler: gcc (GCC) 7.1.1 20170620 > > >> .config is attached > > >> Raw console output is attached. > > > > > > I do not see such a commit. My linux-next top is next-20171018 > > > > > > [...] > > >> Chain exists of: > > >> cpu_hotplug_lock.rw_sem --> &pipe->mutex/1 --> > > >> &sb->s_type->i_mutex_key#9 > > >> > > >> Possible unsafe locking scenario: > > >> > > >>CPU0CPU1 > > >> > > >> lock(&sb->s_type->i_mutex_key#9); > > >>lock(&pipe->mutex/1); > > >>lock(&sb->s_type->i_mutex_key#9); > > >> lock(cpu_hotplug_lock.rw_sem); > > > > > > I am quite confused about this report. Where exactly is the deadlock? > > > I do not see where we would get pipe mutex from inside of the hotplug > > > lock. Is it possible this is just a false possitive due to cross release > > > feature? > > > > > > As far as I understand this CPU0/CPU1 scheme works only for simple > > cases with 2 mutexes. This seem to have larger cycle as denoted by > > "the existing dependency chain (in reverse order) is:" section. > > My point was that lru_add_drain_all doesn't take any external locks > other than lru_lock and that one is not anywhere in the chain AFAICS. > > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs
Re: [PATCH] Fix writing mtdoops to nand flash.
Hi Brent, Subject should be prefixed by "mtd: nand: ", so "mtd: nand: Fix writing mtdoops to nand flash" On Sun, 29 Oct 2017 23:23:43 -0500 moto...@gmail.com wrote: > From: Brent Taylor > > When mtdoops calls mtd_panic_write, it eventually calls > panic_nand_write in nand_base.c. In order to properly > wait for the nand chip to be ready in panic_nand_wait, > the chip must first be selected. > > When using the atmel nand flash controller, a panic > would occur due to a NULL pointer exception. > > Signed-off-by: Brent Taylor > --- > drivers/mtd/nand/nand_base.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c > index 12edaae17d81..0a8058a66d93 100644 > --- a/drivers/mtd/nand/nand_base.c > +++ b/drivers/mtd/nand/nand_base.c > @@ -2802,9 +2802,14 @@ static int panic_nand_write(struct mtd_info *mtd, > loff_t to, size_t len, > struct mtd_oob_ops ops; > int ret; > > + int chipnr = (int)(to >> chip->chip_shift); > + chip->select_chip(mtd, chipnr); > + > /* Wait for the device to get ready */ > panic_nand_wait(mtd, chip, 400); > > + chip->select_chip(mtd, -1); > + Duh! Looks like a piece of code that is never tested. Did you face the problem or did you find out by inspecting the code? Anyway, I fear the atmel driver is not the only one to rely on the chip to be selected when ->dev_ready() is called so this should definitely be fixed. Also, we should probably move the ->select_chip() and panic_nand_wait() calls after panic_nand_get_device(), and I don't think we need to unselect the chip (it will be taken care of by nand_do_write_ops()). > /* Grab the device */ > panic_nand_get_device(chip, mtd, FL_WRITING); >
Re: ubi: fastmap: use kmem_cache_free to deallocate memory
On Sun, 29 Oct 2017 20:40:02 +0800
Pan Bian wrote:
> Memory allocated by kmem_cache_alloc() should not be deallocated with
> kfree(). Use kmem_cache_free() instead.
>
> Signed-off-by: Pan Bian
Reviewed-by: Boris Brezillon
Richard, maybe you can add:
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Cc:
> ---
> drivers/mtd/ubi/fastmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c
> index 5a832bc..717db749 100644
> --- a/drivers/mtd/ubi/fastmap.c
> +++ b/drivers/mtd/ubi/fastmap.c
> @@ -1063,7 +1063,7 @@ int ubi_scan_fastmap(struct ubi_device *ubi, struct
> ubi_attach_info *ai,
> e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
> if (!e) {
> while (i--)
> - kfree(fm->e[i]);
> + kmem_cache_free(ubi_wl_entry_slab, fm->e[i]);
>
> ret = -ENOMEM;
> goto free_hdr;
Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply
Neil Armstrong writes:
> Looking at the schematics, the USB Power Supply is shared between the
> two USB interfaces,
> If the usb0 fails to initialize, the second one won't have power.
>
> Fixes: 5a0803bd5ae2 ("ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes")
> Signed-off-by: Neil Armstrong
Applied to v4.15/dt64,
Kevin
Re: [PATCH 0/5] ARM: meson: enable gpio interrupt controller
Jerome Brunet writes: > This patchset enables gpio interrupt controller found on the meson SoC > family. ATM, it supports meson8b, gxbb and gxl. The meson8 has been left > out because I don't have the documentation of this particular SoC. > > The last patch uses the interrupts provided by this controller with the > external ethernet PHY found on a few platforms. > > Jerome Brunet (5): > ARM: meson: enable MESON_IRQ_GPIO in Kconfig for meson8b > ARM64: meson: enable MESON_IRQ_GPIO in Kconfig > ARM: dts: meson8b: enable gpio interrupt controller > ARM64: dts: meson-gx: add gpio interrupt controller > ARM64: dts: meson-gx: add external PHY interrupt on some platforms Applied, Kevin
Re: [PATCH] ubi: fastmap: clean up the initialization of pointer p
On Sun, 29 Oct 2017 13:14:26 +
Colin King wrote:
> From: Colin Ian King
>
> The pointer p is being initialized with one value and a few lines
> later being set to a newer replacement value. Clean up the code by
> using the latter assignment to p as the initial value. Cleans up
> clang warning:
>
> drivers/mtd/ubi/fastmap.c:217:19: warning: Value stored to 'p'
> during its initialization is never read
>
> Signed-off-by: Colin Ian King
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/ubi/fastmap.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c
> index 5a832bc79b1b..9be4b94e83ad 100644
> --- a/drivers/mtd/ubi/fastmap.c
> +++ b/drivers/mtd/ubi/fastmap.c
> @@ -214,9 +214,8 @@ static void assign_aeb_to_av(struct ubi_attach_info *ai,
>struct ubi_ainf_volume *av)
> {
> struct ubi_ainf_peb *tmp_aeb;
> - struct rb_node **p = &ai->volumes.rb_node, *parent = NULL;
> + struct rb_node **p = &av->root.rb_node, *parent = NULL;
>
> - p = &av->root.rb_node;
> while (*p) {
> parent = *p;
>
Re: [PATCH] fs, mm: account filp and names caches to kmemcg
On Fri 27-10-17 13:50:47, Shakeel Butt wrote: > > Why is OOM-disabling a thing? Why isn't this simply a "kill everything > > else before you kill me"? It's crashing the kernel in trying to > > protect a userspace application. How is that not insane? > > In parallel to other discussion, I think we should definitely move > from "completely oom-disabled" semantics to something similar to "kill > me last" semantics. Is there any objection to this idea? Could you be more specific what you mean? -- Michal Hocko SUSE Labs
Re: [PATCH v2] usb: dwc2: host: Don't retry NAKed transactions right away
Hi, Doug Anderson writes: > Hi, > > On Sat, Oct 28, 2017 at 8:51 AM, Stefan Wahren wrote: >> Hi Doug, >> >> [add Felipe since this should go through his tree] > > Ah. Sorry Felipe! I know you've landed some dwc2 stuff in the past No problems :-) > but for some reason get_maintainer didn't ID you so I thought maybe > you weren't doing it anymore. Please let me know if you'd like me to > send this to you again with collected Reviewed-by and Tested-by tags. Yeah, please resend with all tags collected, however let's wait for a week or so and give other people time to catch up. I already sent my pull request to Greg, this would, anyway, go into the -rc cycle. Please add a Cc stable tag too, if necessary. -- balbi signature.asc Description: PGP signature
Re: [PULL REQUEST] i2c-mux for 4.15-rc1
On 2017-10-28 14:25, Wolfram Sang wrote: > >> Right. Blush. I blame the immense flow of patches. I just can't seem to >> keep up... :-) Anyway, thanks for catching this and sorry for making you >> do that. > > No worries. Patchwork makes it easy for me to track patches. Speaking > of, if you register at patchwork.ozlabs.org, then I could assign you the > patches for the mux subsystem. Then you'd have the patches listed. Just > saying... Sounds like a splendid idea. I signed up as 'peda'. Do you need anything else? Cheers, Peter
Re: [RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read
Hi PrasannaKumar,
On Sat, 28 Oct 2017 13:13:51 +0530
PrasannaKumar Muralidharan wrote:
> From: Lars-Peter Clausen
>
> Avoid sending unnecessary READ commands to the chip.
>
> Signed-off-by: Lars-Peter Clausen
> Signed-off-by: PrasannaKumar Muralidharan
> ---
> This patch is taken from git://projects.qi-hardware.com/qi-kernel.git
> branch jz-3.16. From [1] and [2] it can be seen that the patch author
> thinks this can be sent upstream but it never happened so far. This
> patch is used in OpenWRT as seen from [3].
Sounds reasonable, but it's likely to conflict with something I'd like
to queue for 4.16 [1]. I'll rebase this patch on nand/next once the
->exec_op() series is merged. Don't hesitate to ping me if I forget.
Regards,
Boris
[1]http://patchwork.ozlabs.org/project/linux-mtd/list/?series=8923
>
> I have only compile tested the patch.
>
> 1.
> https://www.mail-archive.com/discussion@lists.en.qi-hardware.com/msg04635.html
> 2.
> https://www.mail-archive.com/discussion@lists.en.qi-hardware.com/msg04639.html
> 3.
> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/xburst/patches-3.18/002-NAND-Optimize-NAND_ECC_HW_OOB_FIRST-read.patch;h=046da51912de3cd779df5de13d2c1999719a;hb=c03d4317a6bc891cb4a5e89cbdd77f37c23aff86
>
> drivers/mtd/nand/nand_base.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 12edaae..4bf3bdb 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -1680,9 +1680,15 @@ static int nand_read_page_hwecc_oob_first(struct
> mtd_info *mtd,
> unsigned int max_bitflips = 0;
>
> /* Read the OOB area first */
> - chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> - chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> + if (mtd->writesize > 512) {
> + chip->cmdfunc(mtd, NAND_CMD_READ0, mtd->writesize, page);
> + chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, 0, -1);
> + } else {
> + chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
> + chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> + }
>
> ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
>chip->ecc.total);
> @@ -1902,8 +1908,10 @@ static int nand_do_read_ops(struct mtd_info *mtd,
> loff_t from,
>__func__, buf);
>
> read_retry:
> - if (nand_standard_page_accessors(&chip->ecc))
> + if (nand_standard_page_accessors(&chip->ecc) &&
> + chip->ecc.mode != NAND_ECC_HW_OOB_FIRST) {
> chip->cmdfunc(mtd, NAND_CMD_READ0, 0x00, page);
> + }
>
> /*
>* Now read the page into the buffer. Absent an error,
Re: IB/mlx4: Use common error handling code in __mlx4_ib_create_flow()
On Mon, Oct 30, 2017 at 09:04:36AM +0100, SF Markus Elfring wrote:
> >>> I mean you aren't really making the code any smaller
> >>
> >> Would anybody like to check corresponding effects in more detail
> >> after a specific function call was replaced by a goto statement?
> >
> > You are supposed to do it and not "anybody".
>
> I can offer another bit of information for this software development
> discussion.
>
> The following build settings were active in my “Makefile” for this Linux test
> case.
>
> …
> HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O0
> -fomit-frame-pointer -std=gnu89
> …
>
>
> The affected source file can be compiled for the processor architecture
> “x86_64”
> by a tool like “GCC 6.4.1+r251631-1.3” from the software distribution
> “openSUSE Tumbleweed” with the following command example.
>
> my_cc=/usr/bin/gcc-6 \
> && my_module=drivers/infiniband/hw/mlx4/main.o \
> && git checkout next-20171009 \
> && make -j4 CC="${my_cc}" HOSTCC="${my_cc}" allmodconfig "${my_module}" \
> && size "${my_module}" \
> && git checkout next_fine-tuning_in_mlx4_1 \
> && make -j4 CC="${my_cc}" HOSTCC="${my_cc}" allmodconfig "${my_module}" \
> && size "${my_module}"
>
>
> Do you find the following details useful for further clarification?
Almost, you should compare sizes of mlx4_ib.ko and not
drivers/infiniband/hw/mlx4/main.o.
Thanks
>
> text: -32
> data: 0
> bss: 0
>
> Regards,
> Markus
signature.asc
Description: PGP signature
Re: [PATCH 0/6] [media] omap_vout: Adjustments for three function implementations
Hi Markus, On 09/24/2017 12:20 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 24 Sep 2017 12:06:54 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (6): > Delete an error message for a failed memory allocation in > omap_vout_create_video_devices() > Improve a size determination in two functions > Adjust a null pointer check in two functions > Fix a possible null pointer dereference in omap_vout_open() > Delete an unnecessary variable initialisation in omap_vout_open() > Delete two unnecessary variable initialisations in omap_vout_probe() > > drivers/media/platform/omap/omap_vout.c | 23 ++- > 1 file changed, 10 insertions(+), 13 deletions(-) > While we do not mind cleanup patches, the way you post them (one fix per file) is really annoying and takes us too much time to review. I'll take the "Fix a possible null pointer" patch since it is an actual bug fix, but will reject the others, not just this driver but all of them that are currently pending in our patchwork (https://patchwork.linuxtv.org). Feel free to repost, but only if you organize the patch as either fixing the same type of issue for a whole subdirectory (media/usb, media/pci, etc) or fixing all issues for a single driver. Actual bug fixes (like the null pointer patch in this series) can still be posted as separate patches, but cleanups shouldn't. So in this particular case I would expect two omap_vout patches: one for the bug fix, one for the cleanups. Just so you know, I'll reject any future patch series that do not follow these rules. Just use common sense when posting these things in the future. I would also suggest that your time might be spent more productively if you would work on some more useful projects. There is more than enough to do. However, that's up to you. Regards, Hans
Re: [PULL REQUEST] i2c-mux for 4.15-rc1
> Sounds like a splendid idea. I signed up as 'peda'. Great! > Do you need anything else? Nope, I need to ask Jeremy to add you to the i2c project. Can't do this myself, sadly. Will keep you updated! signature.asc Description: PGP signature
Re: [locking/paravirt] static_key_disable_cpuslocked(): static key 'virt_spin_lock_key+0x0/0x20' used before call to jump_label_init()
On Mon, Oct 30, 2017 at 08:47:08AM +0100, Juergen Gross wrote: On 30/10/17 08:35, Fengguang Wu wrote: On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: Hi Linus, Up to now we see the below boot error/warnings when testing v4.14-rc6. They hit the RC release mainly due to various imperfections in 0day's auto bisection. So I manually list them here and CC the likely easy to debug ones to the corresponding maintainers in the followup emails. boot_successes: 4700 boot_failures: 247 [...] WARNING:at_kernel/jump_label.c:#static_key_disable_cpuslocked: 7 This patch is in the tip tree only, it will be merged in 4.15. So I don't understand why you are reporting this for 4.14-rc6. Ah sorry, I simply checked recent bisects for that warning. Then I'll need to carry out some new bisect on 4.14-rc6. There is a patch by Dou Liyang pending since 28th October addressing that issue: [PATCH tip v2] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init() Excellent! Thanks, Fengguang
Build regressions/improvements in v4.14-rc6
Below is the list of build error/warning regressions/improvements in v4.14-rc6[1] compared to v4.13[2]. Summarized: - build errors: +6/-0 - build warnings: +2016/-1207 JFYI, when comparing v4.14-rc6[1] to v4.14-rc5[3], the summaries are: - build errors: +0/-3 - build warnings: +6060/-1075 Note that there may be false regressions, as some logs are incomplete. Still, they're build errors/warnings. Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/bb176f67090ca54869fc1262c913aa69d2ede070/ (all 270 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/569dbb88e80deb68974ef6fdd6a13edb9d686261/ (267 out of 270 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9/ (all 270 configs) *** ERRORS *** 6 error regressions: + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: 'per_cpu_secondary_mm' undeclared (first use in this function): => 81:10 + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: implicit declaration of function 'per_cpu' [-Werror=implicit-function-declaration]: => 81:2 + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: implicit declaration of function 'smp_processor_id' [-Werror=implicit-function-declaration]: => 79:12 + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: unknown type name 'per_cpu_secondary_mm': => 22:37 + /home/kisskb/slave/src/drivers/net/ethernet/intel/i40e/i40e_ethtool.c: error: implicit declaration of function 'cmpxchg64' [-Werror=implicit-function-declaration]: => 4150:6 + error: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined!: => N/A *** WARNINGS *** [Deleted 925 lines about "warning: ... [-Wpointer-sign]" on parisc-allmodconfig] [Deleted 1477 lines about "warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]" on parisc-allmodconfig] [Deleted 835 lines about "'__f' is static but declared in inline function '...' which is not static [enabled by default]" on i386-randconfig [Deleted 547 lines about ¨warning: "memcpy" ... has no CRC!" on um-allmodconfig 2016 warning regressions: + /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4a/clock-sh7763.c: warning: 'cpg_clk_init' is deprecated (declared at /home/kisskb/slave/src/arch/sh/include/asm/clock.h:11) [-Wdeprecated-declarations]: => 104:2 + /home/kisskb/slave/src/arch/um/os-Linux/skas/process.c: warning: control reaches end of non-void function [-Wreturn-type]: => 613:1 + /home/kisskb/slave/src/crypto/algif_aead.c: warning: 'crypto_aead_copy_sgl' uses dynamic stack allocation [enabled by default]: => 91:1 + /home/kisskb/slave/src/drivers/clk/renesas/clk-sh73a0.c: warning: 'parent_name' may be used uninitialized in this function [-Wuninitialized]: => 155:3 + /home/kisskb/slave/src/drivers/crypto/caam/caamalg_qi.c: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Wformat]: => 672:16, 1062:16, 909:16 + /home/kisskb/slave/src/drivers/infiniband/core/uverbs_std_types.c: warning: 'inbuf' may be used uninitialized in this function [-Wuninitialized]: => 249:2 + /home/kisskb/slave/src/drivers/infiniband/core/uverbs_std_types.c: warning: 'outbuf' may be used uninitialized in this function [-Wuninitialized]: => 249:2 + /home/kisskb/slave/src/drivers/md/dm-crypt.c: warning: 'crypt_iv_lmk_one.isra.28' uses dynamic stack allocation [enabled by default]: => 640:1 + /home/kisskb/slave/src/drivers/md/dm-crypt.c: warning: 'crypt_iv_tcw_whitening.isra.27' uses dynamic stack allocation [enabled by default]: => 787:1 + /home/kisskb/slave/src/drivers/media/pci/ddbridge/ddbridge-io.h: warning: 'return' with a value, in function returning void [enabled by default]: => 55:2, 50:2 + /home/kisskb/slave/src/drivers/mtd/chips/cfi_cmdset_0020.c: warning: the frame size of 1396 bytes is larger than 1280 bytes [-Wframe-larger-than=]: => 603:1 + /home/kisskb/slave/src/drivers/net/tun.c: warning: 'copylen' may be used uninitialized in this function [-Wuninitialized]: => 1471:22 + /home/kisskb/slave/src/drivers/net/tun.c: warning: 'linear' may be used uninitialized in this function [-Wuninitialized]: => 1384:46, 1192:34, 1192:31 + /home/kisskb/slave/src/drivers/scsi/bfa/bfa_fcs_lport.c: warning: the frame size of 1712 bytes is larger than 1280 bytes [-Wframe-larger-than=]: => 2160:1 + /home/kisskb/slave/src/fs/btrfs/backref.c: warning: 'count' may be used uninitialized in this function [-Wuninitialized]: => 799:15 + /home/kisskb/slave/src/include/linux/byteorder/big_endian.h: warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp] AR drivers/clk/renesas/built-in.o: => 7:2 + /home/kisskb/slave/src/include/linux/byteorder/big_endian.h: warning: #warning inconsistent configuration, needs CON
[PATCH] lib: hint GCC to inlilne _find_next_bit() helper
Hi Yury, I've tried your benchmark on x86-64 (haswell). Inlining is a pretty small increase in binary size: 48B (2%). In terms of speed, results are not very stable from one run to another (I've included two runs to give you an idea), but overall there seems to be small improvement on the random-filled bitmap, and not so much on the sparse one. Before (2312B): [ 312.912746] Start testing find_bit() with random-filled bitmap [ 312.919066] find_next_bit: 170226 cycles, 16267 iterations [ 312.924657] find_next_zero_bit: 170826 cycles, 16502 iterations [ 312.930674] find_last_bit: 152900 cycles, 16266 iterations [ 312.938856] find_first_bit: 5335034 cycles, 16267 iterations [ 312.944533] Start testing find_bit() with sparse bitmap [ 312.949780] find_next_bit: 2644 cycles, 66 iterations [ 312.955016] find_next_zero_bit: 320294 cycles, 32703 iterations [ 312.960957] find_last_bit: 2170 cycles, 66 iterations [ 312.966048] find_first_bit: 21704 cycles, 66 iterations [ 515.310376] Start testing find_bit() with random-filled bitmap [ 515.316693] find_next_bit: 164854 cycles, 16350 iterations [ 515.322293] find_next_zero_bit: 173710 cycles, 16419 iterations [ 515.328312] find_last_bit: 155458 cycles, 16350 iterations [ 515.336584] find_first_bit: 5518332 cycles, 16351 iterations [ 515.342272] Start testing find_bit() with sparse bitmap [ 515.347519] find_next_bit: 2538 cycles, 66 iterations [ 515.352763] find_next_zero_bit: 334828 cycles, 32703 iterations [ 515.358703] find_last_bit: 2250 cycles, 66 iterations [ 515.363787] find_first_bit: 23804 cycles, 66 iterations After (2360B): [ 183.844318] Start testing find_bit() with random-filled bitmap [ 183.850588] find_next_bit: 148976 cycles, 16342 iterations [ 183.856186] find_next_zero_bit: 173298 cycles, 16427 iterations [ 183.862202] find_last_bit: 148728 cycles, 16341 iterations [ 183.870404] find_first_bit: 5390470 cycles, 16342 iterations [ 183.876084] Start testing find_bit() with sparse bitmap [ 183.881341] find_next_bit: 2144 cycles, 66 iterations [ 183.886586] find_next_zero_bit: 335558 cycles, 32703 iterations [ 183.892535] find_last_bit: 2376 cycles, 66 iterations [ 183.897627] find_first_bit: 24814 cycles, 66 iterations [ 187.842232] Start testing find_bit() with random-filled bitmap [ 187.848505] find_next_bit: 164512 cycles, 16412 iterations [ 187.854101] find_next_zero_bit: 172770 cycles, 16357 iterations [ 187.860117] find_last_bit: 145050 cycles, 16412 iterations [ 187.868312] find_first_bit: 5374792 cycles, 16413 iterations [ 187.873996] Start testing find_bit() with sparse bitmap [ 187.879251] find_next_bit: 2422 cycles, 66 iterations [ 187.884500] find_next_zero_bit: 342548 cycles, 32703 iterations [ 187.890448] find_last_bit: 2150 cycles, 66 iterations [ 187.895539] find_first_bit: 21830 cycles, 66 iterations
Re: [perf_event_ctx_lock_nested] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
On Mon, Oct 30, 2017 at 12:02:01AM +0100, Fengguang Wu wrote: > The dmesg fragment is > > [ 40.886662] done > [ 40.886686] [ 40.905102] capability: warning: `turbostat' uses 32-bit > capabilities (legacy support in use) > [ 40.940087] IPMI Device Information > [ 41.073351] [ 41.076223] BUG: sleeping function called from invalid > context at kernel/locking/mutex.c:97 > [ 41.076224] in_atomic(): 1, irqs_disabled(): 0, pid: 14, name: watchdog/0 > [ 41.076226] CPU: 0 PID: 14 Comm: watchdog/0 Tainted: G O > 4.8.0-01558-g21f54dd #1 That's not 4.14 or even close. > [ 41.076228] Hardware name: Dell Inc. PowerEdge R630/0CNCJW, BIOS 2.1.7 > 06/16/2016 > [ 41.076231] c91bfd90 813de3b9 882062ab4b80 > 0061 > [ 41.076232] c91bfda8 810a7083 81c6fa60 > c91bfdd0 > [ 41.076233] 810a711a 88206661d4a8 882066037800 > 88206661d4a8 > [ 41.076234] Call Trace: > [ 41.076240] [] dump_stack+0x63/0x8a > [ 41.076246] [] ___might_sleep+0xd3/0x120 > [ 41.076248] [] __might_sleep+0x4a/0x80 > [ 41.076254] [] mutex_lock+0x20/0x50 > [ 41.076256] [] perf_event_ctx_lock_nested+0x52/0xa0 > [ 41.076259] [] perf_event_disable+0xf/0x30 > [ 41.076261] [] watchdog_nmi_disable+0x36/0x70 > [ 41.076263] [] ? smpboot_thread_fn+0x34/0x1f0 > [ 41.076264] [] watchdog_disable+0x4d/0x60 > [ 41.076266] [] smpboot_thread_fn+0x163/0x1f0 > [ 41.076267] [] ? sort_range+0x30/0x30 > [ 41.076269] [] kthread+0xd5/0xf0 > [ 41.076270] [] ? kthread_park+0x60/0x60 > [ 41.076272] [] ret_from_fork+0x25/0x30 I'm not seeing where preemption would be disabled there.. we explicitly call ->park() with preempt enabled.
Re: [locking/paravirt] static_key_disable_cpuslocked(): static key 'virt_spin_lock_key+0x0/0x20' used before call to jump_label_init()
Hi Fengguang, There are two different warning. At 10/30/2017 03:35 PM, Fengguang Wu wrote: On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: Hi Linus, Up to now we see the below boot error/warnings when testing v4.14-rc6. The original warning: WARNING:at_arch/x86/events/intel/core.c:#intel_pmu_handle_irq: 1 in v4.14-rc6, which happens rarely. They hit the RC release mainly due to various imperfections in 0day's auto bisection. So I manually list them here and CC the likely easy to debug ones to the corresponding maintainers in the followup emails. boot_successes: 4700 boot_failures: 247 [...] WARNING:at_kernel/jump_label.c:#static_key_disable_cpuslocked: 7 This is a new warning in tip tree, and the patch has sent[1]. [1]https://lkml.org/lkml/2017/10/28/4 we may need do it in v4.14-rc6, not in tip tree directly. Thanks, dou.
Re: [PATCH 03/14] VFS: Implement a filesystem superblock creation/configuration context [ver #6]
On Fri, Oct 27, 2017 at 6:03 PM, David Howells wrote: > Miklos Szeredi wrote: > >> Yes I did mean vfs_parse_sb_flag_option(). >> >> Yes, I understand its purpose, but it would be cleaner if all the >> option parsing was done in fc->ops->parse_option(). >> >> It might be worth introducing the vfs_parse_sb_flag_option(), to be >> called from ->parse_option(). > > I was trying to relieve the filesystem of the requirement to have to deal with > common stuff and also the need to talk directly to the LSM. No need to talk directly to the LSM: security_fs_context_parse_option() will do that in VFS code. How common is common stuff? dirsync/sync/rw: not handled by all filesystems, those that don't handle it should reject the option on the new interface lazytime: handled by generic code, AFAICS, but makes no sense on read-only fs so those should probably reject it mand: handled by generic code, but does not make sense for some filesystems (e.g. those that don't have all the unixy permission bits). posixacl: there's no such mount option now. The options is "acl" and does not get translated to MS_POSIXACL in mount(8). Makes zero sense to add a previously nonexistent option to the new interface. silent: makes no sense on the new interface, since we should no longer be putting error messages into the kernel log. So that leaves async/ro/nolazytime/nomand options to be handled by all filesystems. Not sure how to best handle these differences, but the current code definitely seems lacking, and I cannot imagine a better way than to pass all options to filesystem's ->parse_option() and add helper(s) to handle the generic options. >> > Btw, how would it affect the LSM? >> >> LSM would have to reject a "reset" if not enough privileges to >> *create* a new fs instance, since it essentially requires creating a >> new config, which is what is done when creating an fs instance. > > That's not what I'm asking. Would the reset change LSM state? Reset security > labels and options? No. And it wouldn't reset any other option that is immutable (e.g. server IP address). Thanks, Miklos
Re: [PATCH 10/17] hyper-v: trace vmbus_open()
On Mon, Oct 30, 2017 at 09:16:19AM +0100, Vitaly Kuznetsov wrote: > Greg KH writes: > > > On Sun, Oct 29, 2017 at 12:21:09PM -0700, k...@exchange.microsoft.com wrote: > >> From: Vitaly Kuznetsov > >> > >> Add tracepoint to CHANNELMSG_OPENCHANNEL sender. > >> > >> Signed-off-by: Vitaly Kuznetsov > >> Signed-off-by: K. Y. Srinivasan > >> --- > >> drivers/hv/channel.c | 2 ++ > >> drivers/hv/hv_trace.h | 27 +++ > >> 2 files changed, 29 insertions(+) > >> > >> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c > >> index a406beb10dd0..739b3fe1e0fb 100644 > >> --- a/drivers/hv/channel.c > >> +++ b/drivers/hv/channel.c > >> @@ -185,6 +185,8 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 > >> send_ringbuffer_size, > >>ret = vmbus_post_msg(open_msg, > >> sizeof(struct vmbus_channel_open_channel), true); > >> > >> + trace_vmbus_open(open_msg, ret); > > > > Why add tracepoints for things that ftrace can handle automatically? > > This series adds pretty prints for structures printing what is needed > and in the right format significantly simplifying debugging. And it > wouldn't make sense to add tracepoints to *some* messages-related > functions and skip others where parsing is more trivial. Tracepoints add memory usage and take up real space. If you don't need them for something, as there are other ways to already get the information needed, why add new ones that you now need to drag around for all time? thanks greg k-h
Re: [PATCH v3 00/13] dax: fix dma vs truncate and remove 'page-less' support
Hi,
On Mon 30-10-17 13:00:23, Dave Chinner wrote:
> On Sun, Oct 29, 2017 at 04:46:44PM -0700, Dan Williams wrote:
> > Coming back to this since Dave has made clear that new locking to
> > coordinate get_user_pages() is a no-go.
> >
> > We can unmap to force new get_user_pages() attempts to block on the
> > per-fs mmap lock, but if punch-hole finds any elevated pages it needs
> > to drop the mmap lock and wait. We need this lock dropped to get
> > around the problem that the driver will not start to drop page
> > references until it has elevated the page references on all the pages
> > in the I/O. If we need to drop the mmap lock that makes it impossible
> > to coordinate this unlock/retry loop within truncate_inode_pages_range
> > which would otherwise be the natural place to land this code.
> >
> > Would it be palatable to unmap and drain dma in any path that needs to
> > detach blocks from an inode? Something like the following that builds
> > on dax_wait_dma() tried to achieve, but does not introduce a new lock
> > for the fs to manage:
> >
> > retry:
> > per_fs_mmap_lock(inode);
> > unmap_mapping_range(mapping, start, end); /* new page references
> > cannot be established */
> > if ((dax_page = dax_dma_busy_page(mapping, start, end)) != NULL) {
> > per_fs_mmap_unlock(inode); /* new page references can happen,
> > so we need to start over */
> > wait_for_page_idle(dax_page);
> > goto retry;
> > }
> > truncate_inode_pages_range(mapping, start, end);
> > per_fs_mmap_unlock(inode);
>
> These retry loops you keep proposing are just bloody horrible. They
> are basically just a method for blocking an operation until whatever
> condition is preventing the invalidation goes away. IMO, that's an
> ugly solution no matter how much lipstick you dress it up with.
>
> i.e. the blocking loops mean the user process is going to be blocked
> for arbitrary lengths of time. That's not a solution, it's just
> passing the buck - now the userspace developers need to work around
> truncate/hole punch being randomly blocked for arbitrary lengths of
> time.
So I see substantial difference between how you and Christoph think this
should be handled. Christoph writes in [1]:
The point is that we need to prohibit long term elevated page counts
with DAX anyway - we can't just let people grab allocated blocks forever
while ignoring file system operations. For stage 1 we'll just need to
fail those, and in the long run they will have to use a mechanism
similar to FL_LAYOUT locks to deal with file system allocation changes.
So Christoph wants to block truncate until references are released, forbid
long term references until userspace acquiring them supports some kind of
lease-breaking. OTOH you suggest truncate should just proceed leaving
blocks allocated until references are released. We cannot have both... I'm
leaning more towards the approach Christoph suggests as it puts the burned
to the place which is causing it - the application having long term
references - and applications needing this should be sufficiently rare that
we don't have to devise a general mechanism in the kernel for this.
If the solution Christoph suggests is acceptable to you, I think we should
first write a patch to forbid acquiring long term references to DAX blocks.
On top of that we can implement mechanism to block truncate while there are
short term references pending (and for that retry loops would be IMHO
acceptable). And then we can work on a mechanism to notify userspace that
it needs to drop references to blocks that are going to be truncated so
that we can re-enable taking of long term references.
Honza
[1]
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1522887.html
--
Jan Kara
SUSE Labs, CR
Re: [PATCH v2] dwc: dra7xx: Print link state to console for debug
On Thursday 26 October 2017 01:29 PM, Faiz Abbas wrote:
> David,
>
> On Thursday 19 October 2017 06:56 PM, David Laight wrote:
>> From: Faiz Abbas
>>> Sent: 19 October 2017 14:09
>>> On Thursday 19 October 2017 06:13 PM, Faiz Abbas wrote:
Enable support for printing the LTSSM link state for debugging PCI
when link is down.
Signed-off-by: Faiz Abbas
---
v2:
1. Changed dev_err() to dev_dbg()
2. Changed static char array to static const char * const
3. format changes
drivers/pci/dwc/pci-dra7xx.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 34427a6..0e70e77 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -98,6 +98,45 @@ struct dra7xx_pcie_of_data {
#define to_dra7xx_pcie(x) dev_get_drvdata((x)->dev)
+static const char * const state[] = {
+ "DETECT_QUIET",
>> ...
+ "RCVRY_EQ3"
+};
+
static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
{
return readl(pcie->base + offset);
@@ -118,6 +157,15 @@ static int dra7xx_pcie_link_up(struct dw_pcie *pci)
{
struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
u32 reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_PHY_CS);
+ u32 cmd_reg;
+ u32 ltssm_state;
+
+ if (!(reg & LINK_UP)) {
+ cmd_reg = dra7xx_pcie_readl(dra7xx,
+ PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+ ltssm_state = (cmd_reg & GENMASK(7, 2)) >> 2;
+ dev_dbg(pci->dev, "Link state:%s\n", state[ltssm_state]);
>>
>> Hmmm... GENMASK leaves by hunting header files...> Why not (cmd_reg >> 2) &
>> 63 and explicitly define state[64]
>> to guarantee that you never print anything worse than a NULL
>> pointer.
>
> I'm not sure what you mean. Are you worried we might print something
> outside the array bounds? How is this easier to decipher than GENMASK?
>
>>
+ }
return !!(reg & LINK_UP);
}
>>>
>>> I missed David's comment in v1. Will submit a new version. Please ignore.
>>
>> I've a 'neat' trick for generating strings that match constants.
>> You can get the compiler to do all the work for you:
>> (Assuming I've typed it correctly)
>>
>> #define LTSSM_DEFS(x) \
>> x(DETECT_QUIET) \
>> x(DETECT_ACT) \
>> (continue for all the names)
>>
>> Define an enum with the named constants:
>> #define X(name) LTSSM_STATE_##name,
>> enum (LTSSM_DEFS(X) LTSSM_STATE_SIZE=64);
>> #undef X
>>
>> Array of strings:
>> #define X(name) [LTSSM_STATE_##name] = #name
>> static const char * const state_names[LTSSM_STATE_SIZE] = { LTSSM_DEFS(X) };
>> #undef X
>>
>> David
>>
>
> So I implemented your idea and it looks like this:
> http://pastebin.ubuntu.com/25821834/
>
> I don't know how much we gained by adding the trick. I still had to be
> careful not to be off by 1 when writing the list. Plus we are never
> saying anything like printk("%s", state[LTSSM_STATE_DETECT_QUIET]. Its a
> register read which is used to index the list array.
>
> Thanks,
> Faiz
>
Gentle Ping.
Re: IB/mlx4: Use common error handling code in __mlx4_ib_create_flow()
>> Do you find the following details useful for further clarification? > > Almost, you should compare sizes of mlx4_ib.ko and not > drivers/infiniband/hw/mlx4/main.o. text: -32 data: 0 bss: 0 The determined difference is the same finally. Regards, Markus
[PATCH] net: hns: set correct return value
The function of_parse_phandle() returns a NULL pointer if it cannot
resolve a phandle property to a device_node pointer. In function
hns_nic_dev_probe(), its return value is passed to PTR_ERR to extract
the error code. However, in this case, the extracted error code will
always be zero, which is unexpected.
Signed-off-by: Pan Bian
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 3652063..e771926 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -2369,8 +2369,8 @@ static int hns_nic_dev_probe(struct platform_device *pdev)
priv->enet_ver = AE_VERSION_2;
ae_node = of_parse_phandle(dev->of_node, "ae-handle", 0);
- if (IS_ERR_OR_NULL(ae_node)) {
- ret = PTR_ERR(ae_node);
+ if (!ae_node) {
+ ret = -ENODEV;
dev_err(dev, "not find ae-handle\n");
goto out_read_prop_fail;
}
--
1.9.1
Re: [PATCH v2] pids: introduce find_get_task_by_vpid helper
On Sat, Oct 28, 2017 at 4:52 AM, Mike Rapoport wrote: > There are several functions that do find_task_by_vpid() followed by > get_task_struct(). We can use a helper function instead. > > Signed-off-by: Mike Rapoport > --- I did a quick grep and found other similar patterns in kernel/events/core.c, kernel/kcmp.c kernel/sys.c , kernel/time/posix-cpu-timers.c, arch/x86/kernel/cpu/intel_rdt_rdtgroup.c, security/yama/yama_lsm.c, mm/process_vm_access.c, mm/mempolicy.c and arch/ia64/kernel/perfmon.c Balbir Singh.
Re: [PATCH] usb: musb_core: mark expected switch fall-through
On Fri, Oct 27, 2017 at 11:56:14AM -0500, Bin Liu wrote: > On Fri, Oct 27, 2017 at 06:49:49PM +0200, Greg Kroah-Hartman wrote: > > On Fri, Oct 27, 2017 at 11:44:47AM -0500, Bin Liu wrote: > > > Hi, > > > > > > On Mon, Oct 23, 2017 at 10:10:43PM -0500, Gustavo A. R. Silva wrote: > > > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > > > > where we are expecting to fall through. > > > > > > > > Addresses-Coverity-ID: 1397608 > > > > Signed-off-by: Gustavo A. R. Silva > > > > > > Applied with the above Coverity-ID message removed. > > > > Why? It's good to track these things. > > hmm, I thought we don't want non-kernel related information in the commit > message. This is kernel-related information. We don't want foolish "Id:" lines, from gerrit instances, as they are no help at all because we can not do anything with them. We _do_ want identifiers that are globally unique that provide real information, like public bugzilla ids, and tools like coverity. So for things like this, always keep them on. I've added it back by hand now. thanks, greg k-h
Re: [PATCH] usb: musb: Convert timers to use timer_setup()
On Fri, Oct 27, 2017 at 11:24:22AM -0500, Bin Liu wrote:
> Hi,
>
> On Tue, Oct 24, 2017 at 03:08:35AM -0700, Kees Cook wrote:
> > In preparation for unconditionally passing the struct timer_list pointer to
> > all timer callbacks, switch to using the new timer_setup() and from_timer()
> > to pass the timer pointer explicitly.
> >
> > Instead of a per-device static timer variable, a spare timer "dev_timer"
> > is added to the musb structure for devices to use for their per-device
> > timer.
> >
> > Cc: Bin Liu
> > Cc: Greg Kroah-Hartman
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Kees Cook
> > ---
> > drivers/usb/musb/am35x.c | 24 +++-
> > drivers/usb/musb/blackfin.c | 13 ++---
> > drivers/usb/musb/blackfin.h | 2 --
> > drivers/usb/musb/da8xx.c | 26 --
> > drivers/usb/musb/davinci.c | 20 +---
> > drivers/usb/musb/musb_core.c | 6 +++---
> > drivers/usb/musb/musb_core.h | 1 +
> > drivers/usb/musb/musb_dsps.c | 7 ---
> > drivers/usb/musb/tusb6010.c | 20 +---
> > 9 files changed, 55 insertions(+), 64 deletions(-)
>
> [snip]
>
> > diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> > index 20f4614178d9..e8573975743d 100644
> > --- a/drivers/usb/musb/musb_core.h
> > +++ b/drivers/usb/musb/musb_core.h
> > @@ -345,6 +345,7 @@ struct musb {
> > struct list_headpending_list; /* pending work list */
> >
> > struct timer_list otg_timer;
> > + struct timer_list dev_timer;
>
> Now since dev_timer is added in struct musb for glue drivers,
>
> > struct notifier_block nb;
> >
> > struct dma_controller *dma_controller;
> > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> > index f6b526606ad1..e3d0e626a5d6 100644
> > --- a/drivers/usb/musb/musb_dsps.c
> > +++ b/drivers/usb/musb/musb_dsps.c
> > @@ -282,9 +282,10 @@ static int dsps_check_status(struct musb *musb, void
> > *unused)
> > return 0;
> > }
> >
> > -static void otg_timer(unsigned long _musb)
> > +static void otg_timer(struct timer_list *t)
> > {
> > - struct musb *musb = (void *)_musb;
> > + struct dsps_glue *glue = from_timer(glue, t, timer);
> > + struct musb *musb = platform_get_drvdata(glue->musb);
> > struct device *dev = musb->controller;
> > unsigned long flags;
> > int err;
> > @@ -480,7 +481,7 @@ static int dsps_musb_init(struct musb *musb)
> > }
> > }
> >
> > - setup_timer(&glue->timer, otg_timer, (unsigned long) musb);
> > + timer_setup(&glue->timer, otg_timer, 0);
>
> this glue->timer is duplicate. It can be removed and use musb->dev_timer
> instead as other glue drivers do.
I do not understand your review comments at all. Can you do the fixup
here to use timer_setup for the musb timer code?
thanks,
greg k-h
Re: [perf_event_ctx_lock_nested] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
On Mon, Oct 30, 2017 at 09:42:25AM +0100, Peter Zijlstra wrote: On Mon, Oct 30, 2017 at 12:02:01AM +0100, Fengguang Wu wrote: The dmesg fragment is [ 40.886662] done [ 40.886686] [ 40.905102] capability: warning: `turbostat' uses 32-bit capabilities (legacy support in use) [ 40.940087] IPMI Device Information [ 41.073351] [ 41.076223] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97 [ 41.076224] in_atomic(): 1, irqs_disabled(): 0, pid: 14, name: watchdog/0 [ 41.076226] CPU: 0 PID: 14 Comm: watchdog/0 Tainted: G O 4.8.0-01558-g21f54dd #1 That's not 4.14 or even close. Yeah sorry -- it looks like a 0day bug. So the robot stores dmesg files to the wrong commit dir, which made me believe they are all RC6 bugs. Sorry for the noises! Regards, Fengguang
Re: [PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment
On Fri, Oct 27, 2017 at 02:44:37PM +, Bogdan Purcareata wrote: > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Friday, October 27, 2017 5:30 PM > > To: Bogdan Purcareata > > Cc: Ruxandra Ioana Radulescu ; > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > de...@driverdev.osuosl.org > > Subject: Re: [PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment > > > > On Fri, Oct 27, 2017 at 02:11:35PM +, Bogdan Purcareata wrote: > > > @@ -93,10 +100,10 @@ > > > * buffers large enough to allow building an skb around them and also > > account > > > * for alignment restrictions > > > */ > > > -#define DPAA2_ETH_BUF_RAW_SIZE \ > > > +#define DPAA2_ETH_BUF_RAW_SIZE(priv) \ > > > (DPAA2_ETH_RX_BUF_SIZE + \ > > > SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) + \ > > > - DPAA2_ETH_RX_BUF_ALIGN) > > > + (priv)->rx_buf_align) > > > > > > > Not related to this patch, but this macro is ugly. It would be better > > as function. > > Okay, will change the macros to inline functions in v2, where applicable. > You didn't need to do that, because I said it was "not related to this change". I try not to make people redo paches for stuff like this. But thanks, it looks nicer now. regards, dan carpenter
Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters
adding qemu devel and add Daniel and Erik from libvirt to keep them in the loop. On 10/29/2017 12:11 PM, Cornelia Huck wrote: > On Fri, 13 Oct 2017 13:38:45 -0400 > Tony Krowiak wrote: > >> Tony Krowiak (19): >> KVM: s390: SIE considerations for AP Queue virtualization >> KVM: s390: refactor crypto initialization >> s390/zcrypt: new AP matrix bus >> s390/zcrypt: create an AP matrix device on the AP matrix bus >> s390/zcrypt: base implementation of AP matrix device driver >> s390/zcrypt: register matrix device with VFIO mediated device >> framework >> KVM: s390: introduce AP matrix configuration interface >> s390/zcrypt: support for assigning adapters to matrix mdev >> s390/zcrypt: validate adapter assignment >> s390/zcrypt: sysfs interfaces supporting AP domain assignment >> s390/zcrypt: validate domain assignment >> s390/zcrypt: sysfs support for control domain assignment >> s390/zcrypt: validate control domain assignment >> KVM: s390: Connect the AP mediated matrix device to KVM >> s390/zcrypt: introduce ioctl access to VFIO AP Matrix driver >> KVM: s390: interface to configure KVM guest's AP matrix >> KVM: s390: validate input to AP matrix config interface >> KVM: s390: New ioctl to configure KVM guest's AP matrix >> s390/facilities: enable AP facilities needed by guest > > I'll try to summarize all of this in my own words, both to make sure I > understand the design correctly and to give others a different view on > this. > > [I'm completely disregarding control domains here.] > > On s390, we have cryptographic coprocessor cards, which are modeled on > Linux as devices on the AP bus. There's also a concept called domains, > which means an individual queue of a crypto device is basically a > (card,domain) tuple. We model this something like the following > (assuming we have access to cards 3 and 4 and domains 1 and 2): > > AP -> card3 -> queue (3,1) > -> queue (3,2) >-> card4 -> queue (4,1) > -> queue (4,2) > > (The AP bus is a bit different for backwards compat.) > > If we want to virtualize this, we can use a feature provided by the > hardware. We basically attach a satellite control block to our main > hardware virtualization control block and the hardware takes care of > (mostly) everything. > > For this control block, we don't specify explicit tuples, but a list of > cards and a list of domains. The guest will get access to the cross > product. > > Because of this, we need to take care that the lists provided to > different guests don't overlap; i.e., we need to enforce sane > configurations. Otherwise, one guest may get access to things like > secret keys for another guest. > > The idea of this patch set is to introduce a new device, the matrix > device. This matrix device hangs off a different root and acts as the > node where mdev devices hang off. > > If you now want to give the tuples (4,1) and (4,2), you need to do the > following: > > - Unbind the (4,1) and (4,2) tuples from their ap bus driver. > - Bind the (4,1) and (4,2) tuples to the ap matrix driver. > - Create the mediated device. > - Assign card 4 and domains 1 and 2. > > QEMU will now simply consume the mediated device and things should work. > This is probably the shortest possible summary I can imagine. Tony can you double check if it matches your understanding as well?
Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
Mimi Zohar wrote: > Yes, that works. Thanks! Remember is_ima_appraise_enabled() is > dependent on the "ima: require secure_boot rules in lockdown mode" > patch - http://kernsec.org/pipermail/linux-security-module-archive/201 > 7-October/003910.html. What happens if the file in question is being accessed from a filesystem that doesn't have xattrs and doesn't provide support for appraisal? Is it rejected outright or just permitted? David
Re: [PATCH v7 10/10] lib/dlock-list: Fix use-after-unlock problem in dlist_for_each_entry_safe()
On Fri 27-10-17 16:10:53, Waiman Long wrote:
> The dlist_for_each_entry_safe() macro in include/linux/dlock-list has
> a use-after-unlock problem where racing condition can happen because
> of a lack of spinlock protection. Fortunately, this macro is not
> currently being used in the kernel.
>
> This patch changes the dlist_for_each_entry_safe() macro so that the
> call to __dlock_list_next_list() is deferred until the next entry is
> being used. That should eliminate the use-after-unlock problem.
>
> Reported-by: Boqun Feng
> Signed-off-by: Waiman Long
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> include/linux/dlock-list.h | 28 +---
> 1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/dlock-list.h b/include/linux/dlock-list.h
> index 02c5f4d..f4b7657 100644
> --- a/include/linux/dlock-list.h
> +++ b/include/linux/dlock-list.h
> @@ -191,17 +191,17 @@ extern void dlock_list_add(struct dlock_list_node *node,
> }
>
> /**
> - * dlock_list_first_entry - get the first element from a list
> + * dlock_list_next_list_entry - get first element from next list in iterator
> * @iter : The dlock list iterator.
> - * @type : The type of the struct this is embedded in.
> + * @pos : A variable of the struct that is embedded in.
> * @member: The name of the dlock_list_node within the struct.
> - * Return : Pointer to the next entry or NULL if all the entries are
> iterated.
> + * Return : Pointer to first entry or NULL if all the lists are iterated.
> */
> -#define dlock_list_first_entry(iter, type, member) \
> +#define dlock_list_next_list_entry(iter, pos, member)
> \
> ({ \
> struct dlock_list_node *_n; \
> _n = __dlock_list_next_entry(NULL, iter); \
> - _n ? list_entry(_n, type, member) : NULL; \
> + _n ? list_entry(_n, typeof(*pos), member) : NULL; \
> })
>
> /**
> @@ -231,7 +231,7 @@ extern void dlock_list_add(struct dlock_list_node *node,
> * This iteration function is designed to be used in a while loop.
> */
> #define dlist_for_each_entry(pos, iter, member)
> \
> - for (pos = dlock_list_first_entry(iter, typeof(*(pos)), member);\
> + for (pos = dlock_list_next_list_entry(iter, pos, member); \
>pos != NULL; \
>pos = dlock_list_next_entry(pos, iter, member))
>
> @@ -245,14 +245,20 @@ extern void dlock_list_add(struct dlock_list_node *node,
> * This iteration macro is safe with respect to list entry removal.
> * However, it cannot correctly iterate newly added entries right after the
> * current one.
> + *
> + * The call to __dlock_list_next_list() is deferred until the next entry
> + * is being iterated to avoid use-after-unlock problem.
> */
> #define dlist_for_each_entry_safe(pos, n, iter, member)
> \
> - for (pos = dlock_list_first_entry(iter, typeof(*(pos)), member);\
> + for (pos = NULL;\
> ({ \
> - bool _b = (pos != NULL);\
> - if (_b) \
> - n = dlock_list_next_entry(pos, iter, member); \
> - _b; \
> + if (!pos || \
> +(&(pos)->member.list == &(iter)->entry->list)) \
> + pos = dlock_list_next_list_entry(iter, pos, \
> + member); \
> + if (pos)\
> + n = list_next_entry(pos, member.list); \
> + pos;\
> }); \
> pos = n)
>
> --
> 1.8.3.1
>
>
--
Jan Kara
SUSE Labs, CR
RE: system hung up when offlining CPUs
> -Original Message- > From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, October 17, 2017 1:57 AM > To: YASUAKI ISHIMATSU > Cc: Kashyap Desai; Hannes Reinecke; Marc Zyngier; Christoph Hellwig; > ax...@kernel.dk; m...@ellerman.id.au; keith.bu...@intel.com; > pet...@infradead.org; LKML; linux-s...@vger.kernel.org; Sumit Saxena; > Shivasharan Srikanteshwara > Subject: Re: system hung up when offlining CPUs > > Yasuaki, > > On Mon, 16 Oct 2017, YASUAKI ISHIMATSU wrote: > > > Hi Thomas, > > > > > Can you please apply the patch below on top of Linus tree and retest? > > > > > > Please send me the outputs I asked you to provide last time in any > > > case (success or fail). > > > > The issue still occurs even if I applied your patch to linux 4.14.0-rc4. > > Thanks for testing. > > > --- > > [ ...] INFO: task setroubleshootd:4972 blocked for more than 120 seconds. > > [ ...] Not tainted 4.14.0-rc4.thomas.with.irqdebug+ #6 > > [ ...] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this > message. > > [ ...] setroubleshootd D0 4972 1 0x0080 > > [ ...] Call Trace: > > [ ...] __schedule+0x28d/0x890 > > [ ...] ? release_pages+0x16f/0x3f0 > > [ ...] schedule+0x36/0x80 > > [ ...] io_schedule+0x16/0x40 > > [ ...] wait_on_page_bit+0x107/0x150 > > [ ...] ? page_cache_tree_insert+0xb0/0xb0 [ ...] > > truncate_inode_pages_range+0x3dd/0x7d0 > > [ ...] ? schedule_hrtimeout_range_clock+0xad/0x140 > > [ ...] ? remove_wait_queue+0x59/0x60 > > [ ...] ? down_write+0x12/0x40 > > [ ...] ? unmap_mapping_range+0x75/0x130 [ ...] > > truncate_pagecache+0x47/0x60 [ ...] truncate_setsize+0x32/0x40 [ ...] > > xfs_setattr_size+0x100/0x300 [xfs] [ ...] > > xfs_vn_setattr_size+0x40/0x90 [xfs] [ ...] xfs_vn_setattr+0x87/0xa0 > > [xfs] [ ...] notify_change+0x266/0x440 [ ...] do_truncate+0x75/0xc0 > > [ ...] path_openat+0xaba/0x13b0 [ ...] ? > > mem_cgroup_commit_charge+0x31/0x130 > > [ ...] do_filp_open+0x91/0x100 > > [ ...] ? __alloc_fd+0x46/0x170 > > [ ...] do_sys_open+0x124/0x210 > > [ ...] SyS_open+0x1e/0x20 > > [ ...] do_syscall_64+0x67/0x1b0 > > [ ...] entry_SYSCALL64_slow_path+0x25/0x25 > > This is definitely a driver issue. The driver requests an affinity managed > interrupt. Affinity managed interrupts are different from non managed > interrupts in several ways: > > Non-Managed interrupts: > > 1) At setup time the default interrupt affinity is assigned to each > interrupt. The effective affinity is usually a subset of the online > CPUs. > > 2) User space can modify the affinity of the interrupt > > 3) If a CPU in the affinity mask goes offline and there are still online > CPUs in the affinity mask then the effective affinity is moved to a > subset of the online CPUs in the affinity mask. > > If the last CPU in the affinity mask of an interrupt goes offline then > the hotplug code breaks the affinity and makes it affine to the online > CPUs. The effective affinity is a subset of the new affinity setting, > > Managed interrupts: > > 1) At setup time the interrupts of a multiqueue device are evenly spread > over the possible CPUs. If all CPUs in the affinity mask of a given > interrupt are offline at request_irq() time, the interrupt stays shut > down. If the first CPU in the affinity mask comes online later the > interrupt is started up. > > 2) User space cannot modify the affinity of the interrupt > > 3) If a CPU in the affinity mask goes offline and there are still online > CPUs in the affinity mask then the effective affinity is moved a subset > of the online CPUs in the affinity mask. I.e. the same as with > Non-Managed interrupts. > > If the last CPU in the affinity mask of a managed interrupt goes > offline then the interrupt is shutdown. If the first CPU in the > affinity mask becomes online again then the interrupt is started up > again. > Hi Thomas, Thanks for the detailed explanation about the behavior of managed interrupts. This helped me to understand the issue better. This is first time I am checking CPU hotplug system, so my input is very preliminary. Please bear with my understanding and correct me where required. This issue is reproducible on our local setup as well, with managed interrupts. I have few queries on the requirements for device driver that you have mentioned. In managed-interrupts case, interrupts which were affine to the offlined CPU is not getting migrated to another available CPU. But the documentation at below link says that "all interrupts" are migrated to a new CPU. So not all interrupts are getting migrated to a new CPU then. https://www.kernel.org/doc/html/v4.11/core-api/cpu_hotplug.html#the-offlin e-case "- All interrupts targeted to this CPU are migrated to a new CPU" > So this has consequences: > > 1) The device driver has to make sure that no requests are targeted at a > queue whose interrupt is affine to offline CPUs and therefor shut
Re: [PATCH RFC] random: fix syzkaller fuzzer test int overflow
On Mon, Oct 30, 2017 at 08:39:56AM +0100, Greg KH wrote: > > No "Reported-by:"? Good point, fixed in my tree. - Ted
Re: [PATCH v2] mm: mlock: remove lru_add_drain_all()
On 10/20/2017 12:25 AM, Shakeel Butt wrote: > lru_add_drain_all() is not required by mlock() and it will drain > everything that has been cached at the time mlock is called. And > that is not really related to the memory which will be faulted in > (and cached) and mlocked by the syscall itself. > > Without lru_add_drain_all() the mlocked pages can remain on pagevecs > and be moved to evictable LRUs. However they will eventually be moved > back to unevictable LRU by reclaim. So, we can safely remove > lru_add_drain_all() from mlock syscall. Also there is no need for > local lru_add_drain() as it will be called deep inside __mm_populate() > (in follow_page_pte()). > > On larger machines the overhead of lru_add_drain_all() in mlock() can > be significant when mlocking data already in memory. We have observed > high latency in mlock() due to lru_add_drain_all() when the users > were mlocking in memory tmpfs files. > > Signed-off-by: Shakeel Butt Acked-by: Vlastimil Babka > --- > Changelog since v1: > - updated commit message > > mm/mlock.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/mm/mlock.c b/mm/mlock.c > index dfc6f1912176..3ceb2935d1e0 100644 > --- a/mm/mlock.c > +++ b/mm/mlock.c > @@ -669,8 +669,6 @@ static __must_check int do_mlock(unsigned long start, > size_t len, vm_flags_t fla > if (!can_do_mlock()) > return -EPERM; > > - lru_add_drain_all();/* flush pagevec */ > - > len = PAGE_ALIGN(len + (offset_in_page(start))); > start &= PAGE_MASK; > > @@ -797,9 +795,6 @@ SYSCALL_DEFINE1(mlockall, int, flags) > if (!can_do_mlock()) > return -EPERM; > > - if (flags & MCL_CURRENT) > - lru_add_drain_all();/* flush pagevec */ > - > lock_limit = rlimit(RLIMIT_MEMLOCK); > lock_limit >>= PAGE_SHIFT; > >
RE: [PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment
> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Monday, October 30, 2017 10:56 AM > To: Bogdan Purcareata > Cc: de...@driverdev.osuosl.org; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer alignment > > On Fri, Oct 27, 2017 at 02:44:37PM +, Bogdan Purcareata wrote: > > > -Original Message- > > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > > Sent: Friday, October 27, 2017 5:30 PM > > > To: Bogdan Purcareata > > > Cc: Ruxandra Ioana Radulescu ; > > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > > de...@driverdev.osuosl.org > > > Subject: Re: [PATCH 4/5] staging: fsl-dpaa2/eth: Change RX buffer > > > alignment > > > > > > On Fri, Oct 27, 2017 at 02:11:35PM +, Bogdan Purcareata wrote: > > > > @@ -93,10 +100,10 @@ > > > > * buffers large enough to allow building an skb around them and also > > > account > > > > * for alignment restrictions > > > > */ > > > > -#define DPAA2_ETH_BUF_RAW_SIZE \ > > > > +#define DPAA2_ETH_BUF_RAW_SIZE(priv) \ > > > > (DPAA2_ETH_RX_BUF_SIZE + \ > > > > SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) + \ > > > > - DPAA2_ETH_RX_BUF_ALIGN) > > > > + (priv)->rx_buf_align) > > > > > > > > > > Not related to this patch, but this macro is ugly. It would be better > > > as function. > > > > Okay, will change the macros to inline functions in v2, where applicable. > > > > You didn't need to do that, because I said it was "not related to this > change". I try not to make people redo paches for stuff like this. But > thanks, it looks nicer now. I agree with you, it does look better with inline functions. I know the change wasn't absolutely necessary, but the code is easier on the eyes in v2, so I thought it was good enough reason to go for it. Thanks for the feedback! :) Bogdan P.
Re: Adjustments for a lot of function implementations
> While we do not mind cleanup patches, the way you post them (one fix per file) I find it safer in this way while I was browsing through the landscape of Linux software components. > is really annoying and takes us too much time to review. It is just the case that there are so many remaining open issues. > I'll take the "Fix a possible null pointer" patch since it is an actual bug > fix, Thanks for a bit of change acceptance. > but will reject the others, not just this driver but all of them that are > currently > pending in our patchwork (https://patchwork.linuxtv.org). Will any chances evolve to integrate 146 patches in any other combination? > Feel free to repost, but only if you organize the patch as either fixing the > same type of > issue for a whole subdirectory (media/usb, media/pci, etc) Can we achieve an agreement on the shown change patterns? Is a consensus possible for involved update candidates? > or fixing all issues for a single driver. I find that I did this already. > Actual bug fixes (like the null pointer patch in this series) can still be > posted as > separate patches, but cleanups shouldn't. I got an other software development opinion. > Just so you know, I'll reject any future patch series that do not follow > these rules. > Just use common sense when posting these things in the future. Do we need to try any additional communication tools out? > I would also suggest that your time might be spent more productively if you > would > work on some more useful projects. I hope that various change possibilities (from my selection) will become useful for more Linux users. How will the clarification evolve further? Regards, Markus
Re: [PATCH] drivers/firmware: psci_checker: Add missing destroy_timer_on_stack()
On Tue, Oct 24, 2017 at 5:02 PM, Lorenzo Pieralisi
wrote:
> The PSCI checker suspend_test_thread() function (ie executed for the
> suspend test) requires an on-stack timer to carry out the test it
> executes; it sets it up through the setup_timer_on_stack() API.
>
> setup_timer_on_stack() requires its counterpart destroy_timer_on_stack()
> to be called when the timer is disposed of but the PSCI checker code is
> currently missing that call, leaving the timer object in an incosistent
> state when the PSCI checker stops the thread executing the suspend
> test.
>
> Add the missing destroy_timer_on_stack() call to fix the omission.
>
> Fixes: ea8b1c4a6019 ("drivers: psci: PSCI checker module")
> Signed-off-by: Lorenzo Pieralisi
> Reported-by: Kees Cook
> Cc: Kees Cook
> Cc: Mark Rutland
Hi Lorenzo,
You addressed the patch 'To: a...@kernel.org', but I'm not entirely
sure what to do with it, it would be nice to be a little more explicit whether
you want us to apply the patch directly or just review it, and which trees
you want it to get merged into.
As you are fixing a regression against v4.10, I would assume you want
it merged into v4.14 with a 'cc: stable' tag to have it backported into v4.13,
correct?
Arnd
Re: [PATCH v3 2/2] watchdog: Add Spreadtrum watchdog driver
Hi Guenter,
(There are some problem with Eric's email, he can not receive this
email, so I help to reply his comments following yours. sorry for
troubles.)
+#define SPRD_WDT_MAX_TIMEOUT 60
>>>
>>>
>>> Is that really the maximum supported timeout ? Seems a bit low.
>>> Shouldn't it be something like (U32_MAX / SPRD_WDT_CNT_STEP) ?
>>>
>>
>> It supports the max value like as U32_MAX/SPRD_WDT_CNT_STEP,
>> but it doesn't unnecessary to support so big value, if the system can not
>> response it in 60s, the watchdog could trigger timeout.
>>
> It is customary to provide the highest possible value here.
> No one is forced to set such high values. You are making a choice for
> others here. But, sure, if you insist; not worth arguing about.
Eric said 60s is better for us, thanks for your patient explanation.
>
+
+#define SPRD_WDT_CNT_HIGH_VALUE16
>>>
>>>
>>> Maybe name it "SPRD_WDT_CNT_HIGH_SHIFT". It is not really a value,
>>> it is a shift.
>>>
>>
>> Yes, you are right, _SHIFT will be better.
>>
+#define SPRD_WDT_LOW_VALUE_MASKGENMASK(15, 0)
+#define SPRD_WDT_CNT_VALUE_MAX GENMASK(31, 0)
>>>
>>>
>>> Does this mask serve a useful purpose ?
>>>
>>
>> OK, I will remove it, thanks!
>>
+#define SPRD_WDT_LOAD_TIMEOUT 1000
+
+struct sprd_wdt {
+ void __iomem *base;
+ struct watchdog_device wdd;
+ struct clk *enable;
+ struct clk *rtc_enable;
+ unsigned int irq;
+};
+
+static inline struct sprd_wdt *to_sprd_wdt(struct watchdog_device *wdd)
+{
+ return container_of(wdd, struct sprd_wdt, wdd);
+}
+
+static inline void sprd_wdt_lock(void __iomem *addr)
+{
+ writel_relaxed(0x0, addr + SPRD_WDT_LOCK);
+}
+
+static inline void sprd_wdt_unlock(void __iomem *addr)
+{
+ writel_relaxed(SPRD_WDT_UNLOCK_KEY, addr + SPRD_WDT_LOCK);
+}
+
+static inline bool sprd_wdt_is_running(struct sprd_wdt *wdt)
+{
+ u32 val;
+
+ val = readl_relaxed(wdt->base + SPRD_WDT_CTRL);
+ return val & SPRD_WDT_NEW_VER_EN;
+}
+
+static irqreturn_t sprd_wdt_isr(int irq, void *dev_id)
+{
+ struct sprd_wdt *wdt = (struct sprd_wdt *)dev_id;
+
+ sprd_wdt_unlock(wdt->base);
+ writel_relaxed(SPRD_WDT_INT_CLEAR_BIT, wdt->base +
SPRD_WDT_INT_CLR);
+ sprd_wdt_lock(wdt->base);
+ watchdog_notify_pretimeout(&wdt->wdd);
+ return IRQ_HANDLED;
+}
+
+static u32 sprd_wdt_get_cnt_value(struct sprd_wdt *wdt)
+{
+ u32 val;
+
+ val = readl_relaxed(wdt->base + SPRD_WDT_CNT_HIGH) <<
+ SPRD_WDT_CNT_HIGH_VALUE;
+ val |= readl_relaxed(wdt->base + SPRD_WDT_CNT_LOW) &
+ SPRD_WDT_LOW_VALUE_MASK;
+
+ return val;
+}
+
+static int sprd_wdt_load_value(struct sprd_wdt *wdt, u32 timeout,
+ u32 pretimeout)
+{
+ u32 val, delay_cnt = 0;
+ u32 tmr_step = timeout * SPRD_WDT_CNT_STEP;
+ u32 prtmr_step = pretimeout * SPRD_WDT_CNT_STEP;
+
+ sprd_wdt_unlock(wdt->base);
+ writel_relaxed((tmr_step >> SPRD_WDT_CNT_HIGH_VALUE) &
+ SPRD_WDT_LOW_VALUE_MASK, wdt->base +
SPRD_WDT_LOAD_HIGH);
+ writel_relaxed((tmr_step & SPRD_WDT_LOW_VALUE_MASK),
+ wdt->base + SPRD_WDT_LOAD_LOW);
+ writel_relaxed((prtmr_step >> SPRD_WDT_CNT_HIGH_VALUE) &
+ SPRD_WDT_LOW_VALUE_MASK,
+ wdt->base + SPRD_WDT_IRQ_LOAD_HIGH);
+ writel_relaxed(prtmr_step & SPRD_WDT_LOW_VALUE_MASK,
+ wdt->base + SPRD_WDT_IRQ_LOAD_LOW);
+ sprd_wdt_lock(wdt->base);
+
+ /*
+* Waiting the load value operation done,
+* it needs two or three RTC clock cycles.
+*/
+ do {
+ val = readl_relaxed(wdt->base + SPRD_WDT_INT_RAW);
+ if (!(val & SPRD_WDT_LD_BUSY_BIT))
+ break;
+
+ cpu_relax();
+ } while (delay_cnt++ < SPRD_WDT_LOAD_TIMEOUT);
+
+ if (delay_cnt >= SPRD_WDT_LOAD_TIMEOUT)
+ return -EBUSY;
+ return 0;
+}
+
+static int sprd_wdt_enable(struct sprd_wdt *wdt)
+{
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(wdt->enable);
+ if (ret)
+ return ret;
+ ret = clk_prepare_enable(wdt->rtc_enable);
+ if (ret)
+ return ret;
+
+ sprd_wdt_unlock(wdt->base);
+ val = readl_relaxed(wdt->base + SPRD_WDT_CTRL);
>>
Re: [PATCH RFC 3/5] cpufreq: schedutil: Use idle_calls counter of the remote CPU
On 28-10-17, 02:59, Joel Fernandes wrote:
> Since the recent remote cpufreq callback work, its possible that a cpufreq
> update is triggered from a remote CPU. For single policies however, the
> current
> code uses the local CPU when trying to determine if the remote sg_cpu entered
> idle or is busy. This is incorrect. To remedy this, compare with the nohz tick
> idle_calls counter of the remote CPU.
>
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Frederic Weisbecker
> Cc: Thomas Gleixner
Fixes: 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")
> Signed-off-by: Joel Fernandes
> ---
> include/linux/tick.h | 1 +
> kernel/sched/cpufreq_schedutil.c | 2 +-
> kernel/time/tick-sched.c | 13 +
> 3 files changed, 15 insertions(+), 1 deletion(-)
Acked-by: Viresh Kumar
--
viresh
Re: [pgtable_trans_huge_withdraw] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
On Mon, Oct 30, 2017 at 12:37:01AM +0100, Fengguang Wu wrote: > CC MM people. > > On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: > > Hi Linus, > > > > Up to now we see the below boot error/warnings when testing v4.14-rc6. > > > > They hit the RC release mainly due to various imperfections in 0day's > > auto bisection. So I manually list them here and CC the likely easy to > > debug ones to the corresponding maintainers in the followup emails. > > > > boot_successes: 4700 > > boot_failures: 247 > > > > BUG:kernel_hang_in_test_stage: 152 > > BUG:kernel_reboot-without-warning_in_test_stage: 10 > > BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c: > > 1 > > BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c: > > 3 > > BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c: 21 > > BUG:soft_lockup-CPU##stuck_for#s: 1 > > BUG:unable_to_handle_kernel: 13 > > Here is the call trace: > > [ 956.669197] [ 956.670421] stress-ng: fail: [27945] stress-ng-numa: > get_mempolicy: errno=22 (Invalid argument) Can you also share how you run stress-ng? Is it reproducible? -- Kirill A. Shutemov
Re: [f2fs-dev] [PATCH 2/2] f2fs: relax EIO injection for quota file
On 10/28, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2017/10/23 0:51, Jaegeuk Kim wrote:
> > On 10/22, Chao Yu wrote:
> >> On 2017/10/20 0:56, Jaegeuk Kim wrote:
> >>> This case is not happening easily.
> >>
> >> Actually it can happen, so why not just keep it?
> >
> > Okay, so let me keep this patch for local stress tests only.
>
> May I ask which type and rate of fault injection you are using for
> test now?
I select random value between 3000 and 5000, and 255 for type.
Thanks,
>
> Thanks,
>
> >
> > Thanks,
> >
> >
> >>
> >> Thanks,
> >>
> >>>
> >>> Signed-off-by: Jaegeuk Kim
> >>> ---
> >>> fs/f2fs/f2fs.h | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >>> index e0ef31cb2cc6..6301ccca 100644
> >>> --- a/fs/f2fs/f2fs.h
> >>> +++ b/fs/f2fs/f2fs.h
> >>> @@ -1544,7 +1544,7 @@ static inline int inc_valid_block_count(struct
> >>> f2fs_sb_info *sbi,
> >>> return ret;
> >>>
> >>> #ifdef CONFIG_F2FS_FAULT_INJECTION
> >>> - if (time_to_inject(sbi, FAULT_BLOCK)) {
> >>> + if (!IS_NOQUOTA(inode) && time_to_inject(sbi, FAULT_BLOCK)) {
> >>> f2fs_show_injection_info(FAULT_BLOCK);
> >>> release = *count;
> >>> goto enospc;
> >>>
> >
> > .
> >
Re: [GIT PULL] ARM: uniphier: fixes for v4.14
On Fri, Oct 20, 2017 at 7:16 PM, Masahiro Yamada wrote: > Hi Arnd, Olof, > > Please pull small fixes of ARM UniPhier DT. > It turned out one clock was missing that is actually > necessary for EHCI nodes. Pulled into fixes, thanks! Arnd
Re: [PATCH RFC 4/5] sched/fair: Correct obsolete comment about cpufreq_update_util
You have prefixed most of the Cc'd names with "Cc: " somehow :) On 28-10-17, 02:59, Joel Fernandes wrote: > Since the remote cpufreq callback work, the cpufreq_update_util call can > happen > from remote CPUs. The comment about local CPUs is thus obsolete. Update it > accordingly. We normally keep the column width as 72 in commit logs instead of 80, as with 'git log' this is indented by a tab and then we would cross 80 columns. > Cc: Viresh Kumar > Cc: Rafael J. Wysocki > Cc: Ingo Molnar > Cc: Peter Zijlstra > Signed-off-by: Joel Fernandes > --- > kernel/sched/fair.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 4c06e52935d3..5c49fdb4c508 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -3018,9 +3018,7 @@ static inline void cfs_rq_util_change(struct cfs_rq > *cfs_rq) > /* >* There are a few boundary cases this might miss but it should >* get called often enough that that should (hopefully) not be > - * a real problem -- added to that it only calls on the local > - * CPU, so if we enqueue remotely we'll miss an update, but > - * the next tick/schedule should update. > + * a real problem. >* >* It will not get called when we go idle, because the idle >* thread is a different class (!fair), nor will the utilization Reviewed-by: Viresh Kumar -- viresh
Re: [PATCH] mtd: cfi_cmdset_0002: fix Cypress S29GL flash erase suspend
Hi Chen,
On Thu, 14 Sep 2017 21:58:11 +0800
Chen Bin wrote:
> On UBIFS, Cypress S29GL01GT flash is failed to access occasionally
> , and throw below error information and call trace:
> MTD get_chip(): chip not ready after erase suspend
> UBI error: ubi_io_write: error -5 while writing 512 bytes to
> PEB 932:36992, written 0 bytes
> Call Trace: [jiffies: 0x1ad9b]
> [] dump_stack+0x8/0x34
> [] ubi_io_write+0x52c/0x670
> [] ubi_eba_write_leb+0xd8/0x758
> [] ubifs_leb_write+0xd0/0x178
> [] ubifs_wbuf_write_nolock+0x430/0x798
> [] ubifs_jnl_write_data+0x1e4/0x348
> [] do_writepage+0xc8/0x258
> [] __writepage+0x18/0x78
> [] write_cache_pages+0x1e0/0x4c8
> [] generic_writepages+0x40/0x78
> [] __writeback_single_inode+0x58/0x370
> [] writeback_sb_inodes+0x2e4/0x498
> [] __writeback_inodes_wb+0xc0/0x118
> [] wb_writeback+0x234/0x3c0
> [] wb_do_writeback+0x230/0x2b0
> [] bdi_writeback_workfn+0x84/0x268
> [] process_one_work+0x180/0x4d0
> [] worker_thread+0x158/0x420
> [] kthread+0xa8/0xb0
> [] ret_from_kernel_thread+0x10/0x18
>
> After issue erase suspend command, flash don't go to ready state,
> and fail to access consequently.
> In Cypress S29GL01GT/S29GL512T flash datasheet, the type value of
> Erase Resume to next Erase suspend(tERS) is 100 µs.
> If Erase Suspend followed Erase Resume without enough delay time,
> Erase Suspend would fail to work.
> 500 μs is chosen because it works well and the latency is acceptable.
>
> Signed-off-by: Chen Bin
> ---
> drivers/mtd/chips/cfi_cmdset_0002.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
> b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 56aa6b7..c7d18ec 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -513,6 +513,22 @@ static void cfi_fixup_m29ew_delay_after_resume(struct
> cfi_private *cfi)
> cfi_udelay(500);
> }
>
> +static void cfi_fixup_delay_after_resume(struct cfi_private *cfi)
> +{
> + cfi_fixup_m29ew_delay_after_resume(cfi);
Can we move the content of cfi_fixup_m29ew_delay_after_resume()
directly in this function?
> +
> + /*
> + * For Cypress S29GL01GT/S29GL512T flash, the type value of
> + * Erase Resume to next Erase suspend(tERS) is 100 µs.
> + * If Erase Suspend followed Erase Resume without enough delay time,
> + * Erase Suspend would fail to work.
> + * 500 μs is chosen because it works well and the latency
> + * is acceptable.
> + */
> + if (cfi->mfr == CFI_MFR_AMD && (cfi->id == 0x2801 || cfi->id == 0x2301))
> + cfi_udelay(500);
> +}
> +
> struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
> {
> struct cfi_private *cfi = map->fldrv_priv;
> @@ -890,7 +906,7 @@ static void put_chip(struct map_info *map, struct flchip
> *chip, unsigned long ad
> cfi_fixup_m29ew_erase_suspend(map,
> chip->in_progress_block_addr);
> map_write(map, cfi->sector_erase_cmd,
> chip->in_progress_block_addr);
> - cfi_fixup_m29ew_delay_after_resume(cfi);
> + cfi_fixup_delay_after_resume(cfi);
> chip->oldstate = FL_READY;
> chip->state = FL_ERASING;
> break;
Re: [pgtable_trans_huge_withdraw] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
Hi Kirill, On Mon, Oct 30, 2017 at 12:19:40PM +0300, Kirill A. Shutemov wrote: On Mon, Oct 30, 2017 at 12:37:01AM +0100, Fengguang Wu wrote: CC MM people. On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote: > Hi Linus, > > Up to now we see the below boot error/warnings when testing v4.14-rc6. > > They hit the RC release mainly due to various imperfections in 0day's > auto bisection. So I manually list them here and CC the likely easy to > debug ones to the corresponding maintainers in the followup emails. > > boot_successes: 4700 > boot_failures: 247 > > BUG:kernel_hang_in_test_stage: 152 > BUG:kernel_reboot-without-warning_in_test_stage: 10 > BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c: 1 > BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/rwsem.c: 3 > BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c: 21 > BUG:soft_lockup-CPU##stuck_for#s: 1 > BUG:unable_to_handle_kernel: 13 Here is the call trace: [ 956.669197] [ 956.670421] stress-ng: fail: [27945] stress-ng-numa: get_mempolicy: errno=22 (Invalid argument) Can you also share how you run stress-ng? Is it reproducible? The command line is stress-ng --class cpu --sequential $(nproc) --timeout 1 --times --verify --metrics-brief The test box is model: Broadwell-EP nr_cpu: 88 memory: 128G It shows up 4 times in 6 test runs: /result/stress-ng/60s-cpu-performance/lkp-bdw-ep6/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/bb176f67090ca54869fc1262c913aa69d2ede070/matrix.json "dmesg.BUG:unable_to_handle_kernel": [ 0, 1, 1, 1, 0, 1 ], Thanks, Fengguang
Re: [PATCH] net: hns: set correct return value
On 2017-10-30 at 09:50:01 +0100, Pan Bian wrote: > The function of_parse_phandle() returns a NULL pointer if it cannot > resolve a phandle property to a device_node pointer. In function > hns_nic_dev_probe(), its return value is passed to PTR_ERR to extract > the error code. However, in this case, the extracted error code will > always be zero, which is unexpected. > > Signed-off-by: Pan Bian Reviewed-by: Tobias Klauser
Re: [f2fs-dev] [PATCH] f2fs: add a function to move nid
On 10/28, Chao Yu wrote:
> On 2017/10/28 19:03, Fan Li wrote:
> > This patch add a new function to move nid from one state to another.
> > Move operation is heavily used, by adding a new function for it
> > we can cut down some branches from several flow.
> >
> >
> > Signed-off-by: Fan li
> > ---
> > fs/f2fs/node.c | 51 ++-
> > 1 file changed, 30 insertions(+), 21 deletions(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index ac629d6..8116b50
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1763,15 +1763,13 @@ static struct free_nid
> > *__lookup_free_nid_list(struct f2fs_nm_info *nm_i,
> > }
> >
> > static int __insert_free_nid(struct f2fs_sb_info *sbi,
> > - struct free_nid *i, enum nid_state state, bool new)
> > + struct free_nid *i, enum nid_state state)
> > {
> > struct f2fs_nm_info *nm_i = NM_I(sbi);
> >
> > - if (new) {
> > - int err = radix_tree_insert(&nm_i->free_nid_root, i->nid, i);
> > - if (err)
> > - return err;
> > - }
> > + int err = radix_tree_insert(&nm_i->free_nid_root, i->nid, i);
> > + if (err)
> > + return err;
> >
> > f2fs_bug_on(sbi, state != i->state);
> > nm_i->nid_cnt[state]++;
> > @@ -1781,7 +1779,7 @@ static int __insert_free_nid(struct f2fs_sb_info *sbi,
> > }
> >
> > static void __remove_free_nid(struct f2fs_sb_info *sbi,
> > - struct free_nid *i, enum nid_state state, bool reuse)
> > + struct free_nid *i, enum nid_state state)
> > {
> > struct f2fs_nm_info *nm_i = NM_I(sbi);
> >
> > @@ -1789,8 +1787,23 @@ static void __remove_free_nid(struct f2fs_sb_info
> > *sbi,
> > nm_i->nid_cnt[state]--;
> > if (state == FREE_NID)
> > list_del(&i->list);
> > - if (!reuse)
> > - radix_tree_delete(&nm_i->free_nid_root, i->nid);
> > + radix_tree_delete(&nm_i->free_nid_root, i->nid);
> > +}
> > +
> > +static void __move_free_nid(struct f2fs_sb_info *sbi, struct free_nid *i,
> > + enum nid_state org_state, enum nid_state dst_state)
> > +{
> > + struct f2fs_nm_info *nm_i = NM_I(sbi);
> > +
> > + f2fs_bug_on(sbi, org_state != i->state);
> > + i->state = dst_state;
> > + nm_i->nid_cnt[org_state]--;
> > + nm_i->nid_cnt[dst_state]++;
> > +
> > + if (org_state == FREE_NID)
>
> Welcome back to community, Fan. :)
>
> Minor, how about "if (dst_stat == PREALLOC_NID)" ?
How about this?
switch (dst_state) {
case PREALLOC_NID:
list_del(&i->list);
break;
case FREE_NID:
list_add_tail(&i->list, &nm_i->free_nid_list);
break;
default:
BUG_ON(1);
};
>
> Otherwise this patch looks good to me, anyway, you can add:
>
> Reviewed-by: Chao Yu
>
> Thanks,
>
> > + list_del(&i->list);
> > + else if (dst_state == FREE_NID)
> > + list_add_tail(&i->list, &nm_i->free_nid_list);
> > }
> >
> > /* return if the nid is recognized as free */
> > @@ -1850,7 +1863,7 @@ static bool add_free_nid(struct f2fs_sb_info *sbi,
> > nid_t nid, bool build)
> > }
> > }
> > ret = true;
> > - err = __insert_free_nid(sbi, i, FREE_NID, true);
> > + err = __insert_free_nid(sbi, i, FREE_NID);
> > err_out:
> > spin_unlock(&nm_i->nid_list_lock);
> > radix_tree_preload_end();
> > @@ -1869,7 +1882,7 @@ static void remove_free_nid(struct f2fs_sb_info *sbi,
> > nid_t nid)
> > spin_lock(&nm_i->nid_list_lock);
> > i = __lookup_free_nid_list(nm_i, nid);
> > if (i && i->state == FREE_NID) {
> > - __remove_free_nid(sbi, i, FREE_NID, false);
> > + __remove_free_nid(sbi, i, FREE_NID);
> > need_free = true;
> > }
> > spin_unlock(&nm_i->nid_list_lock);
> > @@ -2080,9 +2093,7 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid)
> > struct free_nid, list);
> > *nid = i->nid;
> >
> > - __remove_free_nid(sbi, i, FREE_NID, true);
> > - i->state = PREALLOC_NID;
> > - __insert_free_nid(sbi, i, PREALLOC_NID, false);
> > + __move_free_nid(sbi, i, FREE_NID, PREALLOC_NID);
> > nm_i->available_nids--;
> >
> > update_free_nid_bitmap(sbi, *nid, false, false);
> > @@ -2108,7 +2119,7 @@ void alloc_nid_done(struct f2fs_sb_info *sbi, nid_t
> > nid)
> > spin_lock(&nm_i->nid_list_lock);
> > i = __lookup_free_nid_list(nm_i, nid);
> > f2fs_bug_on(sbi, !i);
> > - __remove_free_nid(sbi, i, PREALLOC_NID, false);
> > + __remove_free_nid(sbi, i, PREALLOC_NID);
> > spin_unlock(&nm_i->nid_list_lock);
> >
> > kmem_cache_free(free_nid_slab, i);
> > @@ -2131,12 +2142,10 @@ void alloc_nid_failed(struct f2fs_sb_info *sbi,
> > nid_t nid)
> > f2fs_bug_on(sbi, !i);
> >
> > if (!available_free_memory(sbi, FREE_NIDS)) {
> > -
Re: [PATCH v3 2/2] watchdog: Add Spreadtrum watchdog driver
On 10/30/2017 02:18 AM, Baolin Wang wrote:
Hi Guenter,
(There are some problem with Eric's email, he can not receive this
email, so I help to reply his comments following yours. sorry for
troubles.)
+#define SPRD_WDT_MAX_TIMEOUT 60
Is that really the maximum supported timeout ? Seems a bit low.
Shouldn't it be something like (U32_MAX / SPRD_WDT_CNT_STEP) ?
It supports the max value like as U32_MAX/SPRD_WDT_CNT_STEP,
but it doesn't unnecessary to support so big value, if the system can not
response it in 60s, the watchdog could trigger timeout.
It is customary to provide the highest possible value here.
No one is forced to set such high values. You are making a choice for
others here. But, sure, if you insist; not worth arguing about.
Eric said 60s is better for us, thanks for your patient explanation.
+
+#define SPRD_WDT_CNT_HIGH_VALUE16
Maybe name it "SPRD_WDT_CNT_HIGH_SHIFT". It is not really a value,
it is a shift.
Yes, you are right, _SHIFT will be better.
+#define SPRD_WDT_LOW_VALUE_MASKGENMASK(15, 0)
+#define SPRD_WDT_CNT_VALUE_MAX GENMASK(31, 0)
Does this mask serve a useful purpose ?
OK, I will remove it, thanks!
+#define SPRD_WDT_LOAD_TIMEOUT 1000
+
+struct sprd_wdt {
+ void __iomem *base;
+ struct watchdog_device wdd;
+ struct clk *enable;
+ struct clk *rtc_enable;
+ unsigned int irq;
+};
+
+static inline struct sprd_wdt *to_sprd_wdt(struct watchdog_device *wdd)
+{
+ return container_of(wdd, struct sprd_wdt, wdd);
+}
+
+static inline void sprd_wdt_lock(void __iomem *addr)
+{
+ writel_relaxed(0x0, addr + SPRD_WDT_LOCK);
+}
+
+static inline void sprd_wdt_unlock(void __iomem *addr)
+{
+ writel_relaxed(SPRD_WDT_UNLOCK_KEY, addr + SPRD_WDT_LOCK);
+}
+
+static inline bool sprd_wdt_is_running(struct sprd_wdt *wdt)
+{
+ u32 val;
+
+ val = readl_relaxed(wdt->base + SPRD_WDT_CTRL);
+ return val & SPRD_WDT_NEW_VER_EN;
+}
+
+static irqreturn_t sprd_wdt_isr(int irq, void *dev_id)
+{
+ struct sprd_wdt *wdt = (struct sprd_wdt *)dev_id;
+
+ sprd_wdt_unlock(wdt->base);
+ writel_relaxed(SPRD_WDT_INT_CLEAR_BIT, wdt->base +
SPRD_WDT_INT_CLR);
+ sprd_wdt_lock(wdt->base);
+ watchdog_notify_pretimeout(&wdt->wdd);
+ return IRQ_HANDLED;
+}
+
+static u32 sprd_wdt_get_cnt_value(struct sprd_wdt *wdt)
+{
+ u32 val;
+
+ val = readl_relaxed(wdt->base + SPRD_WDT_CNT_HIGH) <<
+ SPRD_WDT_CNT_HIGH_VALUE;
+ val |= readl_relaxed(wdt->base + SPRD_WDT_CNT_LOW) &
+ SPRD_WDT_LOW_VALUE_MASK;
+
+ return val;
+}
+
+static int sprd_wdt_load_value(struct sprd_wdt *wdt, u32 timeout,
+ u32 pretimeout)
+{
+ u32 val, delay_cnt = 0;
+ u32 tmr_step = timeout * SPRD_WDT_CNT_STEP;
+ u32 prtmr_step = pretimeout * SPRD_WDT_CNT_STEP;
+
+ sprd_wdt_unlock(wdt->base);
+ writel_relaxed((tmr_step >> SPRD_WDT_CNT_HIGH_VALUE) &
+ SPRD_WDT_LOW_VALUE_MASK, wdt->base +
SPRD_WDT_LOAD_HIGH);
+ writel_relaxed((tmr_step & SPRD_WDT_LOW_VALUE_MASK),
+ wdt->base + SPRD_WDT_LOAD_LOW);
+ writel_relaxed((prtmr_step >> SPRD_WDT_CNT_HIGH_VALUE) &
+ SPRD_WDT_LOW_VALUE_MASK,
+ wdt->base + SPRD_WDT_IRQ_LOAD_HIGH);
+ writel_relaxed(prtmr_step & SPRD_WDT_LOW_VALUE_MASK,
+ wdt->base + SPRD_WDT_IRQ_LOAD_LOW);
+ sprd_wdt_lock(wdt->base);
+
+ /*
+* Waiting the load value operation done,
+* it needs two or three RTC clock cycles.
+*/
+ do {
+ val = readl_relaxed(wdt->base + SPRD_WDT_INT_RAW);
+ if (!(val & SPRD_WDT_LD_BUSY_BIT))
+ break;
+
+ cpu_relax();
+ } while (delay_cnt++ < SPRD_WDT_LOAD_TIMEOUT);
+
+ if (delay_cnt >= SPRD_WDT_LOAD_TIMEOUT)
+ return -EBUSY;
+ return 0;
+}
+
+static int sprd_wdt_enable(struct sprd_wdt *wdt)
+{
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(wdt->enable);
+ if (ret)
+ return ret;
+ ret = clk_prepare_enable(wdt->rtc_enable);
+ if (ret)
+ return ret;
+
+ sprd_wdt_unlock(wdt->base);
+ val = readl_relaxed(wdt->base + SPRD_WDT_CTRL);
+ val |= SPRD_WDT_NEW_VER_EN;
+ writel_relaxed(val, wdt->base + SPRD_WDT_CTRL);
+ sprd_wdt_lock(wdt->base);
+ return 0;
+}
+
+static void sprd_wdt_disable(struct sprd_wdt *wdt)
+{
+ sprd_wdt_unlock(wdt->base);
+ writel_relaxed(0x0, wdt->base + SPRD_WDT_CTRL);
+ sprd_wdt_lock(wdt->base);
+
+ clk_disable_unprepare(wdt->rtc_enable);
+ clk_disable_unprepare(wdt->enable);
+}
+
+static int sprd_wdt_start(struct watchdog_device *wdd)
+{
+ struct sprd_wdt *wdt = to_sprd_wdt(wdd);
+ u32 val;
+ int ret;
+
+ ret = sprd_wd
Re: [PATCH v2] ARM: dts: exynos: add cpu perf counters to Exynos54xx boards
Hi,
Can I get feedback on this last patch?
Thanks,
Marian
Either I've been missing something or nothing has been going on. (K. E. Gordon)
On Tue, Oct 24, 2017 at 12:59 PM, memeka wrote:
> Enable support for ARM Performance Monitoring Units available in Cortex-A7
> and Cortex-A15 CPU cores for Exynos54xx SoCs (5410, 5420 and 5422/5800).
>
> The PMUs interrupts are defined in the common exynos54xx.dtsi device tree,
> but the PMUs are enabled and have their interrupt CPU affinity defined
> next to each SoC's cpus node.
>
> Tested with perf on Odroid XU4 (Exynos5422):
> armv7_cortex_a7 PMU driver: 5 counters available
> armv7_cortex_a15 PMU driver: 7 counters available
>
> Suggested-by: Marek Szyprowski
> Signed-off-by: Marian Mihailescu
> Signed-off-by: Willy Wolff
>
> ---
> Changes since v1:
> - both Cortex-A7 and Cortex-A15 PMUs are now defined in exynos54xx.dtsi
> - CPU affinity is defined for each SoC *after* the cpus node entry
> - PMUs are disabled in exynos54xx.dtsi and enabled for each SoC
> - cpus labels have been fixed in the interrupt-affinity property for
>Exynos5410 and Exynos5420 SoCs
>
> ---
> arch/arm/boot/dts/exynos5410.dtsi | 8
> arch/arm/boot/dts/exynos5420-cpus.dtsi | 16
> arch/arm/boot/dts/exynos5422-cpus.dtsi | 16
> arch/arm/boot/dts/exynos54xx.dtsi | 20
> 4 files changed, 60 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5410.dtsi
> b/arch/arm/boot/dts/exynos5410.dtsi
> index 7eab4bc..f42b04b 100644
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@ -428,4 +428,12 @@
> samsung,syscon-phandle = <&pmu_system_controller>;
> };
>
> +&arm_a15_pmu {
> + interrupt-affinity = <&cpu0>,
> + <&cpu1>,
> + <&cpu2>,
> + <&cpu3>;
> + status = "okay";
> +};
> +
> #include "exynos5410-pinctrl.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> index 5c052d7..518b7d8 100644
> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> @@ -124,3 +124,19 @@
> };
> };
> };
> +
> +&arm_a7_pmu {
> + interrupt-affinity = <&cpu4>,
> + <&cpu5>,
> + <&cpu4>,
> + <&cpu5>;
> + status = "okay";
> +};
> +
> +&arm_a15_pmu {
> + interrupt-affinity = <&cpu0>,
> + <&cpu1>,
> + <&cpu2>,
> + <&cpu3>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi
> b/arch/arm/boot/dts/exynos5422-cpus.dtsi
> index ab4c718..92676be 100644
> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
> @@ -131,3 +131,19 @@
> };
> };
> };
> +
> +&arm_a7_pmu {
> + interrupt-affinity = <&cpu0>,
> + <&cpu1>,
> + <&cpu2>,
> + <&cpu3>;
> + status = "okay";
> +};
> +
> +&arm_a15_pmu {
> + interrupt-affinity = <&cpu4>,
> + <&cpu5>,
> + <&cpu6>,
> + <&cpu7>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
> b/arch/arm/boot/dts/exynos54xx.dtsi
> index 8ca4fef..f0bd27d 100644
> --- a/arch/arm/boot/dts/exynos54xx.dtsi
> +++ b/arch/arm/boot/dts/exynos54xx.dtsi
> @@ -79,6 +79,26 @@
> interrupts = ;
> };
>
> + arm_a7_pmu: arm-a7-pmu {
> + compatible = "arm,cortex-a7-pmu";
> + interrupt-parent = <&gic>;
> + interrupts = ,
> + ,
> + ,
> + ;
> + status = "disabled";
> + };
> +
> + arm_a15_pmu: arm-a15-pmu {
> + compatible = "arm,cortex-a15-pmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <1 2>,
> + <7 0>,
> + <16 6>,
> + <19 2>;
> + status = "disabled";
> + };
> +
> sss: sss@1083 {
> compatible = "samsung,exynos4210-secss";
> reg = <0x1083 0x300>;
> --
> 2.7.4
>
[PATCH 2/2] usb: ohci-platform: use reset array API
Generic drivers like this need to control arbitrary numbers of reset
lines. Instead of hard-coding the maximum number of resets, use the
reset array API. It can manage a bunch of resets behind the scene.
Signed-off-by: Masahiro Yamada
---
drivers/usb/host/ohci-platform.c | 37 ++---
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 61fe2b9..cb7e190 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -34,12 +34,11 @@
#define DRIVER_DESC "OHCI generic platform driver"
#define OHCI_MAX_CLKS 3
-#define OHCI_MAX_RESETS 2
#define hcd_to_ohci_priv(h) ((struct ohci_platform_priv *)hcd_to_ohci(h)->priv)
struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
- struct reset_control *resets[OHCI_MAX_RESETS];
+ struct reset_control *resets;
struct phy **phys;
int num_phys;
};
@@ -119,7 +118,7 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
- int err, irq, phy_num, clk = 0, rst = 0;
+ int err, irq, phy_num, clk = 0;
if (usb_disabled())
return -ENODEV;
@@ -204,21 +203,15 @@ static int ohci_platform_probe(struct platform_device
*dev)
break;
}
}
- for (rst = 0; rst < OHCI_MAX_RESETS; rst++) {
- priv->resets[rst] =
- devm_reset_control_get_shared_by_index(
- &dev->dev, rst);
- if (IS_ERR(priv->resets[rst])) {
- err = PTR_ERR(priv->resets[rst]);
- if (err == -EPROBE_DEFER)
- goto err_reset;
- priv->resets[rst] = NULL;
- break;
- }
- err = reset_control_deassert(priv->resets[rst]);
- if (err)
- goto err_reset;
- }
+
+ priv->resets = devm_reset_control_array_get_optional_shared(
+ &dev->dev);
+ if (IS_ERR(priv->resets))
+ return PTR_ERR(priv->resets);
+
+ err = reset_control_deassert(priv->resets);
+ if (err)
+ goto err_put_clks;
}
if (pdata->big_endian_desc)
@@ -279,8 +272,7 @@ static int ohci_platform_probe(struct platform_device *dev)
pdata->power_off(dev);
err_reset:
pm_runtime_disable(&dev->dev);
- while (--rst >= 0)
- reset_control_assert(priv->resets[rst]);
+ reset_control_assert(priv->resets);
err_put_clks:
while (--clk >= 0)
clk_put(priv->clks[clk]);
@@ -298,7 +290,7 @@ static int ohci_platform_remove(struct platform_device *dev)
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
- int clk, rst;
+ int clk;
pm_runtime_get_sync(&dev->dev);
usb_remove_hcd(hcd);
@@ -306,8 +298,7 @@ static int ohci_platform_remove(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
- for (rst = 0; rst < OHCI_MAX_RESETS && priv->resets[rst]; rst++)
- reset_control_assert(priv->resets[rst]);
+ reset_control_assert(priv->resets);
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[clk]);
--
2.7.4
[PATCH 1/2] usb: ehci-platform: use reset array API
Generic drivers like this need to control arbitrary numbers of reset
lines. Instead of hard-coding the maximum number of resets, use the
reset array API. It can manage a bunch of resets behind the scene.
Signed-off-by: Masahiro Yamada
---
drivers/usb/host/ehci-platform.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index f1908ea..64fd643 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -40,12 +40,11 @@
#define DRIVER_DESC "EHCI generic platform driver"
#define EHCI_MAX_CLKS 4
-#define EHCI_MAX_RSTS 4
#define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
- struct reset_control *rsts[EHCI_MAX_RSTS];
+ struct reset_control *rsts;
struct phy **phys;
int num_phys;
bool reset_on_resume;
@@ -151,7 +150,7 @@ static int ehci_platform_probe(struct platform_device *dev)
struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
- int err, irq, phy_num, clk = 0, rst;
+ int err, irq, phy_num, clk = 0;
if (usb_disabled())
return -ENODEV;
@@ -239,21 +238,13 @@ static int ehci_platform_probe(struct platform_device
*dev)
}
}
- for (rst = 0; rst < EHCI_MAX_RSTS; rst++) {
- priv->rsts[rst] = devm_reset_control_get_shared_by_index(
- &dev->dev, rst);
- if (IS_ERR(priv->rsts[rst])) {
- err = PTR_ERR(priv->rsts[rst]);
- if (err == -EPROBE_DEFER)
- goto err_reset;
- priv->rsts[rst] = NULL;
- break;
- }
+ priv->rsts = devm_reset_control_array_get_optional_shared(&dev->dev);
+ if (IS_ERR(priv->rsts))
+ return PTR_ERR(priv->rsts);
- err = reset_control_deassert(priv->rsts[rst]);
- if (err)
- goto err_reset;
- }
+ err = reset_control_deassert(priv->rsts);
+ if (err)
+ goto err_put_clks;
if (pdata->big_endian_desc)
ehci->big_endian_desc = 1;
@@ -310,8 +301,7 @@ static int ehci_platform_probe(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
err_reset:
- while (--rst >= 0)
- reset_control_assert(priv->rsts[rst]);
+ reset_control_assert(priv->rsts);
err_put_clks:
while (--clk >= 0)
clk_put(priv->clks[clk]);
@@ -329,15 +319,14 @@ static int ehci_platform_remove(struct platform_device
*dev)
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
- int clk, rst;
+ int clk;
usb_remove_hcd(hcd);
if (pdata->power_off)
pdata->power_off(dev);
- for (rst = 0; rst < EHCI_MAX_RSTS && priv->rsts[rst]; rst++)
- reset_control_assert(priv->rsts[rst]);
+ reset_control_assert(priv->rsts);
for (clk = 0; clk < EHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[clk]);
--
2.7.4
Re: [PATCH v2] ARM: dts: exynos: add cpu perf counters to Exynos54xx boards
On Mon, Oct 30, 2017 at 10:34 AM, Marian Mihailescu wrote: > Hi, > > Can I get feedback on this last patch? Just six days passed... I'll take a look soon, it is not lost. But anyway merge window is too close so I am not planning to take anything more for upcoming release. Best regards. Krzysztof > > Thanks, > Marian > Either I've been missing something or nothing has been going on. (K. E. > Gordon) > > > On Tue, Oct 24, 2017 at 12:59 PM, memeka wrote: >> Enable support for ARM Performance Monitoring Units available in Cortex-A7 >> and Cortex-A15 CPU cores for Exynos54xx SoCs (5410, 5420 and 5422/5800). >> >> The PMUs interrupts are defined in the common exynos54xx.dtsi device tree, >> but the PMUs are enabled and have their interrupt CPU affinity defined >> next to each SoC's cpus node. >> >> Tested with perf on Odroid XU4 (Exynos5422): >> armv7_cortex_a7 PMU driver: 5 counters available >> armv7_cortex_a15 PMU driver: 7 counters available >> >> Suggested-by: Marek Szyprowski >> Signed-off-by: Marian Mihailescu >> Signed-off-by: Willy Wolff >>
Build regressions/improvements in v4.14-rc7
Below is the list of build error/warning regressions/improvements in v4.14-rc7[1] compared to v4.13[2]. Summarized: - build errors: +6/-0 - build warnings: +1861/-923 JFYI, when comparing v4.14-rc7[1] to v4.14-rc6[3], the summaries are: - build errors: +0/-0 - build warnings: +521/-388 Note that there may be false regressions, as some logs are incomplete. Still, they're build errors/warnings. Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/0b07194bb55ed836c2cc7c22e866b87a14681984/ (all 270 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/569dbb88e80deb68974ef6fdd6a13edb9d686261/ (267 out of 270 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/bb176f67090ca54869fc1262c913aa69d2ede070/ (all 270 configs) *** ERRORS *** 6 error regressions: + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: 'per_cpu_secondary_mm' undeclared (first use in this function): => 81:10 + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: implicit declaration of function 'per_cpu' [-Werror=implicit-function-declaration]: => 81:2 + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: implicit declaration of function 'smp_processor_id' [-Werror=implicit-function-declaration]: => 79:12 + /home/kisskb/slave/src/arch/sparc/include/asm/mmu_context_64.h: error: unknown type name 'per_cpu_secondary_mm': => 22:37 + /home/kisskb/slave/src/drivers/net/ethernet/intel/i40e/i40e_ethtool.c: error: implicit declaration of function 'cmpxchg64' [-Werror=implicit-function-declaration]: => 4150:6 + error: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined!: => N/A *** WARNINGS *** [Deleted 836 lines about "warning: ... [-Wpointer-sign]" on parisc-allmodconfig] [Deleted 1136 lines about "warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]" on parisc-allmodconfig] [Deleted 826 lines about "'__f' is static but declared in inline function '...' which is not static [enabled by default]" on i386-randconfig [Deleted 547 lines about ¨warning: "memcpy" ... has no CRC!" on um-allmodconfig 1861 warning regressions: + /home/kisskb/slave/src/arch/um/os-Linux/skas/process.c: warning: control reaches end of non-void function [-Wreturn-type]: => 613:1 + /home/kisskb/slave/src/crypto/algif_aead.c: warning: 'crypto_aead_copy_sgl' uses dynamic stack allocation [enabled by default]: => 91:1 + /home/kisskb/slave/src/drivers/clk/renesas/clk-sh73a0.c: warning: 'parent_name' may be used uninitialized in this function [-Wuninitialized]: => 155:3 + /home/kisskb/slave/src/drivers/crypto/caam/caamalg_qi.c: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Wformat]: => 1062:16, 672:16, 909:16 + /home/kisskb/slave/src/drivers/infiniband/core/uverbs_std_types.c: warning: 'inbuf' may be used uninitialized in this function [-Wuninitialized]: => 249:2 + /home/kisskb/slave/src/drivers/infiniband/core/uverbs_std_types.c: warning: 'outbuf' may be used uninitialized in this function [-Wuninitialized]: => 249:2 + /home/kisskb/slave/src/drivers/md/dm-crypt.c: warning: 'crypt_iv_lmk_one.isra.28' uses dynamic stack allocation [enabled by default]: => 640:1 + /home/kisskb/slave/src/drivers/md/dm-crypt.c: warning: 'crypt_iv_tcw_whitening.isra.27' uses dynamic stack allocation [enabled by default]: => 787:1 + /home/kisskb/slave/src/drivers/media/pci/ddbridge/ddbridge-io.h: warning: 'return' with a value, in function returning void [enabled by default]: => 50:2, 55:2 + /home/kisskb/slave/src/drivers/mtd/chips/cfi_cmdset_0020.c: warning: the frame size of 1396 bytes is larger than 1280 bytes [-Wframe-larger-than=]: => 603:1 + /home/kisskb/slave/src/drivers/net/tun.c: warning: 'copylen' may be used uninitialized in this function [-Wuninitialized]: => 1472:22 + /home/kisskb/slave/src/drivers/net/tun.c: warning: 'linear' may be used uninitialized in this function [-Wuninitialized]: => 1192:34, 1385:46, 1192:31 + /home/kisskb/slave/src/drivers/scsi/bfa/bfa_fcs_lport.c: warning: the frame size of 1712 bytes is larger than 1280 bytes [-Wframe-larger-than=]: => 2160:1 + /home/kisskb/slave/src/fs/btrfs/backref.c: warning: 'count' may be used uninitialized in this function [-Wuninitialized]: => 799:15 + /home/kisskb/slave/src/include/linux/byteorder/big_endian.h: warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]: => 7:2 + /home/kisskb/slave/src/include/linux/byteorder/big_endian.h: warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]In file included from /home/kisskb/slave/src/arch/m32r/include/uapi/asm/byteorder.h:7:0,: => 7:2 + /home/kisskb/slave/src/include/linux/pinctrl/pinconf-generic.h: warning: 'arg' may be used uninitialized in this function [-Wun
Re: [PATCH v2 RESEND] Revert "f2fs: handle dirty segments inside refresh_sit_entry"
On 10/30, Chao Yu wrote:
> On 2017/10/30 9:33, Yunlong Song wrote:
> > This reverts commit 5e443818fa0b2a2845561ee25bec181424fb2889
> >
> > The commit should be reverted because call sequence of below two parts
> > of code must be kept:
> > a. update sit information, it needs to be updated before segment
> > allocation since latter allocation may trigger SSR, and SSR allocation
> > needs latest valid block information of all segments.
> > b. update segment status, it needs to be updated after segment allocation
> > since we can skip updating current opened segment status.
> >
> > Fixes: 5e443818fa0b ("f2fs: handle dirty segments inside refresh_sit_entry")
> > Suggested-by: Chao Yu
> > Signed-off-by: Yunlong Song
>
> Reviewed-by: Chao Yu
>
> Thanks,
>
> > ---
> > fs/f2fs/f2fs.h| 1 -
> > fs/f2fs/segment.c | 20 +---
> > 2 files changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 13a96b8..f166112 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -2567,7 +2567,6 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
> > bool is_checkpointed_data(struct f2fs_sb_info *sbi, block_t blkaddr);
> > void init_discard_policy(struct discard_policy *dpolicy, int discard_type,
> > unsigned int granularity);
> > -void refresh_sit_entry(struct f2fs_sb_info *sbi, block_t old, block_t new);
> > void stop_discard_thread(struct f2fs_sb_info *sbi);
> > bool f2fs_wait_discard_bios(struct f2fs_sb_info *sbi);
> > void clear_prefree_segments(struct f2fs_sb_info *sbi, struct cp_control
> > *cpc);
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index 46dfbca..a3509e9 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -1884,14 +1884,11 @@ static void update_sit_entry(struct f2fs_sb_info
> > *sbi, block_t blkaddr, int del)
> > get_sec_entry(sbi, segno)->valid_blocks += del;
> > }
> >
> > -void refresh_sit_entry(struct f2fs_sb_info *sbi, block_t old, block_t new)
> > +static void refresh_sit_entry(struct f2fs_sb_info *sbi, block_t old,
> > block_t new)
IMO, we don't even need this function, and insteda, do update_sit_entry work
directly below. Merged with it, so let me know, if you have any concern.
Thanks,
> > {
> > update_sit_entry(sbi, new, 1);
> > if (GET_SEGNO(sbi, old) != NULL_SEGNO)
> > update_sit_entry(sbi, old, -1);
> > -
> > - locate_dirty_segment(sbi, GET_SEGNO(sbi, old));
> > - locate_dirty_segment(sbi, GET_SEGNO(sbi, new));
> > }
> >
> > void invalidate_blocks(struct f2fs_sb_info *sbi, block_t addr)
> > @@ -2529,13 +2526,22 @@ void allocate_data_block(struct f2fs_sb_info *sbi,
> > struct page *page,
> >
> > stat_inc_block_count(sbi, curseg);
> >
> > + /*
> > +* SIT information should be updated before segment allocation,
> > +* since SSR needs latest valid block information.
> > +*/
> > + refresh_sit_entry(sbi, old_blkaddr, *new_blkaddr);
> > +
> > if (!__has_curseg_space(sbi, type))
> > sit_i->s_ops->allocate_segment(sbi, type, false);
> > +
> > /*
> > -* SIT information should be updated after segment allocation,
> > -* since we need to keep dirty segments precisely under SSR.
> > +* segment dirty status should be updated after segment allocation,
> > +* so we just need to update status only one time after previous
> > +* segment being closed.
> > */
> > - refresh_sit_entry(sbi, old_blkaddr, *new_blkaddr);
> > + locate_dirty_segment(sbi, GET_SEGNO(sbi, old_blkaddr));
> > + locate_dirty_segment(sbi, GET_SEGNO(sbi, *new_blkaddr));
> >
> > mutex_unlock(&sit_i->sentry_lock);
> >
> >
Re: [PATCH] media: pci: Convert timers to use timer_setup()
Hi Kees,
On 10/24/2017 05:22 PM, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Mauro Carvalho Chehab
> Cc: Andy Walls
> Cc: Sergey Kozlov
> Cc: Abylay Ospan
> Cc: Ezequiel Garcia
> Cc: Hans Verkuil
> Cc: Arvind Yadav
> Cc: Geliang Tang
> Cc: Sean Young
> Cc: Sakari Ailus
> Cc: "Pali Rohár"
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
> drivers/media/pci/bt8xx/bttv-driver.c | 6 +++---
> drivers/media/pci/bt8xx/bttv-input.c | 19 ++-
> drivers/media/pci/bt8xx/bttvp.h| 1 +
> drivers/media/pci/cx18/cx18-fileops.c | 4 ++--
> drivers/media/pci/cx18/cx18-fileops.h | 2 +-
> drivers/media/pci/cx18/cx18-streams.c | 2 +-
> drivers/media/pci/ivtv/ivtv-driver.c | 3 +--
> drivers/media/pci/ivtv/ivtv-irq.c | 4 ++--
> drivers/media/pci/ivtv/ivtv-irq.h | 2 +-
> drivers/media/pci/netup_unidvb/netup_unidvb_core.c | 7 +++
> drivers/media/pci/ttpci/av7110_ir.c| 7 +++
FYI: I'm merging all except for this av7110_ir.c patch.
There are a number of other patches that appear to address this and I think
this driver should be handled separately.
Regards,
Hans
> drivers/media/pci/tw686x/tw686x-core.c | 7 +++
> 12 files changed, 31 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
> b/drivers/media/pci/bt8xx/bttv-driver.c
> index 227086a2e99c..b366a7e1d976 100644
> --- a/drivers/media/pci/bt8xx/bttv-driver.c
> +++ b/drivers/media/pci/bt8xx/bttv-driver.c
> @@ -3652,9 +3652,9 @@ bttv_irq_wakeup_vbi(struct bttv *btv, struct
> bttv_buffer *wakeup,
> wake_up(&wakeup->vb.done);
> }
>
> -static void bttv_irq_timeout(unsigned long data)
> +static void bttv_irq_timeout(struct timer_list *t)
> {
> - struct bttv *btv = (struct bttv *)data;
> + struct bttv *btv = from_timer(btv, t, timeout);
> struct bttv_buffer_set old,new;
> struct bttv_buffer *ovbi;
> struct bttv_buffer *item;
> @@ -4043,7 +4043,7 @@ static int bttv_probe(struct pci_dev *dev, const struct
> pci_device_id *pci_id)
> INIT_LIST_HEAD(&btv->capture);
> INIT_LIST_HEAD(&btv->vcapture);
>
> - setup_timer(&btv->timeout, bttv_irq_timeout, (unsigned long)btv);
> + timer_setup(&btv->timeout, bttv_irq_timeout, 0);
>
> btv->i2c_rc = -1;
> btv->tuner_type = UNSET;
> diff --git a/drivers/media/pci/bt8xx/bttv-input.c
> b/drivers/media/pci/bt8xx/bttv-input.c
> index 73d655d073d6..ac7674700685 100644
> --- a/drivers/media/pci/bt8xx/bttv-input.c
> +++ b/drivers/media/pci/bt8xx/bttv-input.c
> @@ -133,10 +133,10 @@ void bttv_input_irq(struct bttv *btv)
> ir_handle_key(btv);
> }
>
> -static void bttv_input_timer(unsigned long data)
> +static void bttv_input_timer(struct timer_list *t)
> {
> - struct bttv *btv = (struct bttv*)data;
> - struct bttv_ir *ir = btv->remote;
> + struct bttv_ir *ir = from_timer(ir, t, timer);
> + struct bttv *btv = ir->btv;
>
> if (btv->c.type == BTTV_BOARD_ENLTV_FM_2)
> ir_enltv_handle_key(btv);
> @@ -189,9 +189,9 @@ static u32 bttv_rc5_decode(unsigned int code)
> return rc5;
> }
>
> -static void bttv_rc5_timer_end(unsigned long data)
> +static void bttv_rc5_timer_end(struct timer_list *t)
> {
> - struct bttv_ir *ir = (struct bttv_ir *)data;
> + struct bttv_ir *ir = from_timer(ir, t, timer);
> ktime_t tv;
> u32 gap, rc5, scancode;
> u8 toggle, command, system;
> @@ -296,15 +296,15 @@ static int bttv_rc5_irq(struct bttv *btv)
>
> /* -- */
>
> -static void bttv_ir_start(struct bttv *btv, struct bttv_ir *ir)
> +static void bttv_ir_start(struct bttv_ir *ir)
> {
> if (ir->polling) {
> - setup_timer(&ir->timer, bttv_input_timer, (unsigned long)btv);
> + timer_setup(&ir->timer, bttv_input_timer, 0);
> ir->timer.expires = jiffies + msecs_to_jiffies(1000);
> add_timer(&ir->timer);
> } else if (ir->rc5_gpio) {
> /* set timer_end for code completion */
> - setup_timer(&ir->timer, bttv_rc5_timer_end, (unsigned long)ir);
> + timer_setup(&ir->timer, bttv_rc5_timer_end, 0);
> ir->shift_by = 1;
> ir->rc5_remote_gap = ir_rc5_remote_gap;
> }
> @@ -531,6 +531,7 @@ int bttv_input_init(struct bttv *btv)
>
> /* init input device */
> ir->dev = rc;
> + ir->btv = btv;
>
> snprintf(ir->name, sizeof(ir->name), "bttv IR (card=%d)",
>btv->c.type);
> @@ -553,7 +554,7 @@ int bttv_input_init(struct bttv *btv)
> rc->drive
Re: [f2fs-dev] [PATCH] f2fs: optimize __update_nat_bits
On 2017/10/30 15:19, Fan Li wrote:
> Make three modification for __update_nat_bits:
> 1. Take the codes of dealing the nat with nid 0 out of the loop
> Such nat only needs to be dealt with once at beginning.
> 2. Use " nat_index == 0" instead of " start_nid == 0" to decide if it's the
> first nat block
> It's better that we don't assume @start_nid is the first nid of the nat
> block it's in.
> 3. Use " if (nat_blk->entries[i].block_addr != NULL_ADDR)" to explicitly
> comfirm the value of block_addr
> use constant to make sure the codes is right, even if the value of
> NULL_ADDR changes.
>
> Signed-off-by: Fan li
Reviewed-by: Chao Yu
Thanks,
> ---
> fs/f2fs/node.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index ac629d6..b97a031 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -2407,15 +2407,17 @@ static void __update_nat_bits(struct f2fs_sb_info
> *sbi, nid_t start_nid,
> unsigned int nat_index = start_nid / NAT_ENTRY_PER_BLOCK;
> struct f2fs_nat_block *nat_blk = page_address(page);
> int valid = 0;
> - int i;
> + int i = 0;
>
> if (!enabled_nat_bits(sbi, NULL))
> return;
>
> - for (i = 0; i < NAT_ENTRY_PER_BLOCK; i++) {
> - if (start_nid == 0 && i == 0)
> - valid++;
> - if (nat_blk->entries[i].block_addr)
> + if (nat_index == 0) {
> + valid = 1;
> + i = 1;
> + }
> + for (; i < NAT_ENTRY_PER_BLOCK; i++) {
> + if (nat_blk->entries[i].block_addr != NULL_ADDR)
> valid++;
> }
> if (valid == 0) {
> --
> 2.7.4
>
>
>
Re: [f2fs-dev] [PATCH 2/2] f2fs: relax EIO injection for quota file
On 2017/10/30 17:21, Jaegeuk Kim wrote:
> On 10/28, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2017/10/23 0:51, Jaegeuk Kim wrote:
>>> On 10/22, Chao Yu wrote:
On 2017/10/20 0:56, Jaegeuk Kim wrote:
> This case is not happening easily.
Actually it can happen, so why not just keep it?
>>>
>>> Okay, so let me keep this patch for local stress tests only.
>>
>> May I ask which type and rate of fault injection you are using for
>> test now?
>
> I select random value between 3000 and 5000, and 255 for type.
Got it, thanks for your sharing. :)
Thanks,
>
> Thanks,
>
>>
>> Thanks,
>>
>>>
>>> Thanks,
>>>
>>>
Thanks,
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/f2fs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index e0ef31cb2cc6..6301ccca 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1544,7 +1544,7 @@ static inline int inc_valid_block_count(struct
> f2fs_sb_info *sbi,
> return ret;
>
> #ifdef CONFIG_F2FS_FAULT_INJECTION
> - if (time_to_inject(sbi, FAULT_BLOCK)) {
> + if (!IS_NOQUOTA(inode) && time_to_inject(sbi, FAULT_BLOCK)) {
> f2fs_show_injection_info(FAULT_BLOCK);
> release = *count;
> goto enospc;
>
>>>
>>> .
>>>
>
> .
>
Re: [PATCH v2] pids: introduce find_get_task_by_vpid helper
On Mon, Oct 30, 2017 at 07:51:42PM +1100, Balbir Singh wrote: > On Sat, Oct 28, 2017 at 4:52 AM, Mike Rapoport > wrote: > > There are several functions that do find_task_by_vpid() followed by > > get_task_struct(). We can use a helper function instead. > > > > Signed-off-by: Mike Rapoport > > --- > > I did a quick grep and found other similar patterns in (reordered the file list a bit) > kernel/events/core.c, > arch/x86/kernel/cpu/intel_rdt_rdtgroup.c, > mm/mempolicy.c, Those and mm/migrate.c indeed have a similar pattern, but they all do task = pid ? find_task_by_vpid(pid) : current; And I don't see an elegant way to use find_get_task_by_vpid() in this case. > kernel/kcmp.c, kcmp gets both tasks between rcu_read_lock/unlock and I think it's better to keep it this way. > kernel/sys.c, There is no get_task_struct() after find_task_by_vpid(), unless I've missed something > kernel/time/posix-cpu-timers.c, Here the task is selected with more complex logic than just find_task_by_vpid() > mm/process_vm_access.c, Converted in the patch > security/yama/yama_lsm.c, > arch/ia64/kernel/perfmon.c I've missed these two, indeed. The arch/ia64/kernel/perfmon.c even still uses read_lock(&tasklist) rather than rcu_read_lock()... > Balbir Singh. > -- Sincerely yours, Mike.
Re: [PATCH 0/3] arm64: defconfig: remove some Qualcomm USB options
On Thu, Oct 26, 2017 at 3:23 AM, Alex Elder wrote: > This series deletes three config options related to USB on Qualcomm > SoCs from the arm64 "defconfig". The code enabled by the options is > no longer needed by any Qualcomm hardware. > > -Alex Shouldn't we remove the driver code too in the case that no HW actually uses it? > Alex Elder (3): > arm64: defconfig: remove CONFIG_USB_EHCI_MSM > arm64: defconfig: remove CONFIG_USB_MSM_OTG > arm64: defconfig: remove CONFIG_USB_QCOM_8X16_PHY > > arch/arm64/configs/defconfig | 3 --- > 1 file changed, 3 deletions(-)
Re: [PATCH] virtio_balloon: fix deadlock on OOM
On 10/13/2017 09:21 PM, Michael S. Tsirkin wrote: fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY is specified, this allocation attempt might indirectly depend on somebody else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via virtballoon_oom_notify() via blocking_notifier_call_chain() callback via out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if leak_balloon() is called from out_of_memory(). Thread1 Thread2 fill_balloon() takes a balloon_lock balloon_page_enqueue() alloc_page(GFP_HIGHUSER_MOVABLE) direct reclaim (__GFP_FS context) takes a fs lock waits for that fs lock alloc_page(GFP_NOFS) __alloc_pages_may_oom() takes the oom_lock out_of_memory() blocking_notifier_call_chain() leak_balloon() tries to take that balloon_lock and deadlocks Reported-by: Tetsuo Handa Cc: Michal Hocko Cc: Wei Wang --- The "virtio-balloon enhancement" series has a dependency on this patch. Could you send out a new version soon? Or I can include it in the series if you want. Best, Wei
Re: Adjustments for a lot of function implementations
On Mon, 30 Oct 2017, SF Markus Elfring wrote: > > While we do not mind cleanup patches, the way you post them (one fix per > > file) > > I find it safer in this way while I was browsing through the landscape of > Linux > software components. > > > > is really annoying and takes us too much time to review. > > It is just the case that there are so many remaining open issues. > > > > I'll take the "Fix a possible null pointer" patch since it is an actual bug > > fix, > > Thanks for a bit of change acceptance. > > > > but will reject the others, not just this driver but all of them that are > > currently > > pending in our patchwork (https://patchwork.linuxtv.org). > > Will any chances evolve to integrate 146 patches in any other combination? > > > > Feel free to repost, but only if you organize the patch as either fixing > > the same type of > > issue for a whole subdirectory (media/usb, media/pci, etc) Just for the record, while this may work for media, it won't work for all subsystems. One will quickly get a complaint that the big patch needs to go into multiple trees. julia > > Can we achieve an agreement on the shown change patterns? > > Is a consensus possible for involved update candidates? > > > > or fixing all issues for a single driver. > > I find that I did this already. > > > > Actual bug fixes (like the null pointer patch in this series) can still be > > posted as > > separate patches, but cleanups shouldn't. > > I got an other software development opinion. > > > > Just so you know, I'll reject any future patch series that do not follow > > these rules. > > Just use common sense when posting these things in the future. > > Do we need to try any additional communication tools out? > > > > I would also suggest that your time might be spent more productively if you > > would > > work on some more useful projects. > > I hope that various change possibilities (from my selection) will become > useful > for more Linux users. > How will the clarification evolve further? > > > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH] drivers/firmware: psci_checker: Add missing destroy_timer_on_stack()
On Mon, Oct 30, 2017 at 10:17:54AM +0100, Arnd Bergmann wrote:
> On Tue, Oct 24, 2017 at 5:02 PM, Lorenzo Pieralisi
> wrote:
> > The PSCI checker suspend_test_thread() function (ie executed for the
> > suspend test) requires an on-stack timer to carry out the test it
> > executes; it sets it up through the setup_timer_on_stack() API.
> >
> > setup_timer_on_stack() requires its counterpart destroy_timer_on_stack()
> > to be called when the timer is disposed of but the PSCI checker code is
> > currently missing that call, leaving the timer object in an incosistent
> > state when the PSCI checker stops the thread executing the suspend
> > test.
> >
> > Add the missing destroy_timer_on_stack() call to fix the omission.
> >
> > Fixes: ea8b1c4a6019 ("drivers: psci: PSCI checker module")
> > Signed-off-by: Lorenzo Pieralisi
> > Reported-by: Kees Cook
> > Cc: Kees Cook
> > Cc: Mark Rutland
>
> Hi Lorenzo,
>
> You addressed the patch 'To: a...@kernel.org', but I'm not entirely
> sure what to do with it, it would be nice to be a little more explicit whether
> you want us to apply the patch directly or just review it, and which trees
> you want it to get merged into.
Yes, I was about to reply to you - I should have added some comments
to the patch itself, apologies.
> As you are fixing a regression against v4.10, I would assume you want
> it merged into v4.14 with a 'cc: stable' tag to have it backported into v4.13,
> correct?
Yes it is correct - since the PSCI checker went through ARM SoC I expect
fixes to go through ARM SoC too please (but I should have mentioned the
summary you correctly wrote up above myself).
Thanks,
Lorenzo
Re: [PATCH] media: pvrusb2: Convert timers to use timer_setup()
On 10/24/2017 05:22 PM, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Mike Isely
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Kees Cook
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 64
> ++---
> 1 file changed, 36 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> index ad5b25b89699..8289ee482f49 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> @@ -330,10 +330,10 @@ static void pvr2_hdw_state_log_state(struct pvr2_hdw *);
> static int pvr2_hdw_cmd_usbstream(struct pvr2_hdw *hdw,int runFl);
> static int pvr2_hdw_commit_setup(struct pvr2_hdw *hdw);
> static int pvr2_hdw_get_eeprom_addr(struct pvr2_hdw *hdw);
> -static void pvr2_hdw_quiescent_timeout(unsigned long);
> -static void pvr2_hdw_decoder_stabilization_timeout(unsigned long);
> -static void pvr2_hdw_encoder_wait_timeout(unsigned long);
> -static void pvr2_hdw_encoder_run_timeout(unsigned long);
> +static void pvr2_hdw_quiescent_timeout(struct timer_list *);
> +static void pvr2_hdw_decoder_stabilization_timeout(struct timer_list *);
> +static void pvr2_hdw_encoder_wait_timeout(struct timer_list *);
> +static void pvr2_hdw_encoder_run_timeout(struct timer_list *);
> static int pvr2_issue_simple_cmd(struct pvr2_hdw *,u32);
> static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> unsigned int timeout,int probe_fl,
> @@ -2373,18 +2373,15 @@ struct pvr2_hdw *pvr2_hdw_create(struct usb_interface
> *intf,
> }
> if (!hdw) goto fail;
>
> - setup_timer(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout, 0);
>
> - setup_timer(&hdw->decoder_stabilization_timer,
> - pvr2_hdw_decoder_stabilization_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->decoder_stabilization_timer,
> + pvr2_hdw_decoder_stabilization_timeout, 0);
>
> - setup_timer(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
> + 0);
>
> - setup_timer(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout,
> - (unsigned long)hdw);
> + timer_setup(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout, 0);
>
> hdw->master_state = PVR2_STATE_DEAD;
>
> @@ -3539,10 +3536,16 @@ static void pvr2_ctl_read_complete(struct urb *urb)
> complete(&hdw->ctl_done);
> }
>
> +struct hdw_timer {
> + struct timer_list timer;
> + struct pvr2_hdw *hdw;
> +};
>
> -static void pvr2_ctl_timeout(unsigned long data)
> +static void pvr2_ctl_timeout(struct timer_list *t)
> {
> - struct pvr2_hdw *hdw = (struct pvr2_hdw *)data;
> + struct hdw_timer *timer = from_timer(timer, t, timer);
> + struct pvr2_hdw *hdw = timer->hdw;
> +
> if (hdw->ctl_write_pend_flag || hdw->ctl_read_pend_flag) {
> hdw->ctl_timeout_flag = !0;
> if (hdw->ctl_write_pend_flag)
> @@ -3564,7 +3567,10 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> {
> unsigned int idx;
> int status = 0;
> - struct timer_list timer;
> + struct hdw_timer timer = {
> + .hdw = hdw,
> + };
> +
> if (!hdw->ctl_lock_held) {
> pvr2_trace(PVR2_TRACE_ERROR_LEGS,
> "Attempted to execute control transfer without
> lock!!");
> @@ -3621,8 +3627,8 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
> hdw->ctl_timeout_flag = 0;
> hdw->ctl_write_pend_flag = 0;
> hdw->ctl_read_pend_flag = 0;
> - setup_timer(&timer, pvr2_ctl_timeout, (unsigned long)hdw);
> - timer.expires = jiffies + timeout;
> + timer_setup_on_stack(&timer.timer, pvr2_ctl_timeout, 0);
> + timer.timer.expires = jiffies + timeout;
>
> if (write_len && write_data) {
> hdw->cmd_debug_state = 2;
> @@ -3677,7 +3683,7 @@ status);
> }
>
> /* Start timer */
> - add_timer(&timer);
> + add_timer(&timer.timer);
>
> /* Now wait for all I/O to complete */
> hdw->cmd_debug_state = 4;
> @@ -3687,7 +3693,7 @@ status);
> hdw->cmd_debug_state = 5;
>
> /* Stop timer */
> - del_timer_sync(&timer);
> + del_timer_sync(&timer.timer);
>
> hdw->cmd_debug_state = 6;
> status = 0;
> @@ -3769,6 +3775,8 @@ status);
> if ((status < 0) && (!probe_fl)) {
> pvr2_hdw_render_useless(hdw);
> }
> + destroy_timer_on_
Re: [PATCH 3/3] spi: spi-axi: take extra controller reference before deregistration
On 10/29/2017 12:56 PM, Johan Hovold wrote: > Take an extra reference to the controller to avoid use-after-free in > free_irq() which is called only after the controller has been > deregistered and freed. > > Note that this is not an issue for this particular driver which does not > use shared interrupts, but free_irq() could otherwise end up accessing > the freed controller when CONFIG_DEBUG_SHIRQ is set. Strictly speaking there is no guarantee that the IRQ handler does not run until free_irq() has been called. And since the SPI master is referenced in the IRQ handler there could be an use-after-free condition. So there is kind of a real issue here as well. But it should be really really hard to trigger it unless the hardware misbehaves. > > Defer controller release until free_irq() returns to prevent this > from ever becoming an issue should this code be replicated in other > drivers. > > Cc: Lars-Peter Clausen > Signed-off-by: Johan Hovold Acked-by: Lars-Peter Clausen Thanks.
Re: [PATCH 0/3] arm64: defconfig: remove some Qualcomm USB options
On Mon, Oct 30, 2017 at 3:16 PM, Amit Kucheria wrote: > On Thu, Oct 26, 2017 at 3:23 AM, Alex Elder wrote: >> This series deletes three config options related to USB on Qualcomm >> SoCs from the arm64 "defconfig". The code enabled by the options is >> no longer needed by any Qualcomm hardware. >> >> -Alex > > > Shouldn't we remove the driver code too in the case that no HW actually uses > it? Nevermind, I just found the other thread that removes the actual driver code. FWIW, for the entire series, feel free to add my Reviewed-by.
Re: [PATCH 1/2] drm/rcar-du: Use common error handling code in rcar_du_encoders_init()
On Sun, 29 Oct 2017, Laurent Pinchart wrote: > Hi Jani, > > On Friday, 27 October 2017 21:45:17 EET Jani Nikula wrote: >> On Tue, 24 Oct 2017, SF Markus Elfring wrote: >> > Add a jump target so that a bit of exception handling can be better reused >> > at the end of this function. >> > >> > This issue was detected by using the Coccinelle software. >> >> Please also look into the GCC software, which will detect that your >> patch does not compile. > > Just for the record, I've been bitten in the past by applying one of Markus' > patches that seemed to make sense, only to discover later that it introduced > a > security hole. I now drop his patches altogether, so could you please keep an > eye open to make sure none of them touching the rcar-du driver will be > applied > through drm-misc ? Ack. You're the maintainer, and we need to respect that. In general, I'll pick up any patches that are good, but the current track record is that Markus' patches need extra scrutiny, and many of the patches contain subjective changes that lead to debate that is not constructive. There's no return on investment here. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
