Problem with tdfx drm module
[root@neutron /root]# modprobe tdfx /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol create_proc_entry /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol inter_module_put /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol __get_free_pages /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol boot_cpu_data /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol inter_module_get /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol remove_wait_queue /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol high_memory /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol iounmap /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol free_pages /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol __ioremap /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol del_timer /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol interruptible_sleep_on /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol __pollwait /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol kfree /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol remove_proc_entry /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol pci_find_slot /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol kill_fasync /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol fasync_helper /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol add_wait_queue /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol do_mmap_pgoff /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol mem_map /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol sprintf /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol jiffies /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol printk /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol add_timer /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_to_user /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: insmod /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o failed /lib/modules/2.4.0-test13pre4-ac2/kernel/drivers/char/drm/tdfx.o: insmod tdfx failed This is on kernel 2.4.0-test13pre4 ac2 and on 2.4.0test13pre (not the ac patch) the tdfx module doesn't even build. I am using modutils 2.3.23 (it didn't work with 2.3.21 and 2.3.22 either). This is with XFree86 4.0.1 and a Voodoo3 3000 on a Pentium III 450 if that is revelant.. All of those unresolved symbols do appear in /proc/ksyms Kernel configuration File here: # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFI
[PATCH 1/3] arm/pmu: Reject groups spanning multiple hardware PMUs
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may not be true always, with other hardware PMUs
around (CCI, CCN).
---
CPU: 0 PID: 1527 Comm: perf_fuzzer Not tainted 4.0.0-rc2 #57
Hardware name: ARM-Versatile Express
task: bd8484c0 ti: be676000 task.ti: be676000
PC is at 0xbf1bbc90
LR is at validate_event+0x34/0x5c
pc : []lr : [<80016060>]psr: 0013
...
[<80016060>] (validate_event) from [<80016198>] (validate_group+0x28/0x90)
[<80016198>] (validate_group) from [<80016398>] (armpmu_event_init+0x150/0x218)
[<80016398>] (armpmu_event_init) from [<800882e4>]
(perf_try_init_event+0x30/0x48)
[<800882e4>] (perf_try_init_event) from [<8008f544>] (perf_init_event+0x5c/0xf4)
[<8008f544>] (perf_init_event) from [<8008f8a8>] (perf_event_alloc+0x2cc/0x35c)
[<8008f8a8>] (perf_event_alloc) from [<8009015c>]
(SyS_perf_event_open+0x498/0xa70)
[<8009015c>] (SyS_perf_event_open) from [<8000e420>] (ret_fast_syscall+0x0/0x34)
Code: bf1be000 bf1bb380 802a2664 (0002)
---[ end trace 01aff0ff00926a0a ]---
Also cleans up the code to use the arm_pmu only when we know that
we are dealing with an arm pmu event.
Cc: Will Deacon
Cc: Mark Rutland
Signed-off-by: Suzuki K. Poulose
---
arch/arm/kernel/perf_event.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 557e128..4a86a01 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -259,20 +259,29 @@ out:
}
static int
-validate_event(struct pmu_hw_events *hw_events,
- struct perf_event *event)
+validate_event(struct pmu *pmu, struct pmu_hw_events *hw_events,
+ struct perf_event *event)
{
- struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
+ struct arm_pmu *armpmu;
if (is_software_event(event))
return 1;
+ /*
+* Reject groups spanning multiple HW PMUs (e.g. CPU + CCI). The
+* core perf code won't check that the pmu->ctx == leader->ctx
+* until after pmu->event_init(event).
+*/
+ if (event->pmu != pmu)
+ return 0;
+
if (event->state < PERF_EVENT_STATE_OFF)
return 1;
if (event->state == PERF_EVENT_STATE_OFF && !event->attr.enable_on_exec)
return 1;
+ armpmu = to_arm_pmu(event->pmu);
return armpmu->get_event_idx(hw_events, event) >= 0;
}
@@ -288,15 +297,15 @@ validate_group(struct perf_event *event)
*/
memset(&fake_pmu.used_mask, 0, sizeof(fake_pmu.used_mask));
- if (!validate_event(&fake_pmu, leader))
+ if (!validate_event(event->pmu, &fake_pmu, leader))
return -EINVAL;
list_for_each_entry(sibling, &leader->sibling_list, group_entry) {
- if (!validate_event(&fake_pmu, sibling))
+ if (!validate_event(event->pmu, &fake_pmu, sibling))
return -EINVAL;
}
- if (!validate_event(&fake_pmu, event))
+ if (!validate_event(event->pmu, &fake_pmu, event))
return -EINVAL;
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] arm-cci: Reject groups spanning multiple HW PMUs
From: "Suzuki K. Poulose"
Invalidate an event if the group has a hardware event from
a different PMU as we cannot schedule all of them in the same
context. The perf core code won't check the group consistency
until after pmu_event_init().
Signed-off-by: Suzuki K. Poulose
---
drivers/bus/arm-cci.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 84fd660..68ef6f2 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -660,12 +660,21 @@ static void cci_pmu_del(struct perf_event *event, int
flags)
}
static int
-validate_event(struct cci_pmu_hw_events *hw_events,
- struct perf_event *event)
+validate_event(struct pmu *cci_pmu,
+ struct cci_pmu_hw_events *hw_events,
+ struct perf_event *event)
{
if (is_software_event(event))
return 1;
+ /*
+* Reject groups spanning multiple HW PMUs (e.g. CPU + CCI). The
+* core perf code won't check that the pmu->ctx == leader->ctx
+* until after pmu->event_init(event).
+*/
+ if (event->pmu != cci_pmu)
+ return 0;
+
if (event->state < PERF_EVENT_STATE_OFF)
return 1;
@@ -687,15 +696,15 @@ validate_group(struct perf_event *event)
.used_mask = CPU_BITS_NONE,
};
- if (!validate_event(&fake_pmu, leader))
+ if (!validate_event(event->pmu, &fake_pmu, leader))
return -EINVAL;
list_for_each_entry(sibling, &leader->sibling_list, group_entry) {
- if (!validate_event(&fake_pmu, sibling))
+ if (!validate_event(event->pmu, &fake_pmu, sibling))
return -EINVAL;
}
- if (!validate_event(&fake_pmu, event))
+ if (!validate_event(event->pmu, &fake_pmu, event))
return -EINVAL;
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] [4.0] arm/arm64: Do not group hardware events from different PMUs
From: "Suzuki K. Poulose" This is a collection of fixes which denies grouping hardware events from different PMUs. They also fix crashes triggered by perf_fuzzer on Linux-4.0-rc2. Pawel, Similar fix is required in ARM CCN PMU driver. I didn't find it straight forward to fix it there. Could you please take a look into it ? Suzuki K. Poulose (3): arm/pmu: Reject groups spanning multiple hardware PMUs arm64/pmu: Reject groups spanning multiple HW PMUs arm-cci: Reject groups spanning multiple HW PMUs arch/arm/kernel/perf_event.c | 21 +++-- arch/arm64/kernel/perf_event.c | 21 +++-- drivers/bus/arm-cci.c | 19 ++- 3 files changed, 44 insertions(+), 17 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] arm64/pmu: Reject groups spanning multiple HW PMUs
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may not be true always, with other hardware PMUs
around (CCI, CCN).
Bad mode in Synchronous Abort handler detected, code 0x8606 -- IABT
(current EL)
CPU: 0 PID: 1371 Comm: perf_fuzzer Not tainted 3.19.0+ #249
Hardware name: V2F-1XV7 Cortex-A53x2 SMM (DT)
task: ffc07c73a280 ti: ffc07b0a task.ti: ffc07b0a
PC is at 0x0
LR is at validate_event+0x90/0xa8
pc : [<>] lr : [] pstate: 0145
sp : ffc07b0a3ba0
[< (null)>] (null)
[] armpmu_event_init+0x174/0x3cc
[] perf_try_init_event+0x34/0x70
[] perf_init_event+0xe0/0x10c
[] perf_event_alloc+0x288/0x358
[] SyS_perf_event_open+0x464/0x98c
Code: bad PC value
Also cleans up the code to use the arm_pmu only when we know
that we are dealing with an arm pmu event.
Cc: Will Deacon
Cc: Mark Rutland
Signed-off-by: Suzuki K. Poulose
---
arch/arm64/kernel/perf_event.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 25a5308..68a7415 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -322,22 +322,31 @@ out:
}
static int
-validate_event(struct pmu_hw_events *hw_events,
- struct perf_event *event)
+validate_event(struct pmu *pmu, struct pmu_hw_events *hw_events,
+ struct perf_event *event)
{
- struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
+ struct arm_pmu *armpmu;
struct hw_perf_event fake_event = event->hw;
struct pmu *leader_pmu = event->group_leader->pmu;
if (is_software_event(event))
return 1;
+ /*
+* Reject groups spanning multiple HW PMUs (e.g. CPU + CCI). The
+* core perf code won't check that the pmu->ctx == leader->ctx
+* until after pmu->event_init(event).
+*/
+ if (event->pmu != pmu)
+ return 0;
+
if (event->pmu != leader_pmu || event->state < PERF_EVENT_STATE_OFF)
return 1;
if (event->state == PERF_EVENT_STATE_OFF && !event->attr.enable_on_exec)
return 1;
+ armpmu = to_arm_pmu(event->pmu);
return armpmu->get_event_idx(hw_events, &fake_event) >= 0;
}
@@ -355,15 +364,15 @@ validate_group(struct perf_event *event)
memset(fake_used_mask, 0, sizeof(fake_used_mask));
fake_pmu.used_mask = fake_used_mask;
- if (!validate_event(&fake_pmu, leader))
+ if (!validate_event(event->pmu, &fake_pmu, leader))
return -EINVAL;
list_for_each_entry(sibling, &leader->sibling_list, group_entry) {
- if (!validate_event(&fake_pmu, sibling))
+ if (!validate_event(event->pmu, &fake_pmu, sibling))
return -EINVAL;
}
- if (!validate_event(&fake_pmu, event))
+ if (!validate_event(event->pmu, &fake_pmu, event))
return -EINVAL;
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reply
Are you free for discussion?
Re: [Acpi] linux-test12-pre3 fails to compile in acpi.c]
Patrick Mochel wrote: > > Hmm...I tried it a few times, and I could not get it to fail. This is > what I did: Success! rm -rf linux-2.4 Started over with my original linux-2.4.0-test10.bz2, patched it up and all was fine. Perhaps I experienced some of the fs corruption that has been floating around. Linux support never will cease to amaze me. Thanks! Garst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reply: [Qemu-devel] reply: reply: qemu crashed when starting vm(kvm) with vnc connect
> > On Mon, Apr 08, 2013 at 12:27:06PM +, Zhanghaoyu (A) wrote:
> >> On Sun, Apr 07, 2013 at 04:58:07AM +0000, Zhanghaoyu (A) wrote:
> >>>>>> I start a kvm VM with vnc(using the zrle protocol) connect, sometimes
> >>>>>> qemu program crashed during starting period, received signal SIGABRT.
> >>>>>> Trying about 20 times, this crash may be reproduced.
> >>>>>> I guess the cause memory corruption or double free.
> >>>>>
> >>>>> Which version of QEMU are you running?
> >>>>>
> >>>>> Please try qemu.git/master.
>
> Please try again with latest master, might be fixed meanwhile.
>
> If it still happens pleas provide full qemu and vnc client command lines.
>
> >> backtrace from core file is shown as below:
> >>
> >> Program received signal SIGABRT, Aborted.
>
> >> #8 0x7f32efd26d07 in vnc_disconnect_finish (vs=0x7f32f0c762d0)
> >> at ui/vnc.c:1050
>
> Do you have a vnc client connected? Do you close it?
>
I have a vnc client connected, it was auto closed while qemu crashed.
> Any errors reported by the vnc client (maybe it disconnects due to an error
> in the data stream)?
>
No errors reported by the vnc client, just popup a reconnect window.
And, I have tried to fix this bug, not reproduce this crash after tried about
100 times, patch is shown as below,
--- a/ui/vnc-jobs.c 2013-04-18 20:10:07.0 +0800
+++ b/ui/vnc-jobs.c 2013-04-18 20:14:06.0 +0800
@@ -234,7 +234,6 @@ static int vnc_worker_thread_loop(VncJob
vnc_unlock_output(job->vs);
goto disconnected;
}
-vnc_unlock_output(job->vs);
/* Make a local copy of vs and switch output buffers */
vnc_async_encoding_start(job->vs, &vs);
@@ -252,6 +251,8 @@ static int vnc_worker_thread_loop(VncJob
if (job->vs->csock == -1) {
vnc_unlock_display(job->vs->vd);
+vnc_async_encoding_end(job->vs, &vs);
+vnc_unlock_output(job->vs);
goto disconnected;
}
@@ -269,7 +270,6 @@ static int vnc_worker_thread_loop(VncJob
vs.output.buffer[saved_offset] = (n_rectangles >> 8) & 0xFF;
vs.output.buffer[saved_offset + 1] = n_rectangles & 0xFF;
-vnc_lock_output(job->vs);
if (job->vs->csock != -1) {
buffer_reserve(&job->vs->jobs_buffer, vs.output.offset);
buffer_append(&job->vs->jobs_buffer, vs.output.buffer,
@@ -278,6 +278,8 @@ static int vnc_worker_thread_loop(VncJob
vnc_async_encoding_end(job->vs, &vs);
qemu_bh_schedule(job->vs->bh);
+} else {
+vnc_async_encoding_end(job->vs, &vs);
}
vnc_unlock_output(job->vs);
Thanks,
Zhang Haoyu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
>> On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote:
>>> I start 10 VMs(windows xp), then running geekbench tool on them,
>>> about 2 days, one of them was reset, I found the reset operation is
>>> done by int kvm_cpu_exec(CPUArchState *env) {
>>>...
>>> switch (run->exit_reason)
>>> ...
>>>case KVM_EXIT_SHUTDOWN:
>>>DPRINTF("shutdown\n");
>>>qemu_system_reset_request();
>>>ret = EXCP_INTERRUPT;
>>>break;
>>>...
>>> }
>>>
>>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle
>>> handle_triple_fault().
>>>
>> How do you know that reset was done here? This is not the only place
>> where qemu_system_reset_request() is called.
I used gdb to debug QEMU process, and add a breakpoint in
qemu_system_reset_request(), when the case occurred, backtrace shown as below,
(gdb) bt
#0 qemu_system_reset_request () at vl.c:1964
#1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100)
at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602
#2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100)
at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759
#3 0x7f9ef898b5f0 in start_thread () from /lib64/libpthread.so.0
#4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6
#5 0x in ?? ()
And, I add printk log in all place where KVM_EXIT_SHUTDOWN exit reason is set,
only handle_triple_fault() was called.
>
>Make sure XP is not set to auto-reset in case of BSOD.
No, winxp is not set to auto-reset in case of BSOD. No Winxp event log reported.
>
>Best regards,
>Yan.
>
>>
>>> What causes the triple fault?
>>>
>> Are you asking what is triple fault or why it happened in your case?
What I asked is why triple fault happened in my case.
>> For the former see here: http://en.wikipedia.org/wiki/Triple_fault
>> For the later it is to late to tell after VM reset. You can run QEMU
>> with -no-reboot -no-shutdown. VM will pause instead of rebooting and
>> then you can examine what is going on.
Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM paused
in my case, what should I examined?
Thanks,
Zhang Haoyu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
>> >> On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote:
>> >>> I start 10 VMs(windows xp), then running geekbench tool on them,
>> >>> about 2 days, one of them was reset, I found the reset operation
>> >>> is done by int kvm_cpu_exec(CPUArchState *env) {
>> >>>...
>> >>> switch (run->exit_reason)
>> >>> ...
>> >>>case KVM_EXIT_SHUTDOWN:
>> >>>DPRINTF("shutdown\n");
>> >>>qemu_system_reset_request();
>> >>>ret = EXCP_INTERRUPT;
>> >>>break;
>> >>>...
>> >>> }
>> >>>
>> >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle
>> >>> handle_triple_fault().
>> >>>
>> >> How do you know that reset was done here? This is not the only
>> >> place where qemu_system_reset_request() is called.
>> I used gdb to debug QEMU process, and add a breakpoint in
>> qemu_system_reset_request(), when the case occurred, backtrace shown
>> as below,
>> (gdb) bt
>> #0 qemu_system_reset_request () at vl.c:1964
>> #1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100)
>> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602
>> #2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100)
>> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759
>> #3 0x7f9ef898b5f0 in start_thread () from /lib64/libpthread.so.0
>> #4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6
>> #5 0x in ?? ()
>>
>> And, I add printk log in all places where KVM_EXIT_SHUTDOWN exit reason is
>> set, only handle_triple_fault() was called.
>> >
>> >Make sure XP is not set to auto-reset in case of BSOD.
>> No, winxp is not set to auto-reset in case of BSOD. No Winxp event log
>> reported.
>> >
>> >Best regards,
>> >Yan.
>> >
>> >>
>> >>> What causes the triple fault?
>> >>>
>> >> Are you asking what is triple fault or why it happened in your case?
>> What I asked is why triple fault happened in my case.
>> >> For the former see here: http://en.wikipedia.org/wiki/Triple_fault
>> >> For the later it is to late to tell after VM reset. You can run
>> >> QEMU with -no-reboot -no-shutdown. VM will pause instead of
>> >> rebooting and then you can examine what is going on.
>> Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM
>> paused in my case, what should I examined?
>>
>Register state "info registers" in the monitor for each vcpu. Code around the
>instruction that faulted.
I ran the QEMU with -no-reboot -no-shutdown options, the VM paused When the
case happened, then I info registers in QEMU monitor, shown as below,
CS =0008 00c09b00 DPL =0 CS32 [-RA]
SS =0010 00c09300 DPL =0 DS [-WA]
DS =0023 00c0f300 DPL =3 DS [-WA]
FS =0030 ffdff000 1fff 00c09300 DPL =0 DS [-WA]
GS = 00c0
LDT= 00c0
TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy
GDT= 8003f000 03ff
IDT= 8003f400 07ff
CR0=8001003b CR2=760d7fe4 CR3=002ec000 CR4=06f8
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=0800
FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0= FPR1=
FPR2= FPR3=
FPR4= FPR5=
FPR6= FPR7=
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06= XMM07=
In normal case, info registers in QEMU monitor, shown as below
CS =001b 00c0fb00 DPL=3 CS32 [-RA]
SS =0023 00c0f300 DPL=3 DS [-WA]
DS =0023 00c0f300 DPL=3 DS [-WA]
FS =0038 7ffda000 0fff 0040f300 DPL=3 DS [-WA]
GS = 0100
LDT=
TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy
GDT= 8003f000 03ff
IDT= 8003f400 07ff
CR0=80010031 CR2=0167fd20 CR3=0af00220 CR4=06f8
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EF
reply: reply: [Qemu-devel] qemu crashed when starting vm(kvm) with vnc connect
On Sun, Apr 07, 2013 at 04:58:07AM +, Zhanghaoyu (A) wrote: > >>> I start a kvm VM with vnc(using the zrle protocol) connect, sometimes > >>> qemu program crashed during starting period, received signal SIGABRT. > >>> Trying about 20 times, this crash may be reproduced. > >>> I guess the cause memory corruption or double free. > >> > >> Which version of QEMU are you running? > >> > >> Please try qemu.git/master. > >> > >> Stefan > > > >I used the QEMU download from qemu.git (http://git.qemu.org/git/qemu.git). > > Great, thanks! Can you please post a backtrace? > > The easiest way is: > > $ ulimit -c unlimited > $ qemu-system-x86_64 -enable-kvm -m 1024 ... > ...crash... > $ gdb -c qemu-system-x86_64.core > (gdb) bt > > Depending on how your system is configured the core file might have a > different filename but there should be a file name *core* the current working > directory after the crash. > > The backtrace will make it possible to find out where the crash occurred. > > Thanks, > Stefan backtrace from core file is shown as below: Program received signal SIGABRT, Aborted. 0x7f32eda3dd95 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x7f32eda3dd95 in raise () from /lib64/libc.so.6 #1 0x7f32eda3f2ab in abort () from /lib64/libc.so.6 #2 0x7f32eda77ece in __libc_message () from /lib64/libc.so.6 #3 0x7f32eda7dc06 in malloc_printerr () from /lib64/libc.so.6 #4 0x7f32eda7ecda in _int_free () from /lib64/libc.so.6 #5 0x7f32efd3452c in free_and_trace (mem=0x7f329cd0) at vl.c:2880 #6 0x7f32efd251a1 in buffer_free (buffer=0x7f32f0c82890) at ui/vnc.c:505 #7 0x7f32efd20c56 in vnc_zrle_clear (vs=0x7f32f0c762d0) at ui/vnc-enc-zrle.c:364 #8 0x7f32efd26d07 in vnc_disconnect_finish (vs=0x7f32f0c762d0) at ui/vnc.c:1050 #9 0x7f32efd275c5 in vnc_client_read (opaque=0x7f32f0c762d0) at ui/vnc.c:1349 #10 0x7f32efcb397c in qemu_iohandler_poll (readfds=0x7f32f074d020, writefds=0x7f32f074d0a0, xfds=0x7f32f074d120, ret=1) at iohandler.c:124 #11 0x7f32efcb46e8 in main_loop_wait (nonblocking=0) at main-loop.c:417 #12 0x7f32efd31159 in main_loop () at vl.c:2133 #13 0x7f32efd38070 in main (argc=46, argv=0x7fff7f5df178, envp=0x7fff7f5df2f0) at vl.c:4481 Zhang Haoyu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
KVM VM(rhel-5.5) %si is too high when TX/RX packets
I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1), and direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the other host via iperf tool, top tool result on VM shown that the %si is too high, approximately 95% ~ 100%, but from the view of host, the VM's total CPU usage is about 20% - 30%. And the throughput rate is approximately 200Mb/s, far from the line rate 1Gb/s, And, I found the hardirq rate is lower than normal by running "watch -d -n 1 cat /proc/interrupts", I think it's caused by the too high %si, because the NIC's hardirq was disabled during the softirq process. Then, I direct-assign the intel 82576 to the VM, the same case happened too. I found the intel 82576 and intel 82576 VF's interrupt mode are both PCI-MSI-X. And, I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the %si is approximately 20% -30%, and the throughput rate came to the line rate, about 940Mb/s. I update the VM to RHEL-6.1, the problem disappeared too. And, I found a very strange thing, the VM's 82576VF's irq routing is set one time on Vf's one interrupt received, so frequently. Thanks, Zhang Haoyu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(rhel-5.5) %si is too high when TX/RX packets
> I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1), and > direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the other > host via iperf tool, top tool result on VM shown that the %si is too high, > approximately 95% ~ 100%, but from the view of host, the VM's total CPU usage > is about 20% - 30%. And the throughput rate is approximately 200Mb/s, far > from the line rate 1Gb/s, And, I found the hardirq rate is lower than normal > by running "watch -d -n 1 cat /proc/interrupts", I think it's caused by the > too high %si, because the NIC's hardirq was disabled during the softirq > process. > Then, I direct-assign the intel 82576 to the VM, the same case happened too. > I found the intel 82576 and intel 82576 VF's interrupt mode are both > PCI-MSI-X. > > And, > I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the > parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the > %si is approximately 20% -30%, and the throughput rate came to the line rate, > about 940Mb/s. > I update the VM to RHEL-6.1, the problem disappeared too. > And, I found a very strange thing, the VM's 82576VF's irq routing is set one > time on Vf's one interrupt received, so frequently. With regard to rhel-5.5(linux-2.6.18), in ISR process, mask and unmask msi-x vector function msi_set_mask_bit() was invoked every time, which result in VMEXIT, then QEMU will invoke kvm_irqchip_update_msi_route() to ask KVM hypervisor to update the VM irq routing table. In KVM hypervisor, synchronizing process needed after updating routing table, so much time consumed for waiting in wait_rcu_gp(). So %si in VM is so high, while from the view of host, VM's total CPU usage is so low. Why in ISR process, masking and unmasking msi-x vector is needed every time? Thanks, Zhang Haoyu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(rhel-5.5) %si is too high when TX/RX packets
>> I running a VM(RHEL-5.5) on KVM hypervisor(linux-3.8 + QEMU-1.4.1),
>> and direct-assign intel 82576 VF to the VM. When TX/RX packets on VM to the
>> other host via iperf tool, top tool result on VM shown that the %si is too
>> high, approximately 95% ~ 100%, but from the view of host, the VM's total
>> CPU usage is about 20% - 30%. And the throughput rate is approximately
>> 200Mb/s, far from the line rate 1Gb/s, And, I found the hardirq rate is
>> lower than normal by running "watch -d -n 1 cat /proc/interrupts", I think
>> it's caused by the too high %si, because the NIC's hardirq was disabled
>> during the softirq process.
>> Then, I direct-assign the intel 82576 to the VM, the same case happened too.
>> I found the intel 82576 and intel 82576 VF's interrupt mode are both
>> PCI-MSI-X.
>>
>> And,
>> I rmmod the igb driver, and, re-insmod the igb driver(igb-4.1.2) with the
>> parameter IntMode=0/1(0:legacy, 1:MSI, 2:MSI-x), the problem then gone, the
>> %si is approximately 20% -30%, and the throughput rate came to the line
>> rate, about 940Mb/s.
>> I update the VM to RHEL-6.1, the problem disappeared too.
>> And, I found a very strange thing, the VM's 82576VF's irq routing is set one
>> time on Vf's one interrupt received, so frequently.
>
>RHEL 5.5 is a very old update. Can you try RHEL 5.9?
>
>In any case, this looks a lot like a bug in the version of the driver that was
>included in RHEL5.5; you should contact Red Hat support services if you can
>still reproduce it with the latest RHEL5 update.
>
>Paolo
One patch has been proposed to QEMU, shown as below,
[PATCH] [KVM] Needless to update msi route when only msi-x entry "control"
section changed
With regard to old version linux guest(e.g., rhel-5.5), in ISR processing, mask
and unmask msi-x vector every time, which result in VMEXIT, then QEMU will
invoke kvm_irqchip_update_msi_route() to ask KVM hypervisor to update the VM
irq routing table. In KVM hypervisor, synchronizing RCU needed after updating
routing table, so much time consumed for waiting in wait_rcu_gp(). So CPU usage
in VM is so high, while from the view of host, VM's total CPU usage is so low.
Masking/unmasking msi-x vector only set msi-x entry "control" section, needless
to update VM irq routing table.
hw/i386/kvm/pci-assign.c | 3 +++
1 files changed, 3 insertions(+)
--- a/hw/i386/kvm/pci-assign.c 2013-05-04 15:53:18.0 +0800
+++ b/hw/i386/kvm/pci-assign.c 2013-05-04 15:50:46.0 +0800
@@ -1576,6 +1576,8 @@ static void assigned_dev_msix_mmio_write
MSIMessage msg;
int ret;
+/* Needless to update msi route when only msi-x entry
"control" section changed */
+if ((addr & (PCI_MSIX_ENTRY_SIZE - 1)) !=
PCI_MSIX_ENTRY_VECTOR_CTRL){
msg.address = entry->addr_lo |
((uint64_t)entry->addr_hi << 32);
msg.data = entry->data; @@ -1585,6 +1587,7 @@ static void
assigned_dev_msix_mmio_write
if (ret) {
error_report("Error updating irq routing entry (%d)", ret);
}
+}
}
}
}
Thanks,
Zhang Haoyu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
>> >> >> On Thu, Apr 18, 2013 at 12:00:49PM +0000, Zhanghaoyu (A) wrote:
>> >> >>> I start 10 VMs(windows xp), then running geekbench tool on
>> >> >>> them, about 2 days, one of them was reset, I found the reset
>> >> >>> operation is done by int kvm_cpu_exec(CPUArchState *env) {
>> >> >>>...
>> >> >>> switch (run->exit_reason)
>> >> >>> ...
>> >> >>>case KVM_EXIT_SHUTDOWN:
>> >> >>>DPRINTF("shutdown\n");
>> >> >>>qemu_system_reset_request();
>> >> >>>ret = EXCP_INTERRUPT;
>> >> >>>break;
>> >> >>>...
>> >> >>> }
>> >> >>>
>> >> >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault
>> >> >>> handle handle_triple_fault().
>> >> >>>
>> >> >> How do you know that reset was done here? This is not the only
>> >> >> place where qemu_system_reset_request() is called.
>> >> I used gdb to debug QEMU process, and add a breakpoint in
>> >> qemu_system_reset_request(), when the case occurred, backtrace
>> >> shown as below,
>> >> (gdb) bt
>> >> #0 qemu_system_reset_request () at vl.c:1964
>> >> #1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100)
>> >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602
>> >> #2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100)
>> >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759
>> >> #3 0x7f9ef898b5f0 in start_thread () from
>> >> /lib64/libpthread.so.0
>> >> #4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6
>> >> #5 0x in ?? ()
>> >>
>> >> And, I add printk log in all places where KVM_EXIT_SHUTDOWN exit reason
>> >> is set, only handle_triple_fault() was called.
>> >> >
>> >> >Make sure XP is not set to auto-reset in case of BSOD.
>> >> No, winxp is not set to auto-reset in case of BSOD. No Winxp event log
>> >> reported.
>> >> >
>> >> >Best regards,
>> >> >Yan.
>> >> >
>> >> >>
>> >> >>> What causes the triple fault?
>> >> >>>
>> >> >> Are you asking what is triple fault or why it happened in your case?
>> >> What I asked is why triple fault happened in my case.
>> >> >> For the former see here:
>> >> >> http://en.wikipedia.org/wiki/Triple_fault
>> >> >> For the later it is to late to tell after VM reset. You can run
>> >> >> QEMU with -no-reboot -no-shutdown. VM will pause instead of
>> >> >> rebooting and then you can examine what is going on.
>> >> Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM
>> >> paused in my case, what should I examined?
>> >>
>> >Register state "info registers" in the monitor for each vcpu. Code around
>> >the instruction that faulted.
>>
>> I ran the QEMU with -no-reboot -no-shutdown options, the VM paused
>> When the case happened, then I info registers in QEMU monitor, shown as
>> below, CS =0008 00c09b00 DPL =0 CS32 [-RA]
>> SS =0010 00c09300 DPL =0 DS [-WA]
>> DS =0023 00c0f300 DPL =3 DS [-WA]
>> FS =0030 ffdff000 1fff 00c09300 DPL =0 DS [-WA]
>> GS = 00c0
>> LDT= 00c0
>> TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy
>> GDT= 8003f000 03ff
>> IDT= 8003f400 07ff
>> CR0=8001003b CR2=760d7fe4 CR3=002ec000 CR4=06f8
>> DR0= DR1= DR2=
>> DR3= DR6=0ff0 DR7=0400
>> EFER=0800 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80
>> FPR0= FPR1=
>> FPR2= FPR3=
>> FPR4= FPR5=
>> FPR6= FPR7=
>> XMM00=
>> XMM01=
>> XMM02=
>> XMM03=
>&g
ps2esdi maintainer?
Hello, I am trying to contact the ps2esdi maintainer, as I have some questions about the driver. I have an ancient PS/2 Thinkpad that gives an annoying but cosmetic error when it boots. I contacted David Weinehall earlier, but he isn't sure who the mainainer is. Thanks, Hal Duston [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
cool dev help..
cool write up.. http://www.linuxdoc.org/LDP/tlk/tlk.html but i just had 1 question: is there anything similar to what microsoft has pulled of with msdn in the linux world? i mean there is man and all, but is there anything more "user friendly" and in the digital means besides Beg. Linux Programming (2nd edition)? it would be really cool, if someone could point me out to something if it existed... laterz, akbar A. "you must find out what is already known, lest you waste your time doing poorly what others have done well." page 29- "The Practice of Programming" ;vertexabuse.cjb.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 randomly hangs up
Here too. :(( My CPU: Pentium 150 (NO overclock). 64 MB RAM. Linux freeze (no keyboard, no disk activity) 5-10 minutes after I load X. No freezing with other 2.4.0-testxx kernels. Please note: I'm not subscribed. Ciao Ale -- Alessandro Airaghi | e-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED] | | home page: http://web.tiscalinet.it/airaghi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PS/2 Esdi patch #8
Jens Axboe wrote: > > --snip-- > > and so it continues. This is the easy way to process requests. However, > if you can start I/O on more than one buffer at the time (scatter > gather), you could then setup your sg tables by browsing the entire > request buffer_head list and initiate I/O as needed. > > Bigger requests on the queue, means more I/O in progress being possible. > There's no rule that you have to finish a request in one go, so even if > you can only handle eg 64 sectors per request with sg, you could do > just start I/O on as many segments as you can and simply don't dequeue > the request until it's completely done. So the max_sectors patch is > never really needed if you know what you are doing. Can I still gain any advantage if the hardware can only have one I/O inflight per device? I am not sure the ps2esdi interface supports this. Hal Duston [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS/2 Esdi patch #8
Jens Axboe wrote: > On Thu, May 24 2001, Paul Gortmaker wrote: > > Hal Duston wrote: > > > > > http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.4-patch4 > > > > > > Hal Duston > > > [EMAIL PROTECTED] > > > > You PS/2 ESDI guys might want to set the max sectors for your > > driver - old default used to be 128, currently 255 (which maybe > > hardware can handle ok?) - the xd and hd drivers were broken until > > a similar fix was added to them. > > > > Probably makes sense for driver to set it regardless, seeing > > as default (MAX_SECTORS) has changed several times over last > > few months. At least then it will be under driver control > > and not at the mercy of some global value. > > You might want to assign that max_sect array too, otherwise it's just > going to waste space :-) > > Take a look at how ps2esdi handles requests -- always processing just > the first segment. Alas, it doesn't matter how big the request is. OK, obviously I am still missing something here from when I got the driver booting again. Presumably something with current_nr_sectors, vs nr_sectors, maybe? I thought it was odd that all the transfers were exactly 2 blocks. I'll go ahead and take this one. I will also go ahead and check to see how much data the hardware can transfer at once as well, but I expect it is quite a bit. I am still working on getting a group of folks to test patch #5 to see if it works as well. Anyone with appropriate hardware willing to test can contact me. All I have access to is my thinkpad 700 PS/2, and a 50Z that is a 286. Thanks, Hal Duston [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Need help in understanding x86 syscall
I had this question. As per my understanding, in the Linux system call implementation on x86 architecture the call flows like this int 0x80 -> syscall -> sys_call_vector(taken from the table)-> return from interrupt service routine. Now I had the doubt that if the the syscall implementation is very large will the scheduling and other interrupts be blocked for the whole time till the process returns from the ISR (because in an ISR by default the interrupts are disabled unless sti is called explicitly)? Thats appears to be too long for the scheduling or other interrupts to be blocked? Am I missing something here? Thanks Ukil __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Cosmetic JFFS patch.
Linus Torvalds hath spoken:
> I don't _have_ any instances of my name being printed out to annoy the
> user, so that's a very theoretical argument.
There is, of course, only one way to be fair about this.
And that is to apply this patch to init/main.c:
518a519
> printk("Linux is a registered trademark of Linus Torvalds.\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Read-only memory on x86?
Probably it is somewhere hidden on a faq.. but I will ask again ... Can I set a memory area or "page" to be read-only, i.e. generate an interrupt when writing is attempted to a certain page/area? Thanks, Antonio = Antonio Dell'elce * http://www.dellelce.com/MyHome/ [EMAIL PROTECTED] * NET2S Ltd., London __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 Q: list of open files per inode?
Al, I'm using the open/close call as a way for processes to register/unregister with a watchdog driver that I'm writing. I thought that I can save the housekeeping within the driver, but it looks like It would be easier just to maintain my own list and be done with it. Jacob - Original Message From: Al Viro <[EMAIL PROTECTED]> To: Jan Engelhardt <[EMAIL PROTECTED]> Cc: Jacob A <[EMAIL PROTECTED]>; linux-kernel@vger.kernel.org Sent: Thursday, July 19, 2007 7:38:10 PM Subject: Re: 2.4 Q: list of open files per inode? On Thu, Jul 19, 2007 at 01:41:03PM +0200, Jan Engelhardt wrote: > > On Jul 19 2007 02:01, Jacob A wrote: > > > > How can a device driver go over the list of all the files that are open on > > a > > specific inode instance? > > pseudo-code: > > task_list_lock; > for each process; do > lock_fdtable; > for each filedescriptor; do > do_something(fd->file_ptr); > unlock_fdtable; > task_list_unlock; Not again... There are other things that can keep file open. SCM_RIGHTS, references held by syscall in progress, etc., etc. The real question is why does driver want to do that? Details, please... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 Q: list of open files per inode?
I want to keep an internal state per each registration instance, and I opted to use open() as the registration mechanism. -Jacob - Original Message From: Jan Engelhardt <[EMAIL PROTECTED]> To: Jacob A <[EMAIL PROTECTED]> Cc: Al Viro <[EMAIL PROTECTED]>; linux-kernel@vger.kernel.org Sent: Sunday, July 22, 2007 2:58:18 PM Subject: Re: 2.4 Q: list of open files per inode? On Jul 22 2007 04:39, Jacob A wrote: >I'm using the open/close call as a way for processes to >register/unregister with a watchdog driver that I'm writing. I >thought that I can save the housekeeping within the driver, but it >looks like It would be easier just to maintain my own list and be >done with it. Sounds a bit wrong. _What_ exactly do you want to keep? Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 Q: list of open files per inode?
Ah, yes, this was my intention, to keep the state in filp->private_data. But then at a timer routine I wanted to go over all the filps associated with the device and check/modify the state. That's why I needed the open files list. -Jacob - Original Message From: Jan Engelhardt <[EMAIL PROTECTED]> To: Jacob A <[EMAIL PROTECTED]> Cc: Al Viro <[EMAIL PROTECTED]>; linux-kernel@vger.kernel.org Sent: Sunday, July 22, 2007 3:28:30 PM Subject: Re: 2.4 Q: list of open files per inode? On Jul 22 2007 05:26, Jacob A wrote: >I want to keep an internal state per each registration instance, and I opted >to use open() as the registration mechanism. So why not just store it in filp->private_data? Jan -- > Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question regarding ADS7846 Touchscreen controller
Hi All, We are running vanilla 2.6.22 linux kernel in i.MX 21 lite kit, patched for our board and utilizing the generic touchscreen driver drivers/input/touchscreen/ads7846.c for our touch screen. We have changed the register values in spi_imx.c for i.MX21. The code seems to run but we are not getting correct values for the touchscreen positions. The SPI registers always return a value of 4096. We have checked for correct clock. But still it does not help. Has anybody faced a similar problem before? Thanks, Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Testing of CPRM on SD Card
Hi All, Our product development requires that we use the CPRM security feature of SD card for protecting our material. I have been searching the web for a SD host controller / Software which is CPRM capable, so that we can write/read an encrypted SD card with the testing keys provided by the 4C Entity) and test our prototype. But I could find none. There are IP cores but no manufactured chips. Has anybody of you done similar stuff ? How do I go about testing the CPRM feature of the SD card on our prototype ? Thanks, Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Testing of CPRM on SD Card
Hey All, Thanks a lot for the replies. I have the development keys. But the algorithm and some intellectual property needs to be licenced from the 4C entity guys to implement it. As of now I just want to test the CPRM functionality. So licensing the algo for a prototype testing is a huge cost. That is why I was looking for an already implemented solution - hardware/software - so that I can just test. If it does not suite our needs, then I have just paid for a chip only and not for a whole license. Seems like there is no other way out than shelling out money for the license. :( Thanks anyways, Midhun. On 7/30/07, Alan Cox <[EMAIL PROTECTED]> wrote: > On Mon, 30 Jul 2007 11:20:58 +0530 > "Sriram, Kannan" <[EMAIL PROTECTED]> wrote: > > > > > Midhun, > > > > There is no open-source implementation of CPRM (SD-Audio/ SD-Bind > > standards). So first of all, you need to license keys from 4C (device > > keys, media keys etc) and do your own implementation. > > Also remember that if you do your own implementation in the kernel you > will be required to publish the source code under the GPL and that will > not be permitted with the CPRM licensing. Thus you will need to do all > the work in user space. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't unload uhci_hcd module with 2.6.22 -- also oops
Hello, To send a fax using an external usb modem, I do the following: modprobe uhci-hcd modprobe cdc-acm mount -t usbfs none /proc/bus/usb Then I send the fax. However, when I attempt to unload the modules by reversing the above steps, then uhci_hcd module will not unload: [/]# rmmod uhci-hcd ERROR: Removing 'uhci_hcd': Device or resource busy Using lsof to list all open files gives the following: ksuspend_ 766 root cwd DIR8,1 456 2 / ksuspend_ 766 root rtd DIR8,1 456 2 / ksuspend_ 766 root txt unknown /proc/766/exe khubd 769 root cwd DIR8,1 456 2 / khubd 769 root rtd DIR8,1 456 2 / khubd 769 root txt unknown /proc/769/exe I cannot terminate these processes. Also, the kernel log shows an oops: kernel: usbcore: deregistering interface driver cdc_acm kernel: uhci_hcd :00:1d.3: remove, state 1 kernel: usb usb4: USB disconnect, address 1 kernel: uhci_hcd :00:1d.3: USB bus 4 deregistered kernel: ACPI: PCI interrupt for device :00:1d.3 disabled kernel: uhci_hcd :00:1d.2: remove, state 1 kernel: usb usb3: USB disconnect, address 1 kernel: uhci_hcd :00:1d.2: USB bus 3 deregistered kernel: ACPI: PCI interrupt for device :00:1d.2 disabled kernel: uhci_hcd :00:1d.1: remove, state 1 kernel: usb usb2: USB disconnect, address 1 kernel: usb 2-2: USB disconnect, address 2 kernel: Unable to handle kernel paging request at 88040440 RIP: kernel: [sysfs_get_name+46/65] sysfs_get_name+0x2e/0x41 kernel: PGD 203067 PUD 205063 PMD 7a6b2067 PTE 0 kernel: Oops: [1] SMP kernel: CPU 1 kernel: Modules linked in: uhci_hcd usbcore af_packet skge bitrev crc32 kernel: Pid: 1123, comm: rmmod Not tainted 2.6.22 #3 kernel: RIP: 0010:[sysfs_get_name+46/65] [sysfs_get_name+46/65] sysfs_get_name+0x2e/0x41 kernel: RSP: 0018:81006edd5ce0 EFLAGS: 00010246 kernel: RAX: 88040440 RBX: 81006fbb68e0 RCX: kernel: RDX: 0004 RSI: 80423b38 RDI: 81006fbb6b88 kernel: RBP: 81006fbb6b88 R08: R09: 8000 kernel: R10: 0080 R11: 80330606 R12: 81006fbb6b90 kernel: R13: 81006f414c78 R14: 80423b38 R15: 8803b940 kernel: FS: 2b93765b76f0() GS:810002f4d140() knlGS: kernel: CS: 0010 DS: ES: CR0: 8005003b kernel: CR2: 88040440 CR3: 6f5e5000 CR4: 06e0 kernel: Process rmmod (pid: 1123, threadinfo 81006edd4000, task 81006e48ae40) kernel: Stack: 8029b6dd 81006fbb0420 81006fbb05a0 8100784a9800 kernel: 81006fbb0510 8100784a9888 80330986 81006fbb0400 kernel: 81006fbb0400 81006fbb0420 80330b95 81006fbb0400 kernel: Call Trace: kernel: [sysfs_hash_and_remove+104/295] sysfs_hash_and_remove+0x68/0x127 kernel: [device_remove_file+37/58] device_remove_file+0x25/0x3a kernel: [device_del+375/704] device_del+0x177/0x2c0 kernel: [_end+129064639/2131730856] :usbcore:usb_disable_device+0x8c/0x106 kernel: [_end+129049073/2131730856] :usbcore:usb_disconnect+0x98/0xee kernel: [_end+129049053/2131730856] :usbcore:usb_disconnect+0x84/0xee kernel: [_end+129057037/2131730856] :usbcore:usb_remove_hcd+0x85/0xe1 kernel: [_end+129097874/2131730856] :usbcore:usb_hcd_pci_remove+0x1d/0x89 kernel: [pci_device_remove+36/77] pci_device_remove+0x24/0x4d kernel: [__device_release_driver+130/184] __device_release_driver+0x82/0xb8 kernel: [driver_detach+252/261] driver_detach+0xfc/0x105 kernel: [bus_remove_driver+122/157] bus_remove_driver+0x7a/0x9d kernel: [pci_unregister_driver+16/129] pci_unregister_driver+0x10/0x81 kernel: [_end+129186684/2131730856] :uhci_hcd:uhci_hcd_cleanup+0x10/0x2c kernel: [sys_delete_module+319/444] sys_delete_module+0x13f/0x1bc kernel: [__up_write+29/318] __up_write+0x1d/0x13e kernel: [system_call+126/131] system_call+0x7e/0x83 kernel: kernel: kernel: Code: 48 8b 00 c3 83 fa 20 74 f7 31 c0 0f 1f 00 c3 0f 0b eb fe 41 kernel: RIP [sysfs_get_name+46/65] sysfs_get_name+0x2e/0x41 kernel: RSP kernel: CR2: 88040440 My system is Intel Pentium D dual core with Asus P5WD2 motherboard. Please CC to my personal address as I am not subscribed to the list. Andrew Kalten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't unload uhci_hcd module with 2.6.22 -- also oops
On Mon, 30 Jul 2007 18:09:23 -0400 (EDT) Alan Stern <[EMAIL PROTECTED]> wrote: > On Mon, 30 Jul 2007, Gabriel C wrote: > > > A. Kalten wrote: > > [ added usb peoples to CC ] > > > Hello, > > > > > > To send a fax using an external usb modem, I do the following: > > > > > > modprobe uhci-hcd > > > modprobe cdc-acm > > > mount -t usbfs none /proc/bus/usb > > > > > > Then I send the fax. > > > > > > However, when I attempt to unload the modules by reversing > > > the above steps, then uhci_hcd module will not unload: > > > > > > [/]# rmmod uhci-hcd > > > ERROR: Removing 'uhci_hcd': Device or resource busy > > > > > > Using lsof to list all open files gives the following: > > > > > > ksuspend_ 766 root cwd DIR8,1 456 2 / > > > ksuspend_ 766 root rtd DIR8,1 456 2 / > > > ksuspend_ 766 root txt unknown > > > /proc/766/exe > > > khubd 769 root cwd DIR8,1 456 2 / > > > khubd 769 root rtd DIR8,1 456 2 / > > > khubd 769 root txt unknown > > > /proc/769/exe > > > > > > I cannot terminate these processes. > > You're not supposed to be able to terminate them. > > > > Also, the kernel log shows an oops: > > > > > > kernel: usbcore: deregistering interface driver cdc_acm > > > kernel: uhci_hcd :00:1d.3: remove, state 1 > > > kernel: usb usb4: USB disconnect, address 1 > > > kernel: uhci_hcd :00:1d.3: USB bus 4 deregistered > > > kernel: ACPI: PCI interrupt for device :00:1d.3 disabled > > > kernel: uhci_hcd :00:1d.2: remove, state 1 > > > kernel: usb usb3: USB disconnect, address 1 > > > kernel: uhci_hcd :00:1d.2: USB bus 3 deregistered > > > kernel: ACPI: PCI interrupt for device :00:1d.2 disabled > > > kernel: uhci_hcd :00:1d.1: remove, state 1 > > > kernel: usb usb2: USB disconnect, address 1 > > > kernel: usb 2-2: USB disconnect, address 2 > > > kernel: Unable to handle kernel paging request at 88040440 RIP: > > > kernel: [sysfs_get_name+46/65] sysfs_get_name+0x2e/0x41 > > > kernel: PGD 203067 PUD 205063 PMD 7a6b2067 PTE 0 > > > kernel: Oops: [1] SMP > > > kernel: CPU 1 > > > kernel: Modules linked in: uhci_hcd usbcore af_packet skge bitrev crc32 > > > kernel: Pid: 1123, comm: rmmod Not tainted 2.6.22 #3 > > > kernel: RIP: 0010:[sysfs_get_name+46/65] [sysfs_get_name+46/65] > > > sysfs_get_name+0x2e/0x41 > > > kernel: RSP: 0018:81006edd5ce0 EFLAGS: 00010246 > > > kernel: RAX: 88040440 RBX: 81006fbb68e0 RCX: > > > kernel: RDX: 0004 RSI: 80423b38 RDI: 81006fbb6b88 > > > kernel: RBP: 81006fbb6b88 R08: R09: 8000 > > > kernel: R10: 0080 R11: 80330606 R12: 81006fbb6b90 > > > kernel: R13: 81006f414c78 R14: 80423b38 R15: 8803b940 > > > kernel: FS: 2b93765b76f0() GS:810002f4d140() > > > knlGS: > > > kernel: CS: 0010 DS: ES: CR0: 8005003b > > > kernel: CR2: 88040440 CR3: 6f5e5000 CR4: 06e0 > > > kernel: Process rmmod (pid: 1123, threadinfo 81006edd4000, task > > > 81006e48ae40) > > > kernel: Stack: 8029b6dd 81006fbb0420 81006fbb05a0 > > > 8100784a9800 > > > kernel: 81006fbb0510 8100784a9888 80330986 > > > 81006fbb0400 > > > kernel: 81006fbb0400 81006fbb0420 80330b95 > > > 81006fbb0400 > > > kernel: Call Trace: > > > kernel: [sysfs_hash_and_remove+104/295] sysfs_hash_and_remove+0x68/0x127 > > > kernel: [device_remove_file+37/58] device_remove_file+0x25/0x3a > > > kernel: [device_del+375/704] device_del+0x177/0x2c0 > > > kernel: [_end+129064639/2131730856] > > > :usbcore:usb_disable_device+0x8c/0x106 > > > kernel: [_end+129049073/2131730856] :usbcore:usb_disconnect+0x98/0xee > > > kernel: [_end+129049053/2131730856] :usbcore:usb_disconnect+0x84/0xee > > > kernel: [_end+129057037/2131730856] :usbcore:usb_remove_hcd+0x85/0xe1 > > > kernel: [_end+129097874/2131730856] :usbcore:usb_hcd_pci_re
USB HC on i.MX21 hangs with error -110
Hi All, We are using the i.MX21 Litekit. It has got a USB host port on it and the driver is imx21-hcd.c provided by the vendor. When I plug in a USB stick into the host port, the kernel hangs with the following error: usb 1-2: device descriptor read/64, error -110 I have read on the net that -110 means timeout error. Also there were suggestions to unload ehci-hcd module. But I do not have ehci-hcd built into my kernel. My kernel config for USB is: # # USB support # CONFIG_USB_ARCH_HAS_HCD=y # CONFIG_USB_ARCH_HAS_OHCI is not set # CONFIG_USB_ARCH_HAS_EHCI is not set CONFIG_USB=y # CONFIG_USB_DEBUG is not set The kernel boots with the following log on enabling CONFIG_USB_DEBUG. imx21_hcd_init:1838 imx21_probe:1765 imx21-hc imx21-hc.0: IMX21 USB Host Controller imx21-hc imx21-hc.0: new USB bus registered, assigned bus number 1 imx21_hc_reset:1430 imx21-hc imx21-hc.0: irq 55, io base 0x imx21_hc_start:1438 imx21_hc_start:1451 usb usb1: Product: IMX21 USB Host Controller usb usb1: Manufacturer: Linux 2.6.22 imx21-hc usb usb1: SerialNumber: imx21-hc.0 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found imx21_hc_hub_control:1579 GetHubDescriptor hub 1-0:1.0: 3 ports detected imx21_hc_hub_control:1579 GetHubStatus imx21_hc_hub_control:1579 SetPortFeature USB_PORT_FEAT_POWER imx21_hc_hub_control:1579 SetPortFeature USB_PORT_FEAT_POWER imx21_hc_hub_control:1579 SetPortFeature USB_PORT_FEAT_POWER >>usb_add_hcd - Exiting without error imx21_probe:1822 imx21_hc_hub_control:1579 GetPortStatus: port: 1, 0x100 imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x100 imx21_hc_hub_control:1579 GetPortStatus: port: 3, 0x100 The debug on plugging in the flash drive is: / # imx21_hc_hub_status_data:1555 port 1 (of 3): 0x10101 imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x10101 imx21_hc_hub_control:1579 ClearPortFeature USB_PORT_FEAT_C_CONNECTION imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x101 imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x101 imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x101 imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x101 imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x101 imx21_hc_hub_control:1579 SetPortFeature USB_PORT_FEAT_RESET hwmode = 0x202000a2 cint_stat = 0x cint_sten = 0x0001 clk_ctrl = 0x0003 rst_ctrl = 0x frm_intvl = 0x2a2f2edf frm_remain = 0x28cd hnp_csr = 0x20440200 hint_isr = 0x hnp_ien= 0x usbctrl= 0x000f1004 host_ctrl = 0x0008 sysisr = 0x0004 sysien= 0x xbufstat = 0x ybufstat = 0x xyinten = 0x xfillstat = 0x yfillstat = 0x etdenset = 0x etdenclr = 0x immedint = 0x etddonest = 0x etddoneen = 0x frmnub = 0x2f1e lsthresh = 0x0628 roothuba = 0x01000103 roothubb = 0x0007 rootstat = 0x portst1= 0x0100 portst2= 0x0101 portst3 = 0x0100 imx21_hc_hub_control:1579 GetPortStatus: port: 2, 0x100103 imx21_hc_hub_control:1579 ClearPortFeature USB_PORT_FEAT_C_RESET usb 1-2: new full speed USB device using imx21-hc and address 2 imx21_hc_urb_enqueue:1466 ep: c2d94034 ep->hcpriv: ep->urb_list: c2d94040 ep->descriptor: bEndpointAddress: 0 wMaxPacketSize: 64 urb: c2d524a0 ->dev->speed: FULL ->hcpriv: ->pipe: 0x8080 IN CTRL ->transfer_flags: 0x0 ->transfer_buffer: c2d734a0 ->transfer_dma: 0xc2d734a0 ->transfer_buffer_length: 64 ->setup_packet: c2cb1200 ->setup_dma: 0xc2cb1200 0x80 0x06 0x00 0x01 0x00 0x00 0x40 0x00 maxpacket: 64 imx21_irq:1403 imx21_irq:1413 etd(0): 0x0040 0x0040 0xf080 0x07e8 imx21_irq:1403 imx21_irq:1407 sh_done_list:1176 hc_parse_trans:1036 hc_parse_trans:1039 hc_parse_trans:1043 etd(0): 0x0840 0x0040 0x5380 0x07e8 hc_parse_trans:1113 hc_parse_trans:1144 hc_parse_trans:1152 urb: c2d524a0 ->dev->speed: FULL ->hcpriv: c2d4e160 ->pipe: 0x8082 IN CTRL ->transfer_flags: 0x0 ->transfer_buffer: c2d734a0 ->transfer_dma: 0xc2d734a0 ->transfer_buffer_length: 64 ->setup_packet: c2cb1200 ->setup_dma: 0xc2cb1200 0x80 0x06 0x00 0x01 0x00 0x00 0x40 0x00 maxpacket: 64 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_parse_trans:1036 hc_p
Re: USB HC on i.MX21 hangs with error -110
Hi All, Sorry for crossposting. > Let's see ... Linux-ARM is a "please don't crosspost" list; I did not know that. I will not repeat. I did not know which list to ask help for USB untill afterwards I found the linux-usb-users mailing list. Sorry again. Will not repeat. Thanks, Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DVD-RAM cannot be mounted RW with 2.6.18/2.6.19
Hello, DVD-RAM disks previously made with a Linux system can no longer be mounted in RW mode. For some reason, as indicated by the error message from the mount command, the disks are detected as being write-protected (which is not the case). To be able to write to these disks, the mount command must be issued again with the "-o remount" option. The commands given are as follows. Although the file type in this example is ext2, the same behavior is seen also with the udf file type. # modprobe ide-cd # hdparm -d1 -X udma4 -k1 /dev/hde # mount -t ext2 -o rw,noatime /dev/hde /cdrom mount: block device /dev/hde is write-protected, mounting read-only # mount -t ext2 -o remount,rw,noatime /dev/hde /cdrom Now the DVD-RAM disk can be written normally, but there should be no need for the second mount command. The kernel log for this command sequence seems to show nothing abnormal: kernel: hde: ATAPI 39X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) kernel: Uniform CD-ROM driver Revision: 3.20 kernel: hde: CHECK for good STATUS kernel: cdrom: hde: mrw address space DMA selected kernel: cdrom open: mrw_status 'not mrw' Furthermore, if I attempt to check the unmounted DVD-RAM disk with e2fsck, the drive is still reported as read-only: # e2fsck -p /dev/hde e2fsck: Read-only file system while trying to open /dev/hde Disk write-protected; use the -n option to do a read-only check of the device. However, as I indicated above, the disk is not write-protected. I am reporting this problem on the lkml because of a hint that I discovered at this link: http://lists.opensuse.org/packet-writing/2006-10/msg0.html Although this problem does not involve packet-writing, it may be related to the cdrom code. Andrew Kalten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 Q: list of open files per inode?
How can a device driver go over the list of all the files that are open on a specific inode instance? I'd like to avoid doing my own housekeeping. The question is about 2.4 kernel. Thanks, Jacob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
the most competitive price of solar water heaters for the international market
EN12976/ISO9806/Solar Keymark approved A9H high pressure solar water heater system Hi, It is my pleasure to introduce you the new products in 2017, model A9H, The high pressure solar hot water system, 1.EN12976/ISO9806 tested and Solar Keymark approved. 2.unique CPC reflectors, overheating solution, highest power output. 3.high pressure system 6bar, SUS316L inner tank, long time warranty, free maintenance, harmony building integration. 4.simple installation, low labors cost, most highest cost/performance solar system 5.100L,150L,180L,240L For more technical details and pricing, please contact with me. PS: 2017 new price list, please check it. See you at the Canton Fair 10.3G37-38, H07-08. best regards David Email: jasonso...@188.com 31463...@qq.com Mobile/WhatsApp: 0086-13511302877 skype: jasonzhsj
Re: [PATCH V2 1/3] perf,tools: get correct cpu id for print_aggr
Em Fri, Aug 28, 2015 at 01:33:22PM +, Liang, Kan escreveu:
> > On Thu, Jul 02, 2015 at 03:08:43AM -0400, kan.li...@intel.com wrote:
> > > From: Kan Liang
> > > print_aggr fails to print per-core/per-socket statistics after commit
> > > 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore
> > > events") if events have differnt cpus. Because in print_aggr,
> > > aggr_get_id needs index (not cpu id) to find core/pkg id. Also, evsel
> > > cpu maps should be used to get aggregated id.
> > > Signed-off-by: Kan Liang
> > Acked-by: Jiri Olsa
> Hi Arnaldo,
> Could you please merge this patch?
> This patch is to fix a bug of perf stat. It doesn't depend on
> other patches of the patchset, and can be merged by itself.
Right, in such cases, please, make it clear against which branch this
should be applied, i.e. if this is a longstanding bug that needs to go
to perf/urgent, i.e. to the current merge window, ASAP, or if this
is for something that was introduced in the current development branch,
perf/core.
In this case it needs to go to perf/urgent, where it applies cleanly,
perf/core has extra stuff there that fuzzes a bit.
Also, since you know the cset where this bug was introduced, please
consider adding a "Fixes:" tag, commom everywhere in the kernel:
[acme@zoo linux]$ git log | grep '^[ \t]\+Fixes:' | wc -l
3805
And we use it in tools/, sometime I add it while editing changelogs,
like in this patch:
[acme@zoo linux]$ git log tools/ | grep '^[ \t]\+Fixes:' | head -5
Fixes: 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore
events")
Fixes: b685ac22b436 ("perf symbols: Add front end cache for DSO symbol
lookup")
Fixes: 06b234ec26fd ("perf script: Don't assume evsel position of tracking
events")
Fixes: d4957633bf9d ("perf report: Add infrastructure for a cycles
histogram")
Fixes: 75186a9b09e4 ("perf probe: Fix to show lines of sys_ functions
correctly")
[acme@zoo linux]$
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
DONATION FOR YOU
Good Day, I am Mrs. Gloria C. Mackenzie, the Power-Ball Lottery winner and I have donated $2,000,000.00 USD to you. I saw your email in Kreditmarket were you were searching for a loan so i decided to get your email so i can help you with some amount so that you can start up a business on your own. I do apologize for sending you this unsolicited email, but your email was selected and submitted to my foundation after a successful Google & Facebook email-draws.See link for more proof; so here is the link of how the sum of $590 Million was transferred to me so CLICK on this link now to watch the video your self for prof. http://www.huffingtonpost.com/2013/06/05/590-million-jackpot-winner_n_3392040.html I will be waiting for your response now. Sincerely, Mrs. Gloria C. Mackenzie. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS / FuseFS Kernel Hangs Bug
Hello, I want to report a Bug with NFS / FuseFS. Theres trouble with mounting a NFS FS with FuseFS, if the NFS Server is slowly responding. The problem occurs, if you mount a NFS FS with FuseFS driver for example with this command: mount -t nfs -o vers=3,nfsvers=3,hard,intr,tcp server /dest Working on this nfs overlay works like a charm, as long as the NFS Server is not under heavy load. If it gets under HEAVY load from time to time the kernel hangs (which should in my opinion never ever occur). Heres a stacktrace: [468661.923371] INFO: task sync:2828 blocked for more than 120 seconds. [468661.924202] Not tainted 4.0.0 #2 [468661.924996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [468661.925806] syncD 0 2828 26428 0x [468661.926605] 880036d9cb70 8101c356 8800797a2af0 8101c3c5 [468661.927476] 88006312ffd8 7fff 88006312fea8 880036d9cb70 [468661.928426] 811f3440 81585e5f 88006312feb0 [468661.929269] Call Trace: [468661.930108] [] ? native_sched_clock+0x26/0x90 [468661.930975] [] ? sched_clock+0x5/0x10 [468661.931742] [] ? SyS_tee+0x390/0x390 [468661.932589] [] ? schedule+0x2f/0x80 [468661.94] [] ? schedule_timeout+0x21a/0x290 [468661.934069] [] ? insert_work+0x50/0xc0 [468661.934782] [] ? __queue_work+0x12b/0x340 [468661.935508] [] ? wait_for_completion+0xb0/0x120 [468661.936425] [] ? wake_up_state+0x20/0x20 [468661.937107] [] ? SyS_tee+0x390/0x390 [468661.937745] [] ? sync_inodes_sb+0xa3/0x1c0 [468661.938432] [] ? SyS_tee+0x390/0x390 [468661.939093] [] ? iterate_supers+0xac/0x100 [468661.939737] [] ? sys_sync+0x33/0xa0 [468661.940511] [] ? system_call_fastpath+0x16/0x1b [367651.029922] INFO: task kworker/u16:1:21362 blocked for more than 120 seconds. [367651.030722] Not tainted 4.0.0 #2 [367651.031497] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [367651.032364] kworker/u16:1 D 88107fcd4440 0 21362 2 0x [367651.033131] Workqueue: writeback bdi_writeback_workfn (flush-0:44) [367651.033882] 880efccacc30 881038a553d0 7fff [367651.034619] 88000e317fd8 88107ffaf090 88102c23c1a0 [367651.035440] 88102c23c270 0001057745ec 81585e5f 880302f0a1c8 [367651.036193] Call Trace: [367651.037021] [] ? schedule+0x2f/0x80 [367651.037745] [] ? inode_sleep_on_writeback+0x80/0xa0 [367651.038473] [] ? wait_woken+0x90/0x90 [367651.039176] [] ? wb_writeback+0x14a/0x2c0 [367651.039881] [] ? set_worker_desc+0x7e/0x90 [367651.040588] [] ? bdi_writeback_workfn+0x2a1/0x420 [367651.041308] [] ? process_one_work+0x14d/0x410 [367651.042035] [] ? worker_thread+0x6b/0x4a0 [367651.042716] [] ? rescuer_thread+0x310/0x310 [367651.043428] [] ? kthread+0xd3/0xf0 [367651.044718] [] ? kthread_create_on_node+0x180/0x180 [367651.045623] [] ? ret_from_fork+0x58/0x90 [367651.046409] [] ? kthread_create_on_node+0x180/0x180 I tried several kernel-versions, and all of them seems to be affected by this issue. I guess the timeout occurs somewhere inside the fusefs part in the kernel. Anyways even if the NFS Server is slowly/not responding the kernel should not hang in kernel space, should it? What i verified: This issue occurs on two different servers (clients), even on two diffrent NFS servers. Heres some env. stuff: cat /proc/version Linux version 4.0.0 (root@xxx) (gcc version 4.9.2 (Debian 4.9.2-10) ) #2 SMP Wed Aug 26 21:00:33 UTC 2015 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping: 4 microcode : 0x415 cpu MHz : 3700.000 cache size : 10240 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt bugs: bogomips: 7399.22 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: cat /proc/modules nfsv3 40960 1 - Live 0xa0a67000 veth 16384 0 - Live 0xa07d1000 xt_nat 16384 1 - Live 0xa07cc000 xt_tcpudp 16384 129 - Live 0xa07b8000 xt_addrtype 16384 4 - Live 0xfff
Re: NFS / FuseFS Kernel Hangs Bug
Hello, Okay, i was wrong with FUSE and NFS thanks for the hint. About the Problem: Without digging deep into the kernel sources, your explaination is more or less that was i thinking about whats happening. Anyways, the reason why i report the Problem is that during this 120 Seconds (until the Kernel solves this issue by killing (?) the process) the system is unusable. What i mean about it: Its not even possible to ssh on the server, even if /root and /home is local and should not be affected by the slow NFS Servers. Also it seems during this period a lot of network connections drop/freeze(?). Youre completly right when you says, theres no other way/its by design to wait for the NFS-Response. But in my point of view this 'wait' is happening on the wrong security level. If im not wrong the current implementation blocks/hangs tasks in kernelspace, or at least blocks the scheduler during this period. 2015-10-01 16:24 GMT+02:00 Austin S Hemmelgarn : > On 2015-10-01 09:06, sascha a. wrote: >> >> Hello, >> >> >> I want to report a Bug with NFS / FuseFS. >> >> Theres trouble with mounting a NFS FS with FuseFS, if the NFS Server >> is slowly responding. >> >> The problem occurs, if you mount a NFS FS with FuseFS driver for >> example with this command: >> >> mount -t nfs -o vers=3,nfsvers=3,hard,intr,tcp server /dest >> >> Working on this nfs overlay works like a charm, as long as the NFS >> Server is not under heavy load. If it gets under HEAVY load from time >> to time the kernel hangs (which should in my opinion never ever >> occur). > > OK, before I start on an explanation of why what is happening is happening, > I should note that unless you're using some special FUSE driver instead of > the regular NFS tools, you're not using FUSE to mount the NFS share, you're > using a regular kernel driver. > > Now, on to the explanation: > This behavior is expected and unavoidable for any network filesystem under > the described conditions. Sync (or any other command that causes access to > the filesystem that isn't served by the local cache) requires sending a > command to the server. Sync in particular is _synchronous_ (and it should > be, otherwise you break the implied data safety from using it), which means > that it will wait until it gets a reply from the server before it returns, > which means that if the server is heavily loaded (or just ridiculously > slow), it will be a while before it returns. On top of this, depending on > how the server is caching data, it may take a long time to return even on a > really fast server with no other load. > > The stacktrace you posted indicates simply that the kernel noticed that > 'sync' was in an I/O sleep state (the 'D state' it refers to) for more than > 120 seconds, which is the default detection timeout for this. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -next v3] mtd: spinand: fix missing unlock on error
>
> Hi Wei,
>
> Wei Yongjun wrote on Wed, 4 Jul 2018
> 09:30:27
> +:
>
> > Add the missing unlock before return from function
> > spinand_mtd_(read|write) in the error handling case.
> >
> > Fixes: c898e0526fb6 ("mtd: nand: Add core infrastructure to support SPI
> NANDs")
> > Signed-off-by: Wei Yongjun
> > ---
>
> Thanks for the two fixes over the spinand work. As this code is not
> yet upstream, do you mind if I fold those fixes directly with the
> initial patch?
No, I don't. Feel free to fold them to the initial patch.
Regards,
Wei yongjun
[PATCH] nvme-pci: fix dbbuf_sq_db point to freed memory
The case is that nvme device support NVME_CTRL_OACS_DBBUF_SUPP, and
return failed when the driver sent nvme_admin_dbbuf. The nvmeq->dbbuf_sq_db
point to freed memory, as nvme_dbbuf_set is called behind nvme_dbbuf_init.
Change-Id: Ief2a5877cb008d3c29cf99053f80fecc9b8db1db
Signed-off-by: lulina
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index da39729..2e11980 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -240,16 +240,25 @@ static int nvme_dbbuf_dma_alloc(struct nvme_dev *dev)
static void nvme_dbbuf_dma_free(struct nvme_dev *dev)
{
unsigned int mem_size = nvme_dbbuf_size(dev->db_stride);
+ unsigned int i;
if (dev->dbbuf_dbs) {
dma_free_coherent(dev->dev, mem_size,
dev->dbbuf_dbs, dev->dbbuf_dbs_dma_addr);
dev->dbbuf_dbs = NULL;
+ for (i = dev->ctrl.queue_count - 1; i > 0; i--) {
+ dev->queues[i]->dbbuf_sq_db = NULL;
+ dev->queues[i]->dbbuf_cq_db = NULL;
+ }
}
if (dev->dbbuf_eis) {
dma_free_coherent(dev->dev, mem_size,
dev->dbbuf_eis, dev->dbbuf_eis_dma_addr);
dev->dbbuf_eis = NULL;
+ for (i = dev->ctrl.queue_count - 1; i > 0; i--) {
+ dev->queues[i]->dbbuf_sq_ei = NULL;
+ dev->queues[i]->dbbuf_cq_ei = NULL;
+ }
}
}
--
1.8.3.1
[PATCH v2] nvme-pci: fix dbbuf_sq_db point to freed memory
The case is that nvme device support NVME_CTRL_OACS_DBBUF_SUPP, and
return failed when the driver sent nvme_admin_dbbuf. The nvmeq->dbbuf_sq_db
point to freed memory, as nvme_dbbuf_set is called after nvme_dbbuf_init.
Signed-off-by: lulina
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c33bb20..a477905 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -251,16 +251,25 @@ static int nvme_dbbuf_dma_alloc(struct nvme_dev *dev)
static void nvme_dbbuf_dma_free(struct nvme_dev *dev)
{
unsigned int mem_size = nvme_dbbuf_size(dev->db_stride);
+ unsigned int i;
if (dev->dbbuf_dbs) {
dma_free_coherent(dev->dev, mem_size,
dev->dbbuf_dbs, dev->dbbuf_dbs_dma_addr);
dev->dbbuf_dbs = NULL;
+ for (i = dev->ctrl.queue_count - 1; i > 0; i--) {
+ dev->queues[i].dbbuf_sq_db = NULL;
+ dev->queues[i].dbbuf_cq_db = NULL;
+ }
}
if (dev->dbbuf_eis) {
dma_free_coherent(dev->dev, mem_size,
dev->dbbuf_eis, dev->dbbuf_eis_dma_addr);
dev->dbbuf_eis = NULL;
+ for (i = dev->ctrl.queue_count - 1; i > 0; i--) {
+ dev->queues[i].dbbuf_sq_ei = NULL;
+ dev->queues[i].dbbuf_cq_ei = NULL;
+ }
}
}
--
1.8.3.1
Re: [PATCH v2] nvme-pci: fix dbbuf_sq_db point to freed memory
Thanks for replying to my email, my description in the last email was not clear enough, so here's a supplementary note. The NVME device I used support DBBUF, but the nvme_admin_dbbuf request returned a failure that eventually led to the kernel crash. The problem occurs as follows: 1, Device support NVME_CTRL_OACS_DBBUF_SUPP，so reset worker alloc memory for dev->dbbuf_dbs。 2, In nvme_setup_io_queues process, the nvme_dbbuf_init function is called to assign values to pointers such as nvmeq->dbbuf_sq_db. 3, In nvme_dev_add function, the nvme_admin_dbbuf request is sent to the device, but the device returns failed, so the memory that dev->dbbuf_dbs points to is released. Then, the driver issued IO requests, in the nvme_write_sq_db process, nvme_dbbuf_update_and_check_event function judgment to Nvmeq->dbbuf_sq_db pointer is not NULL, write to the memory it points to, causing memory confusion and kernel crash. On 2019/1/5 2:07, Christoph Hellwig wrote: > On Fri, Dec 21, 2018 at 01:07:25AM +, Lulina (A) wrote: >> The case is that nvme device support NVME_CTRL_OACS_DBBUF_SUPP, and >> return failed when the driver sent nvme_admin_dbbuf. The nvmeq->dbbuf_sq_db >> point to freed memory, as nvme_dbbuf_set is called after nvme_dbbuf_init. > > But we never use those pointers in that state, do we? Can you explain > the problem in a little more detail? > >
Let us work together!
Greetings, I`m Aston Morgan an officer of the U.S Army presently serving the US Army security forces in Kabul, Afghanistan. You may not know me but I really need your help as I have some very important packages to ship to you for safe keeping until the end of my mission here. I will only explain further upon receiving a positive response from you. Thanks.
Re: [PATCH -next] nilfs2: Fix typos in comments
Thanks for reviewing, I will exclude it in v2 patch and send out later. 在 2021/4/8 23:35, Ryusuke Konishi 写道: Hi, This patch partially overlaps the following fix that I previously sent to Andrew: https://lkml.org/lkml/2021/4/8/114 Can you exclude two typo fixes of "retured -> returned" from yours ? Thanks, Ryusuke Konishi On Thu, Apr 8, 2021 at 11:08 PM Lu Jialin wrote: numer -> number in fs/nilfs2/cpfile.c and fs/nilfs2/segment.c retured -> returned and Decription -> Description in fs/nilfs2/ioctl.c isntance -> instance in fs/nilfs2/the_nilfs.c No functionality changed. Signed-off-by: Lu Jialin --- fs/nilfs2/cpfile.c| 2 +- fs/nilfs2/ioctl.c | 6 +++--- fs/nilfs2/segment.c | 4 ++-- fs/nilfs2/the_nilfs.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/nilfs2/cpfile.c b/fs/nilfs2/cpfile.c index 025fb082575a..ce144776b4ef 100644 --- a/fs/nilfs2/cpfile.c +++ b/fs/nilfs2/cpfile.c @@ -293,7 +293,7 @@ void nilfs_cpfile_put_checkpoint(struct inode *cpfile, __u64 cno, * nilfs_cpfile_delete_checkpoints - delete checkpoints * @cpfile: inode of checkpoint file * @start: start checkpoint number - * @end: end checkpoint numer + * @end: end checkpoint number * * Description: nilfs_cpfile_delete_checkpoints() deletes the checkpoints in * the period from @start to @end, excluding @end itself. The checkpoints diff --git a/fs/nilfs2/ioctl.c b/fs/nilfs2/ioctl.c index b053b40315bf..cbb59a6c4b81 100644 --- a/fs/nilfs2/ioctl.c +++ b/fs/nilfs2/ioctl.c @@ -979,7 +979,7 @@ static int nilfs_ioctl_clean_segments(struct inode *inode, struct file *filp, * and metadata are written out to the device when it successfully * returned. * - * Return Value: On success, 0 is retured. On errors, one of the following + * Return Value: On success, 0 is returned. On errors, one of the following * negative error code is returned. * * %-EROFS - Read only filesystem. @@ -1058,7 +1058,7 @@ static int nilfs_ioctl_resize(struct inode *inode, struct file *filp, * @inode: inode object * @argp: pointer on argument from userspace * - * Decription: nilfs_ioctl_trim_fs is the FITRIM ioctl handle function. It + * Description: nilfs_ioctl_trim_fs is the FITRIM ioctl handle function. It * checks the arguments from userspace and calls nilfs_sufile_trim_fs, which * performs the actual trim operation. * @@ -1100,7 +1100,7 @@ static int nilfs_ioctl_trim_fs(struct inode *inode, void __user *argp) * @inode: inode object * @argp: pointer on argument from userspace * - * Decription: nilfs_ioctl_set_alloc_range() function defines lower limit + * Description: nilfs_ioctl_set_alloc_range() function defines lower limit * of segments in bytes and upper limit of segments in bytes. * The NILFS_IOCTL_SET_ALLOC_RANGE is used by nilfs_resize utility. * diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index cd4da9535aed..686c8ee7b29c 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -2214,7 +2214,7 @@ static void nilfs_segctor_wakeup(struct nilfs_sc_info *sci, int err) * nilfs_construct_segment - construct a logical segment * @sb: super block * - * Return Value: On success, 0 is retured. On errors, one of the following + * Return Value: On success, 0 is returned. On errors, one of the following * negative error code is returned. * * %-EROFS - Read only filesystem. @@ -2251,7 +2251,7 @@ int nilfs_construct_segment(struct super_block *sb) * @start: start byte offset * @end: end byte offset (inclusive) * - * Return Value: On success, 0 is retured. On errors, one of the following + * Return Value: On success, 0 is returned. On errors, one of the following * negative error code is returned. * * %-EROFS - Read only filesystem. diff --git a/fs/nilfs2/the_nilfs.c b/fs/nilfs2/the_nilfs.c index 221a1cc597f0..8b7b01a380ce 100644 --- a/fs/nilfs2/the_nilfs.c +++ b/fs/nilfs2/the_nilfs.c @@ -195,7 +195,7 @@ static int nilfs_store_log_cursor(struct the_nilfs *nilfs, /** * load_nilfs - load and recover the nilfs * @nilfs: the_nilfs structure to be released - * @sb: super block isntance used to recover past segment + * @sb: super block instance used to recover past segment * * load_nilfs() searches and load the latest super root, * attaches the last segment, and does recovery if needed. -- 2.17.1 .
Re: [PATCH] riscv/kprobe: fix kernel panic when invoking sys_read traced by kprobe
在 2021/4/8 19:20, Jisheng Zhang 写道: > On Tue, 30 Mar 2021 16:18:48 +0800 > Liao Chang wrote: > > >> >> The execution of sys_read end up hitting a BUG_ON() in __find_get_block >> after installing kprobe at sys_read, the BUG message like the following: >> >> [ 65.708663] [ cut here ] >> [ 65.709987] kernel BUG at fs/buffer.c:1251! >> [ 65.711283] Kernel BUG [#1] >> [ 65.712032] Modules linked in: >> [ 65.712925] CPU: 0 PID: 51 Comm: sh Not tainted 5.12.0-rc4 #1 >> [ 65.714407] Hardware name: riscv-virtio,qemu (DT) >> [ 65.715696] epc : __find_get_block+0x218/0x2c8 >> [ 65.716835] ra : __getblk_gfp+0x1c/0x4a >> [ 65.717831] epc : ffe00019f11e ra : ffe00019f56a sp : >> ffe002437930 >> [ 65.719553] gp : ffe000f06030 tp : ffe0015abc00 t0 : >> ffe00191e038 >> [ 65.721290] t1 : ffe00191e038 t2 : 000a s0 : >> ffe002437960 >> [ 65.723051] s1 : ffe00160ad00 a0 : ffe00160ad00 a1 : >> 012a >> [ 65.724772] a2 : 0400 a3 : 0008 a4 : >> 0040 >> [ 65.726545] a5 : a6 : ffe00191e000 a7 : >> >> [ 65.728308] s2 : 012a s3 : 0400 s4 : >> 0008 >> [ 65.730049] s5 : 006c s6 : ffe00240f800 s7 : >> ffe000f080a8 >> [ 65.731802] s8 : 0001 s9 : 012a s10: >> 0008 >> [ 65.733516] s11: 0008 t3 : 03ff t4 : >> 000f >> [ 65.734434] t5 : 03ff t6 : 0004 >> [ 65.734613] status: 0100 badaddr: cause: >> 0003 >> [ 65.734901] Call Trace: >> [ 65.735076] [] __find_get_block+0x218/0x2c8 >> [ 65.735417] [] __ext4_get_inode_loc+0xb2/0x2f6 >> [ 65.735618] [] ext4_get_inode_loc+0x3a/0x8a >> [ 65.735802] [] ext4_reserve_inode_write+0x2e/0x8c >> [ 65.735999] [] __ext4_mark_inode_dirty+0x4c/0x18e >> [ 65.736208] [] ext4_dirty_inode+0x46/0x66 >> [ 65.736387] [] __mark_inode_dirty+0x12c/0x3da >> [ 65.736576] [] touch_atime+0x146/0x150 >> [ 65.736748] [] filemap_read+0x234/0x246 >> [ 65.736920] [] generic_file_read_iter+0xc0/0x114 >> [ 65.737114] [] ext4_file_read_iter+0x42/0xea >> [ 65.737310] [] new_sync_read+0xe2/0x15a >> [ 65.737483] [] vfs_read+0xca/0xf2 >> [ 65.737641] [] ksys_read+0x5e/0xc8 >> [ 65.737816] [] sys_read+0xe/0x16 >> [ 65.737973] [] ret_from_syscall+0x0/0x2 >> [ 65.738858] ---[ end trace fe93f985456c935d ]--- >> >> A simple reproducer looks like: >> echo 'p:myprobe sys_read fd=%a0 buf=%a1 count=%a2' > >> /sys/kernel/debug/tracing/kprobe_events >> echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable >> cat /sys/kernel/debug/tracing/trace >> > > I can't reproduce the BUG_ON with the above step, I may miss something. > My test platform versions Kernel: 0d02ec6b3136 Linux 5.12-rc4 QEMU: fdd76fecdd Update version for v5.0.0 release >> Here's what happens to hit that BUG_ON(): >> >> 1) After installing kprobe at entry of sys_read, the first instruction >>is replaced by 'ebreak' instruction on riscv64 platform. >> >> 2) Once kernel reach the 'ebreak' instruction at the entry of sys_read, >>it trap into the riscv breakpoint handler, where it do something to >>setup for coming single-step of origin instruction, including backup >>the 'sstatus' in pt_regs, followed by disable interrupt during single >>stepping via clear 'SIE' bit of 'sstatus' in pt_regs. >> >> 3) Then kernel restore to the instruction slot contains two instructions, >>one is original instruction at entry of sys_read, the other is 'ebreak'. >>Here it trigger a 'Instruction page fault' exception (value at 'scause' >>is '0xc'), if PF is not filled into PageTabe for that slot yet. >> >> 4) Again kernel trap into page fault exception handler, where it choose >>different policy according to the state of running kprobe. Because >>afte 2) the state is KPROBE_HIT_SS, so kernel reset the current kprobe >>and 'pc' points back to the probe address. >> >> 5) Because 'epc' point back to 'ebreak' instrution at sys_read probe, >>kernel trap into breakpoint handler again, and repeat the operations >
Re: [PATCH] crypto: api - fix coding style
On 2021/4/9 15:27, Herbert Xu wrote: > On Thu, Apr 01, 2021 at 03:20:49PM +0800, Zhiqi Song wrote: >> Fixed following checkpatch error: >> - do not use assignment in if condition >> Fixed following checkpatch warning: >> - prefer strscpy over strlcpy >> - delete repeated word >> >> Signed-off-by: Zhiqi Song >> --- >> crypto/api.c | 20 >> 1 file changed, 12 insertions(+), 8 deletions(-) > > Please don't mix unrelated changes in a single patch. > > Thanks, > OK, I will split this patch. Thanks.
Re: ramdisk
Hi Xu, As far we have worked on it, the parameter to be passed is "root=/dev/ram" and not "root=/dev/ram0". Atleast I used it to boot the kernel on a U-Boot boot loader. I guess I can help you out. But I will need more details. But I would like you to try "root=/dev/ram" first and let me know if its working. Midhun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt
git-bisect bad ab144f5ec64c42218a555ec1dbde6b60cf2982d6 Also breaks booting in VMWare's WS 6 if paravirtual support is enabled for the guest. Hope this helps narrow it down. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/buffer.c: Fix data corruption when buffer write with IO error
On 4/8/2019 7:11 PM, Jan Kara wrote: On Sat 06-04-19 15:13:13, ZhangXiaoxu wrote: When the buffer write failed, 'end_buffer_write_sync' and 'end_buffer_async_write' will clear the uptodate flag. But the data in the buffer maybe newer than disk. In some case, this will lead data corruption. For example: ext4 flush metadata to disk failed, it will clear the uptodate flag. when a new coming call want the buffer, it will read it from the disk(because the buffer no uptodate flag). But the journal not checkpoint now, it will read old data from disk. If read successfully, ext4 will write the old data to the new journal, the data will corruption. So, don't clear the uptodate flag when write the buffer failed. Signed-off-by: ZhangXiaoxu Thanks for the patch. But what are the chances that after the write has failed the read will succeed? Also there were places that were using buffer_uptodate() to detect IO errors. Did you check all those got converted to using buffer_write_io_error() instead? Honza I encountered this situation when using iscsi target as the ext4 volume, if the network down a while when ext4 write metadata to disk, and maybe read will success after the network recovered. In my testcase, just create and delete files, when disconnect the network, the dir entry maybe corruption. I add some logs when read entry buffer from disk, the buffer stats maybe buffer_write_io_error() and !buffer_uptodate(). In this case, the ext4 will corruption high probability. Because the buffer is read from disk, and some newer information just on journal. In this case, we should not read buffer from the disk. I don't know any other filesystem how to use the uptodate flag. But I think uptodate means the buffer is valid and newer than disk, am I right? I just test ext4 use the xfstest. Any other idea about my problem?
Re: [PATCH V5 0/3] Intel Platform Monitoring Technology
MCTP and PLDM are the latest in Platform management Technology. Sw application and drivers can be implemented on the PCIe platform. Previously I spent some time on this. On Mon, Aug 10, 2020 at 7:49 PM David E. Box wrote: > > Friendly ping. > > On Wed, 2020-07-29 at 14:37 -0700, David E. Box wrote: > > Intel Platform Monitoring Technology (PMT) is an architecture for > > enumerating and accessing hardware monitoring capabilities on a > > device. > > With customers increasingly asking for hardware telemetry, engineers > > not > > only have to figure out how to measure and collect data, but also how > > to > > deliver it and make it discoverable. The latter may be through some > > device > > specific method requiring device specific tools to collect the data. > > This > > in turn requires customers to manage a suite of different tools in > > order to > > collect the differing assortment of monitoring data on their > > systems. Even > > when such information can be provided in kernel drivers, they may > > require > > constant maintenance to update register mappings as they change with > > firmware updates and new versions of hardware. PMT provides a > > solution for > > discovering and reading telemetry from a device through a hardware > > agnostic > > framework that allows for updates to systems without requiring > > patches to > > the kernel or software tools. > > > > PMT defines several capabilities to support collecting monitoring > > data from > > hardware. All are discoverable as separate instances of the PCIE > > Designated > > Vendor extended capability (DVSEC) with the Intel vendor code. The > > DVSEC ID > > field uniquely identifies the capability. Each DVSEC also provides a > > BAR > > offset to a header that defines capability-specific attributes, > > including > > GUID, feature type, offset and length, as well as configuration > > settings > > where applicable. The GUID uniquely identifies the register space of > > any > > monitor data exposed by the capability. The GUID is associated with > > an XML > > file from the vendor that describes the mapping of the register space > > along > > with properties of the monitor data. This allows vendors to perform > > firmware updates that can change the mapping (e.g. add new metrics) > > without > > requiring any changes to drivers or software tools. The new mapping > > is > > confirmed by an updated GUID, read from the hardware, which software > > uses > > with a new XML. > > > > The current capabilities defined by PMT are Telemetry, Watcher, and > > Crashlog. The Telemetry capability provides access to a continuous > > block > > of read only data. The Watcher capability provides access to hardware > > sampling and tracing features. Crashlog provides access to device > > crash > > dumps. While there is some relationship between capabilities > > (Watcher can > > be configured to sample from the Telemetry data set) each exists as > > stand > > alone features with no dependency on any other. The design therefore > > splits > > them into individual, capability specific drivers. MFD is used to > > create > > platform devices for each capability so that they may be managed by > > their > > own driver. The PMT architecture is (for the most part) agnostic to > > the > > type of device it can collect from. Devices nodes are consequently > > generic > > in naming, e.g. /dev/telem and /dev/smplr. Each capability > > driver > > creates a class to manage the list of devices supporting > > it. Software can > > determine which devices support a PMT feature by searching through > > each > > device node entry in the sysfs class folder. It can additionally > > determine > > if a particular device supports a PMT feature by checking for a PMT > > class > > folder in the device folder. > > > > This patch set provides support for the PMT framework, along with > > support > > for Telemetry on Tiger Lake. > > > > Changes from V4: > > - Replace MFD with PMT in driver title > > - Fix commit tags in chronological order > > - Fix includes in alphabetical order > > - Use 'raw' string instead of defines for device names > > - Add an error message when returning an error code for > > unrecognized capability id > > - Use dev_err instead of dev_warn for messages when returning > > an error > > - Change while loop
Re: [PATCH v2 3/5] crypto: hisilicon/sgl - add some dfx logs
However, I think this log can be used to quickly locate the function or
module if dma alloc failed.
On 2021/3/30 15:56, Joe Perches wrote:
On Tue, 2021-03-30 at 15:39 +0800, Kai Ye wrote:
Add some dfx logs in some abnormal exit situations.
[]
diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
[]
@@ -87,8 +87,10 @@ struct hisi_acc_sgl_pool *hisi_acc_create_sgl_pool(struct
device *dev,
block[i].sgl = dma_alloc_coherent(dev, block_size,
&block[i].sgl_dma,
GFP_KERNEL);
- if (!block[i].sgl)
+ if (!block[i].sgl) {
+ dev_err(dev, "Fail to allocate hw SG buffer!\n");
This doesn't seem useful as dma_alloc_coherent does a dump_stack
by default on OOM.
.
Re: [PATCH] mmc: dw_mmc-k3: use the correct HiSilicon copyright
On 2021/3/30 18:38, Ulf Hansson wrote: On Tue, 30 Mar 2021 at 08:43, Hao Fang wrote: s/Hisilicon/HiSilicon/g. It should use capital S, according to https://www.hisilicon.com/en/terms-of-use. Signed-off-by: Hao Fang --- drivers/mmc/host/dw_mmc-k3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c index 29d2494..0311a37 100644 --- a/drivers/mmc/host/dw_mmc-k3.c +++ b/drivers/mmc/host/dw_mmc-k3.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-or-later /* * Copyright (c) 2013 Linaro Ltd. - * Copyright (c) 2013 Hisilicon Limited. + * Copyright (c) 2013 HiSilicon Limited. This change looks really silly to me, but I am not a lawyer - so I can't tell if this makes sense or not. In any case, "Hisilicon" is being used all over the kernel - do you intend to patch all places with similar changes like this one? Perhaps just send a big tree-wide-patch instead and see what people think? Although HiSilicon has applied for two trademarks Hisilicon/HiSilicon, there is only one English name for the company. We have consulted with company's lawyer who suggested that should use a copyright statement consistent with the official website. Though the kernel has tons of "Hisilicon", I just fix the copyright, and plan to send a commit to each subsystem where is uncorrect. Fortunately, there are not many modules that have the problem, this is one of them. Thanks. Hao */ #include Kind regards Uffe .
Re: [PATCH] mmc: dw_mmc-k3: use the correct HiSilicon copyright
On 2021/3/30 21:43, Pavel Machek wrote: Hi! On Tue, 30 Mar 2021 at 08:43, Hao Fang wrote: s/Hisilicon/HiSilicon/g. It should use capital S, according to https://www.hisilicon.com/en/terms-of-use. Signed-off-by: Hao Fang /* * Copyright (c) 2013 Linaro Ltd. - * Copyright (c) 2013 Hisilicon Limited. + * Copyright (c) 2013 HiSilicon Limited. This change looks really silly to me, but I am not a lawyer - so I can't tell if this makes sense or not. In any case, "Hisilicon" is being used all over the kernel - do you intend to patch all places with similar changes like this one? Perhaps just send a big tree-wide-patch instead and see what people think? Plus, I'd expect authors to submit changes to copyright notices. Just add Reviewed-by or Acked-by! Thanks. Best regards, Pavel
Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT exception
Hi Jisheng, 在 2021/4/2 21:32, Jisheng Zhang 写道: > On Thu, 1 Apr 2021 16:49:47 +0800 > "liaochang (A)" wrote: > >> Hi Jisheng, > > Hi, > >> >> 在 2021/3/31 22:22, Jisheng Zhang 写道: >>> On Tue, 30 Mar 2021 18:33:16 +0900 >>> Masami Hiramatsu wrote: >>> >>>> Hi Jisheng, >>> >>> Hi Masami, >>> >>>> >>>> On Tue, 30 Mar 2021 02:16:24 +0800 >>>> Jisheng Zhang wrote: >>>> >>>>> From: Jisheng Zhang >>>>> >>>>> Current riscv's kprobe handlers are run with both preemption and >>>>> interrupt enabled, this violates kprobe requirements. Fix this issue >>>>> by keeping interrupts disabled for BREAKPOINT exception. >>>> >>>> Not only while the breakpoint exception but also until the end of >>>> the single step (maybe you are using __BUG_INSN_32 ??) need to be >>>> disable interrupts. Can this do that? >>>> >>> >>> interrupt is disabled during "single step" by kprobes_save_local_irqflag() >>> and kprobes_restore_local_irqflag(). The code flow looks like: >>> >>> do_trap_break() // for bp >>> kprobe_breakpoint_handler() >>> setup_singlestep() >>> kprobes_restore_local_irqflag() >>> >>> do_trap_break() // for ss >>> kprobe_single_step_handler() >>> kprobes_restore_local_irqflag() >> >> Recently, kernel hit BUG_ON() on QEMU after I install a probe at "sys_read" >> via kprobe, > > TIPS: Each line should not exceed 80 chars > >> accoriding to my debugging and analysis it looks like caused by the "irq >> disable" operation for single-stepping. >> >> I present a detailed description about this problem in the mail with title >> "[PATCH] riscv/kprobe: fix kernel panic when invoking sys_read traced by >> kprobe". >> Looking forward to some feedback,Thanks. >> > > I will comment that patch. Thanks for your reminder. > > thanks > > . >
Re: [PATCH] phy: hisilicon: Use the correct HiSilicon copyright
On 2021/3/31 20:29, Vinod Koul wrote: On 30-03-21, 14:47, Hao Fang wrote: s/Hisilicon/HiSilicon/g. It should use capital S, according to https://www.hisilicon.com/en/terms-of-use. And I have not agreed to those terms of use! If you wish to change the name, please do send the patch dropping this terms of use link. I dont mind name appearing properly... I put a link to show the correct example for copyright, maybe it makes a misunderstanding. I will change it to "according to the official website", and send V2. Thanks. Hao Thanks Signed-off-by: Hao Fang --- drivers/phy/hisilicon/phy-hi6220-usb.c | 2 +- drivers/phy/hisilicon/phy-hix5hd2-sata.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/phy/hisilicon/phy-hi6220-usb.c b/drivers/phy/hisilicon/phy-hi6220-usb.c index be05292..e92ba78 100644 --- a/drivers/phy/hisilicon/phy-hi6220-usb.c +++ b/drivers/phy/hisilicon/phy-hi6220-usb.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-or-later /* * Copyright (c) 2015 Linaro Ltd. - * Copyright (c) 2015 Hisilicon Limited. + * Copyright (c) 2015 HiSilicon Limited. */ #include diff --git a/drivers/phy/hisilicon/phy-hix5hd2-sata.c b/drivers/phy/hisilicon/phy-hix5hd2-sata.c index c67b78c..b0f99a9 100644 --- a/drivers/phy/hisilicon/phy-hix5hd2-sata.c +++ b/drivers/phy/hisilicon/phy-hix5hd2-sata.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-or-later /* * Copyright (c) 2014 Linaro Ltd. - * Copyright (c) 2014 Hisilicon Limited. + * Copyright (c) 2014 HiSilicon Limited. */ #include -- 2.8.1
Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT exception
Hi Jisheng, 在 2021/3/31 22:22, Jisheng Zhang 写道: > On Tue, 30 Mar 2021 18:33:16 +0900 > Masami Hiramatsu wrote: > >> Hi Jisheng, > > Hi Masami, > >> >> On Tue, 30 Mar 2021 02:16:24 +0800 >> Jisheng Zhang wrote: >> >>> From: Jisheng Zhang >>> >>> Current riscv's kprobe handlers are run with both preemption and >>> interrupt enabled, this violates kprobe requirements. Fix this issue >>> by keeping interrupts disabled for BREAKPOINT exception. >> >> Not only while the breakpoint exception but also until the end of >> the single step (maybe you are using __BUG_INSN_32 ??) need to be >> disable interrupts. Can this do that? >> > > interrupt is disabled during "single step" by kprobes_save_local_irqflag() > and kprobes_restore_local_irqflag(). The code flow looks like: > > do_trap_break() // for bp > kprobe_breakpoint_handler() > setup_singlestep() > kprobes_restore_local_irqflag() > > do_trap_break() // for ss > kprobe_single_step_handler() > kprobes_restore_local_irqflag() Recently, kernel hit BUG_ON() on QEMU after I install a probe at "sys_read" via kprobe, accoriding to my debugging and analysis it looks like caused by the "irq disable" operation for single-stepping. I present a detailed description about this problem in the mail with title "[PATCH] riscv/kprobe: fix kernel panic when invoking sys_read traced by kprobe". Looking forward to some feedback,Thanks. BR, Liao Chang > > Thanks > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > . >
Re: [PATCH -next] [POWERPC] Rename get_property to of_get_property: use DEFINE_SPINLOCK() for spinlock
Rename get_property to of_get_property: use DEFINE_SPINLOCK() for spinlock ~ 这是啥模块名？ 在 2021/4/9 17:51, Ye Bin 写道: spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by: Hulk Robot Signed-off-by: Ye Bin --- drivers/macintosh/via-pmu-led.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/macintosh/via-pmu-led.c b/drivers/macintosh/via-pmu-led.c index ae067ab2373d..2502119cff42 100644 --- a/drivers/macintosh/via-pmu-led.c +++ b/drivers/macintosh/via-pmu-led.c @@ -27,7 +27,7 @@ #include #include -static spinlock_t pmu_blink_lock; +static DEFINE_SPINLOCK(pmu_blink_lock); static struct adb_request pmu_blink_req; /* -1: no change, 0: request off, 1: request on */ static int requested_change; @@ -105,8 +105,6 @@ static int __init via_pmu_led_init(void) return -ENODEV; } of_node_put(dt); - - spin_lock_init(&pmu_blink_lock); /* no outstanding req */ pmu_blink_req.complete = 1; pmu_blink_req.done = pmu_req_done;
Re: [PATCH -next] dlm: use DEFINE_MUTEX() for mutex lock
两个标题一样的可以合并
在 2021/4/9 17:51, Ye Bin 写道:
mutex lock can be initialized automatically with DEFINE_MUTEX()
rather than explicitly calling mutex_init().
Reported-by: Hulk Robot
Signed-off-by: Ye Bin
---
fs/dlm/lockspace.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/dlm/lockspace.c b/fs/dlm/lockspace.c
index c14cf2b7faab..fa3ae801aa43 100644
--- a/fs/dlm/lockspace.c
+++ b/fs/dlm/lockspace.c
@@ -26,7 +26,7 @@
#include "ast.h"
static int ls_count;
-static struct mutexls_lock;
+static DEFINE_MUTEX(ls_lock);
static struct list_head lslist;
static spinlock_t lslist_lock;
static struct task_struct * scand_task;
@@ -231,7 +231,6 @@ static const struct kset_uevent_ops dlm_uevent_ops = {
int __init dlm_lockspace_init(void)
{
ls_count = 0;
- mutex_init(&ls_lock);
INIT_LIST_HEAD(&lslist);
spin_lock_init(&lslist_lock);
Re: [PATCH -next] [POWERPC] Rename get_property to of_get_property: use DEFINE_SPINLOCK() for spinlock
Rename get_property to of_get_property: use DEFINE_SPINLOCK() for spinlock ^ Please fix the module name in the patch subject. spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by: Hulk Robot Signed-off-by: Ye Bin --- drivers/macintosh/via-pmu-led.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/macintosh/via-pmu-led.c b/drivers/macintosh/via-pmu-led.c index ae067ab2373d..2502119cff42 100644 --- a/drivers/macintosh/via-pmu-led.c +++ b/drivers/macintosh/via-pmu-led.c @@ -27,7 +27,7 @@ #include #include -static spinlock_t pmu_blink_lock; +static DEFINE_SPINLOCK(pmu_blink_lock); static struct adb_request pmu_blink_req; /* -1: no change, 0: request off, 1: request on */ static int requested_change; @@ -105,8 +105,6 @@ static int __init via_pmu_led_init(void) return -ENODEV; } of_node_put(dt); - - spin_lock_init(&pmu_blink_lock); /* no outstanding req */ pmu_blink_req.complete = 1; pmu_blink_req.done = pmu_req_done;
Re: [PATCH 2/9] mm: vmscan: use nid from shrink_control for tracepoint
On 2020/12/3 2:27, Yang Shi wrote: The tracepoint's nid should show what node the shrink happens on, the start tracepoint uses nid from shrinkctl, but the nid might be set to 0 before end tracepoint if the shrinker is not NUMA aware, so the traceing log may show the shrink happens on one node but end up on the other node. It seems confusing. And the following patch will remove using nid directly in do_shrink_slab(), this patch also helps cleanup the code. Signed-off-by: Yang Shi --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 7d6186a07daf..457ce04eebf2 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -533,7 +533,7 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, new_nr = atomic_long_add_return(next_deferred, &shrinker->nr_deferred[nid]); - trace_mm_shrink_slab_end(shrinker, nid, freed, nr, new_nr, total_scan); + trace_mm_shrink_slab_end(shrinker, shrinkctl->nid, freed, nr, new_nr, total_scan); Hi， Yang When I read this patch, I wondered why you modified it so much until I read patch6. Could you merge this patch into patch6? Thanks! return freed; }
Re: [PATCH] net: qrtr: fix null-ptr-deref in qrtr_ns_remove
A null-ptr-deref bug is reported by Hulk Robot like this:
--
KASAN: null-ptr-deref in range [0x0128-0x012f]
Call Trace:
qrtr_ns_remove+0x22/0x40 [ns]
qrtr_proto_fini+0xa/0x31 [qrtr]
__x64_sys_delete_module+0x337/0x4e0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x468ded
--
When qrtr_ns_init fails in qrtr_proto_init, qrtr_ns_remove which would
be called later on would raise a null-ptr-deref because qrtr_ns.workqueue
has been destroyed.
Fix it by making qrtr_ns_init have a return value and adding a check in
qrtr_proto_init.
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
net/qrtr/ns.c | 7 ---
net/qrtr/qrtr.c | 14 +++---
net/qrtr/qrtr.h | 2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index 56aaf8cb6..8d00dfe81 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -755,7 +755,7 @@ static void qrtr_ns_data_ready(struct sock *sk)
queue_work(qrtr_ns.workqueue, &qrtr_ns.work);
}
-void qrtr_ns_init(void)
+int qrtr_ns_init(void)
{
struct sockaddr_qrtr sq;
int ret;
@@ -766,7 +766,7 @@ void qrtr_ns_init(void)
ret = sock_create_kern(&init_net, AF_QIPCRTR, SOCK_DGRAM,
PF_QIPCRTR, &qrtr_ns.sock);
if (ret < 0)
- return;
+ return ret;
ret = kernel_getsockname(qrtr_ns.sock, (struct sockaddr *)&sq);
if (ret < 0) {
@@ -797,12 +797,13 @@ void qrtr_ns_init(void)
if (ret < 0)
goto err_wq;
- return;
+ return 0;
err_wq:
destroy_workqueue(qrtr_ns.workqueue);
err_sock:
sock_release(qrtr_ns.sock);
+ return ret;
}
EXPORT_SYMBOL_GPL(qrtr_ns_init);
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index f4ab3ca6d..95533e451 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -1288,12 +1288,20 @@ static int __init qrtr_proto_init(void)
rc = sock_register(&qrtr_family);
if (rc) {
- proto_unregister(&qrtr_proto);
- return rc;
+ goto err_proto;
}
braces {} are not necessary for single statement.
- qrtr_ns_init();
+ rc = qrtr_ns_init();
+ if (rc) {
+ goto err_sock;
+ }
+ return 0;
+
+err_sock:
+ sock_unregister(qrtr_family.family);
+err_proto:
+ proto_unregister(&qrtr_proto);
return rc;
}
postcore_initcall(qrtr_proto_init);
diff --git a/net/qrtr/qrtr.h b/net/qrtr/qrtr.h
index dc2b67f17..3f2d28696 100644
--- a/net/qrtr/qrtr.h
+++ b/net/qrtr/qrtr.h
@@ -29,7 +29,7 @@ void qrtr_endpoint_unregister(struct qrtr_endpoint *ep);
int qrtr_endpoint_post(struct qrtr_endpoint *ep, const void *data, size_t len);
-void qrtr_ns_init(void);
+int qrtr_ns_init(void);
void qrtr_ns_remove(void);
Re: [PATCH RFC net-next] net: hns3: debugfs add dump tm info of nodes, priority and qset
ping
On 2020/12/31 17:03, Guangbin Huang wrote:
To increase methods to dump more tm info, adds three debugfs commands
to dump tm info of nodes, priority and qset. And a new tm file of debugfs
is created for only dumping tm info.
Unlike previous debugfs commands, to dump each tm information, user needs
to enter two commands now. The first command writes parameters to tm and
the second command reads info from tm. For examples, to dump tm info of
priority 0, user needs to enter follow two commands:
1. echo dump priority 0 > tm
2. cat tm
The reason for adding new tm file is because we accepted Jakub Kicinski's
opinion as link https://lkml.org/lkml/2020/9/29/2101. And in order to
avoid generating too many files, we implement write ops to allow user to
input parameters.
However, If there are two or more users concurrently write parameters to
tm, parameters of the latest command will overwrite previous commands,
this concurrency problem will confuse users, but now there is no good
method to fix it.
Signed-off-by: Guangbin Huang
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 9 +
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 117 ++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 6 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 1 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 250 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 1 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 2 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h | 26 +++
8 files changed, 412 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 912c51e..08a30de 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -243,6 +243,10 @@ struct hnae3_vector_info {
int vector;
};
+enum hnae3_dbg_module_type {
+ HNAE3_DBG_MODULE_TYPE_TM,
+};
+
#define HNAE3_RING_TYPE_B 0
#define HNAE3_RING_TYPE_TX 0
#define HNAE3_RING_TYPE_RX 1
@@ -454,6 +458,8 @@ struct hnae3_ae_dev {
* Configure the default MAC for specified VF
* get_module_eeprom
* Get the optical module eeprom info.
+ * dbg_read_cmd
+ * Execute debugfs read command.
*/
struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -609,6 +615,8 @@ struct hnae3_ae_ops {
int (*add_arfs_entry)(struct hnae3_handle *handle, u16 queue_id,
u16 flow_id, struct flow_keys *fkeys);
int (*dbg_run_cmd)(struct hnae3_handle *handle, const char *cmd_buf);
+ int (*dbg_read_cmd)(struct hnae3_handle *handle, const char *cmd_buf,
+ char *buf, int len);
pci_ers_result_t (*handle_hw_ras_error)(struct hnae3_ae_dev *ae_dev);
bool (*get_hw_reset_stat)(struct hnae3_handle *handle);
bool (*ae_dev_resetting)(struct hnae3_handle *handle);
@@ -734,6 +742,7 @@ struct hnae3_handle {
u8 netdev_flags;
struct dentry *hnae3_dbgfs;
+ int dbgfs_type;
/* Network interface message level enabled bits */
u32 msg_enable;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
index dc9a857..bdca7d4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
@@ -12,6 +12,10 @@
static struct dentry *hns3_dbgfs_root;
+#define HNS3_HELP_INFO "help"
+
+#define HNS3_DBG_MODULE_NAME_TM"tm"
+
static int hns3_dbg_queue_info(struct hnae3_handle *h,
const char *cmd_buf)
{
@@ -305,6 +309,22 @@ static void hns3_dbg_help(struct hnae3_handle *h)
dev_info(&h->pdev->dev, "%s", printf_buf);
}
+static void hns3_dbg_tm_help(struct hnae3_handle *h, char *buf, int len)
+{
+ struct hnae3_ae_dev *ae_dev = pci_get_drvdata(h->pdev);
+ int pos;
+
+ pos = scnprintf(buf, len, "available commands:\n");
+
+ if (!hns3_is_phys_func(h->pdev))
+ return;
+
+ if (ae_dev->dev_version > HNAE3_DEVICE_VERSION_V2)
+ pos += scnprintf(buf + pos, len - pos, "dump nodes\n");
+ pos += scnprintf(buf + pos, len - pos, "dump priority \n");
+ pos += scnprintf(buf + pos, len - pos, "dump qset \n");
+}
+
static void hns3_dbg_dev_caps(struct hnae3_handle *h)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(h->pdev);
@@ -444,6 +464,93 @@ static ssize_t hns3_dbg_cmd_write(struct file *filp, const
char __user *buffer,
return count;
}
+static ssize_t hns3_dbg_tm_read(struct file *filp, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+ struct hnae3_handle *handle = filp->private_data;
+ const struct hnae3_ae_ops *ops =
Hello from Mr. Kalifa
Good day, Please can I talk to you about interesting business deal? I will be happy if you permit. I wait to hear from you soon. Regards, Kalifah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/3] silicom: fix whitespace issues in bypass.c
Hello Michael,
On Fri, Dec 20, 2013 at 7:21 PM, Michael Hoefler
wrote:
> This patch addresses several problems in bypass.c found by checkpatch.
> Furthermore it removes/adds some empty lines to make the code more readable.
>
> The following problems are fixed:
> - line over 80 characters
> - space after logical operator !
> - spaces instead of tabs
> - missing empty line after local declarations
> - empty line after {
>
Please do one thing per patch, As Greg suggested for me in previous mail
conversations. Here you could have at least 3 or 4 patches.
For example, first patch would be a fix for line over 80 characters,
followed by the other problems as mentioned above by you.
> The empty line issues were not discovered by checkpatch but in my opinion
> these
> changes make perfect sense in terms of readability.
>
> Signed-off-by: Michael Hoefler
> Signed-off-by: Christoph Kohl
> ---
> drivers/staging/silicom/bypasslib/bypass.c | 111
> -
> 1 file changed, 61 insertions(+), 50 deletions(-)
>
1.8.1.2
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/3] silicom: fix whitespace issues in bypass.c
On Fri, Dec 20, 2013 at 10:31 PM, Greg Kroah-Hartman
wrote:
> On Fri, Dec 20, 2013 at 08:36:48PM +0530, Gokulnath A wrote:
>> Hello Michael,
>>
>> On Fri, Dec 20, 2013 at 7:21 PM, Michael Hoefler
>> wrote:
>> > This patch addresses several problems in bypass.c found by checkpatch.
>> > Furthermore it removes/adds some empty lines to make the code more
>> > readable.
>> >
>> > The following problems are fixed:
>> > - line over 80 characters
>> > - space after logical operator !
>> > - spaces instead of tabs
>> > - missing empty line after local declarations
>> > - empty line after {
>> >
>>
>> Please do one thing per patch, As Greg suggested for me in previous mail
>> conversations. Here you could have at least 3 or 4 patches.
>> For example, first patch would be a fix for line over 80 characters,
>> followed by the other problems as mentioned above by you.
>
> Nah, all of these are affecting the same macros, so it's ok, I'll take
> it as-is.
ok. Sorry for the comments and thanks for information.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Question about bcache buckets utilization
Hi! Kent Overstreet, I tested bcache branch for jens: http://evilpiepirate.org/git/linux-bcache.git/log/?h=for-jens I have a question about buckets utilization, can you help me to resolve it? This is the test fio cmd: fio -name iops -rw=randwrite -iodepth=32 -numjobs=1 -filename=/dev/bcache0 -ioengine libaio -direct=1 -bs=4k -size=500M -runtime=600 -time_based -random_distribution=zipf:1.2 My cache device is 1G size, and Hdd device is 5G size. The bucket size is default 512k. When the test is run, cache is over CUTOFF_WRITEBACK_SYNC after 3 or 4 seconds. The test result is as follows: Device: rrqm/s wrqm/s r/s w/srMB/swMB/s avgrq-sz avgqu-sz await svctm %util bcache0 0.00 0.000.00 62081.00 0.00 242.50 8.00 0.000.01 0.00 0.00 bcache0 0.00 0.000.00 72407.00 0.00 282.84 8.00 0.000.01 0.00 0.00 bcache0 0.00 0.000.00 62990.00 0.00 246.05 8.00 0.000.08 0.00 0.00 bcache0 0.00 0.000.00 511.00 0.00 2.00 8.00 0.00 62.53 0.00 0.00 bcache0 0.00 0.000.00 601.00 0.00 2.35 8.00 0.00 52.73 0.00 0.00 After cache is over CUTOFF_WRITEBACK_SYNC, all writes come down to the hdd, then I got a pool performance. As the random rang is set to 500M, It will all overlapped in the cache device. Why the overlapped buckets can't be reused? Is there any other conditions need to meet? Thanks, Lina Lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] IIO: Added write function in iio_buffer_fileops
From: Aniroop Mathur
Earlier, user space can only read from iio device node but cannot write to it.
This patch adds write function in iio buffer file operations,
which will allow user-space applications/HAL to write the data
to iio device node.
So now there will be two way communication between IIO subsystem
and user space. (userspace <--> kernel)
It can be used by HAL or any user-space application which wants to
write data to iio device node/buffer upon receiving some data from it.
As an example,
It is useful for iio device simulator application which need to record
the data by reading from iio device node and replay the recorded data
by writing back to iio device node.
Signed-off-by: Aniroop Mathur
---
drivers/iio/iio_core.h|5 -
drivers/iio/industrialio-buffer.c | 34 ++
drivers/iio/industrialio-core.c |1 +
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
index 5f0ea77..ba3fe53 100644
--- a/drivers/iio/iio_core.h
+++ b/drivers/iio/iio_core.h
@@ -47,10 +47,12 @@ unsigned int iio_buffer_poll(struct file *filp,
struct poll_table_struct *wait);
ssize_t iio_buffer_read_first_n_outer(struct file *filp, char __user *buf,
size_t n, loff_t *f_ps);
-
+ssize_t iio_buffer_write_first_n_outer(struct file *filp,
+const char __user *buf, size_t n, loff_t *f_ps);
#define iio_buffer_poll_addr (&iio_buffer_poll)
#define iio_buffer_read_first_n_outer_addr (&iio_buffer_read_first_n_outer)
+#define iio_buffer_write_first_n_outer_addr (&iio_buffer_write_first_n_outer)
void iio_disable_all_buffers(struct iio_dev *indio_dev);
void iio_buffer_wakeup_poll(struct iio_dev *indio_dev);
@@ -59,6 +61,7 @@ void iio_buffer_wakeup_poll(struct iio_dev *indio_dev);
#define iio_buffer_poll_addr NULL
#define iio_buffer_read_first_n_outer_addr NULL
+#define iio_buffer_write_first_n_outer_addr NULL
static inline void iio_disable_all_buffers(struct iio_dev *indio_dev) {}
static inline void iio_buffer_wakeup_poll(struct iio_dev *indio_dev) {}
diff --git a/drivers/iio/industrialio-buffer.c
b/drivers/iio/industrialio-buffer.c
index 9f1a140..ef889af 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include "iio_core.h"
@@ -87,6 +88,39 @@ ssize_t iio_buffer_read_first_n_outer(struct file *filp,
char __user *buf,
}
/**
+ * iio_buffer_write_first_n_outer() - chrdev write to buffer
+ *
+ * This function pushes the user space data to kernel iio buffer
+ **/
+ssize_t iio_buffer_write_first_n_outer(struct file *filp,
+ const char __user *buf, size_t n, loff_t *f_ps)
+{
+ struct iio_dev *indio_dev = filp->private_data;
+ struct iio_buffer *rb = indio_dev->buffer;
+ int ret = -1;
+ unsigned char *data = NULL;
+
+ if (!indio_dev->info)
+ return -ENODEV;
+
+ if (n != 1)
+ return -EINVAL;
+
+ data = kzalloc(1, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ if (copy_from_user(data, buf, 1)) {
+ kfree(data);
+ return -EFAULT;
+ }
+
+ ret = iio_push_to_buffer(rb, data);
+ kfree(data);
+ return ret;
+}
+
+/**
* iio_buffer_poll() - poll the buffer to find out if it has data
*/
unsigned int iio_buffer_poll(struct file *filp,
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 4b1f375..a98dba9 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -1114,6 +1114,7 @@ static long iio_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
static const struct file_operations iio_buffer_fileops = {
.read = iio_buffer_read_first_n_outer_addr,
+ .write = iio_buffer_write_first_n_outer_addr,
.release = iio_chrdev_release,
.open = iio_chrdev_open,
.poll = iio_buffer_poll_addr,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reiserfs Bug on linux 3.4.9
Dears i have the following bug on reiserfs on gentoo linux kernel 3.4.9 how can i solve it NOTE am not using NFS [2292727.857807] kernel BUG at fs/reiserfs/stree.c:1474! [2292727.857822] invalid opcode: [#1] SMP DEBUG_PAGEALLOC [2292727.857856] CPU 0 [2292727.857863] Modules linked in: e1000e(O) [2292727.857893] kernel-3.4.9-gentoo [2292727.858764] [] reiserfs_cut_from_item+0x19b/0x6b0 [2292727.858764] [] ? __mutex_lock_slowpath+0x56/0x150 [2292727.858764] [] reiserfs_do_truncate+0x24f/0x600 [2292727.858764] [] ? mutex_lock+0x26/0x40 [2292727.858764] [] reiserfs_truncate_file+0x13b/0x2a0 [2292727.858764] [] reiserfs_file_release+0x26c/0x340 [2292727.858764] [] __fput+0xb9/0x240 [2292727.858764] [] fput+0x1d/0x30 [2292727.858764] [] filp_close+0x61/0x90 [2292727.858764] [] sys_close+0x7c/0xd0 [2292727.858764] [] system_call_fastpath+0x16/0x1b [2292727.858764] Code: 0c 49 d1 ea 4d 39 d1 0f 83 48 ff ff ff 48 39 c3 77 83 49 81 ec 68 01 00 00 49 c1 ec 02 4d 39 e1 0f 83 2f ff ff ff e9 6a ff ff ff <0f> 0b 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 [2292727.858764] RIP [] maybe_indirect_to_direct+0x13e/0x150 [2292727.858764] RSP regards Ayham<>
Re: [PATCH 2/2] perf probe: Support probing at absolute address
Em Wed, Aug 26, 2015 at 12:02:40AM +, 平松雅巳 / HIRAMATU，MASAMI escreveu:
> > From: Wang Nan [mailto:wangn...@huawei.com]
> >
> > It should be useful to allow 'perf probe' probe at absolute offset of
> > a target. For example, when (u)probing at a instruction of a shared
> > object in a embedded system where debuginfo is not avaliable but we
> > know the offset of that instruction by manually digging.
> >
> > This patch enables following perf probe command syntax:
> >
> > # perf probe +0x811e6615
> >
> > And
> >
> > # perf probe /lib/x86_64-linux-gnu/libc-2.19.so +0xeb860
>
> Why do we need "+" for the absolute address?
I guess 'absolute' was the misleading term here, 'offset' would be
better, perhaps, or even 'raw' address.
> It seems that we can do it if we find that the given probe point
> starts with "0x".
Which is kinda ok, since that is the most common way of expressing
offsets, but i don't know why we would preclude using, say, decimal,
octal, etc.
- Arnaldo
> Thanks,
>
> >
> > In the above example, we don't need a anchor symbol, so it is possible
> > to compute absolute addresses using other methods and then use
> > 'perf probe' to create the probing points.
> >
> > Signed-off-by: Wang Nan
> > Cc: Arnaldo Carvalho de Melo
> > Cc: Ingo Molnar
> > Cc: Masami Hiramatsu
> > Cc: Namhyung Kim
> > ---
> > tools/perf/util/probe-event.c | 144
> > +
> > tools/perf/util/probe-event.h | 3 +
> > tools/perf/util/probe-finder.c | 21 +-
> > 3 files changed, 138 insertions(+), 30 deletions(-)
> >
> > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> > index 6c7e538..59de69a4 100644
> > --- a/tools/perf/util/probe-event.c
> > +++ b/tools/perf/util/probe-event.c
> > @@ -1194,9 +1194,13 @@ static int parse_perf_probe_point(char *arg, struct
> > perf_probe_event *pev)
> > *ptr++ = '\0';
> > }
> >
> > - tmp = strdup(arg);
> > - if (tmp == NULL)
> > - return -ENOMEM;
> > + if (arg[0] == '\0')
> > + tmp = NULL;
> > + else {
> > + tmp = strdup(arg);
> > + if (tmp == NULL)
> > + return -ENOMEM;
> > + }
> >
> > if (file_spec)
> > pp->file = tmp;
> > @@ -1283,11 +1287,6 @@ static int parse_perf_probe_point(char *arg, struct
> > perf_probe_event *pev)
> > return -EINVAL;
> > }
> >
> > - if (pp->offset && !pp->function) {
> > - semantic_error("Offset requires an entry function.\n");
> > - return -EINVAL;
> > - }
> > -
> > if (pp->retprobe && !pp->function) {
> > semantic_error("Return probe requires an entry function.\n");
> > return -EINVAL;
> > @@ -1299,6 +1298,11 @@ static int parse_perf_probe_point(char *arg, struct
> > perf_probe_event *pev)
> > return -EINVAL;
> > }
> >
> > + if (!pp->function && !pp->offset && !pp->file) {
> > + semantic_error("Absolute address should not be zero.\n");
> > + return -EINVAL;
> > + }
> > +
> > pr_debug("symbol:%s file:%s line:%d offset:%lu return:%d lazy:%s\n",
> > pp->function, pp->file, pp->line, pp->offset, pp->retprobe,
> > pp->lazy_line);
> > @@ -1609,7 +1613,7 @@ error:
> > static char *synthesize_perf_probe_point(struct perf_probe_point *pp)
> > {
> > char *buf, *tmp;
> > - char offs[32] = "", line[32] = "", file[32] = "";
> > + char offs[32] = "", line[32] = "", file[32] = "", addr[32] = "";
> > int ret, len;
> >
> > buf = zalloc(MAX_CMDLEN);
> > @@ -1622,6 +1626,11 @@ static char *synthesize_perf_probe_point(struct
> > perf_probe_point *pp)
> > if (ret <= 0)
> > goto error;
> > }
> > + if (!pp->function) {
> > + ret = e_snprintf(addr, 32, "0x%lx", pp->offset);
> > + if (ret <= 0)
> > + goto error;
> > + }
> > if (pp->line) {
> > ret = e_snprintf(line, 32, ":%d", pp->line);
> >
Re: [PATCH 2/2] perf probe: Support probing at absolute address
Em Wed, Aug 26, 2015 at 10:38:18AM +0800, Wangnan (F) escreveu:
>
> On 2015/8/26 8:02, 平松雅巳 / HIRAMATU，MASAMI wrote:
> >>From: Wang Nan [mailto:wangn...@huawei.com]
> >>
> >>It should be useful to allow 'perf probe' probe at absolute offset of
> >>a target. For example, when (u)probing at a instruction of a shared
> >>object in a embedded system where debuginfo is not avaliable but we
> >>know the offset of that instruction by manually digging.
> >>
> >>This patch enables following perf probe command syntax:
> >>
> >> # perf probe +0x811e6615
> >>
> >>And
> >>
> >> # perf probe /lib/x86_64-linux-gnu/libc-2.19.so +0xeb860
> >Why do we need "+" for the absolute address?
> >It seems that we can do it if we find that the given probe point
> >starts with "0x".
> >
> >Thanks,
>
> I will change 2/2 as you suggection.
>
> However, we can only ensure that in kernel side symbol never leading
> with '0x'. Although I don't think symbol leading with 0x is useful,
> it is still possible for a userspace program compiled and linked by
> a language other than C produces such symbol. '+' helps us separate
> address and function name semantically, make us don't rely on assumption
> on function names. If in future we do meet '0x' symbols, I think we still
> need the '+' syntax back. But we can do it at that time.
Agreed, I also think that using '+' is better, but will not dwell on
this so as to make progress :-)
- Arnaldo
> Thank you.
>
>
> >>In the above example, we don't need a anchor symbol, so it is possible
> >>to compute absolute addresses using other methods and then use
> >>'perf probe' to create the probing points.
> >>
> >>Signed-off-by: Wang Nan
> >>Cc: Arnaldo Carvalho de Melo
> >>Cc: Ingo Molnar
> >>Cc: Masami Hiramatsu
> >>Cc: Namhyung Kim
> >>---
> >> tools/perf/util/probe-event.c | 144
> >> +
> >> tools/perf/util/probe-event.h | 3 +
> >> tools/perf/util/probe-finder.c | 21 +-
> >> 3 files changed, 138 insertions(+), 30 deletions(-)
> >>
> >>diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> >>index 6c7e538..59de69a4 100644
> >>--- a/tools/perf/util/probe-event.c
> >>+++ b/tools/perf/util/probe-event.c
> >>@@ -1194,9 +1194,13 @@ static int parse_perf_probe_point(char *arg, struct
> >>perf_probe_event *pev)
> >>*ptr++ = '\0';
> >>}
> >>
> >>- tmp = strdup(arg);
> >>- if (tmp == NULL)
> >>- return -ENOMEM;
> >>+ if (arg[0] == '\0')
> >>+ tmp = NULL;
> >>+ else {
> >>+ tmp = strdup(arg);
> >>+ if (tmp == NULL)
> >>+ return -ENOMEM;
> >>+ }
> >>
> >>if (file_spec)
> >>pp->file = tmp;
> >>@@ -1283,11 +1287,6 @@ static int parse_perf_probe_point(char *arg, struct
> >>perf_probe_event *pev)
> >>return -EINVAL;
> >>}
> >>
> >>- if (pp->offset && !pp->function) {
> >>- semantic_error("Offset requires an entry function.\n");
> >>- return -EINVAL;
> >>- }
> >>-
> >>if (pp->retprobe && !pp->function) {
> >>semantic_error("Return probe requires an entry function.\n");
> >>return -EINVAL;
> >>@@ -1299,6 +1298,11 @@ static int parse_perf_probe_point(char *arg, struct
> >>perf_probe_event *pev)
> >>return -EINVAL;
> >>}
> >>
> >>+ if (!pp->function && !pp->offset && !pp->file) {
> >>+ semantic_error("Absolute address should not be zero.\n");
> >>+ return -EINVAL;
> >>+ }
> >>+
> >>pr_debug("symbol:%s file:%s line:%d offset:%lu return:%d lazy:%s\n",
> >> pp->function, pp->file, pp->line, pp->offset, pp->retprobe,
> >> pp->lazy_line);
> >>@@ -1609,7 +1613,7 @@ error:
> >> static char *synthesize_perf_probe_point(struct perf_probe_point *pp)
> >> {
> >>char *buf, *tmp;
> >>- char offs[32] = "", line[32] = "", file[32] = &q
(( United Nations Compensation Code ))
Please view the attached file for your compensation code. PAYMENT CODE.pdf Description: Adobe PDF document
Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility
在 2016/5/19 18:49, Catalin Marinas 写道: On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote: we find that some apps will read cpuinfo when start up, they need the string as follows: "Processor : AArch64 Processor rev 0 (aarch64)" Then thay could load the corresponding libs. But now arm64 platform's cpuinfo don't has this now, so we need add this. I have the same question as Martinez: what are those apps? If they are 64-bit apps, they can always assume AArch64 processor. Those are 32-bit apps, and those apps are very popular in our country.
Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility
在 2016/5/19 19:04, Robin Murphy 写道: On 19/05/16 03:44, x00195127 wrote: we find that some apps will read cpuinfo when start up, they need the string as follows: "Processor : AArch64 Processor rev 0 (aarch64)" Then thay could load the corresponding libs. But now arm64 platform's cpuinfo don't has this now, so we need add this. Signed-off-by: Qing Xia --- arch/arm64/kernel/cpuinfo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c index 3808470..c3527ad 100644 --- a/arch/arm64/kernel/cpuinfo.c +++ b/arch/arm64/kernel/cpuinfo.c @@ -114,6 +114,9 @@ static int c_show(struct seq_file *m, void *v) * online processors, looking for lines beginning with * "processor". Give glibc what it expects. */ +seq_printf(m, "Processor\t: AArch64 Processor rev %d (%s)\n", +read_cpuid_id() & 15, ELF_PLATFORM); The pre-3.19 behaviour printed this once - now you're printing it for every CPU in the system, but all with the same revision of whichever core this happens to be running on, which is unjustifiably incorrect. Furthermore, this string provides virtually no useful information anyway - the majority of code running on AArch64 already knows that by virtue of the fact that *it's running at all*, and for scripts/interpreted code/etc. there are already appropriate mechanisms for discovering the platform (e.g. uname). Robin. Those are 32-bit andriod apps, and according to my tests they really need this information, although this information is already useless in my opinion. A lot of android apps update very slowly. + seq_printf(m, "processor\t: %d\n", i); seq_printf(m, "BogoMIPS\t: %lu.%02lu\n", .
Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility
在 2016/5/19 21:18, Catalin Marinas 写道:
On Thu, May 19, 2016 at 01:50:40PM +0100, Catalin Marinas wrote:
On Thu, May 19, 2016 at 07:06:40PM +0800, Xiaqing (A) wrote:
在 2016/5/19 18:49, Catalin Marinas 写道:
On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote:
we find that some apps will read cpuinfo when start up,
they need the string as follows:
"Processor : AArch64 Processor rev 0 (aarch64)"
Then thay could load the corresponding libs. But now
arm64 platform's cpuinfo don't has this now, so
we need add this.
I have the same question as Martinez: what are those apps? If they are
64-bit apps, they can always assume AArch64 processor.
Those are 32-bit apps, and those apps are very popular in our country.
32-bit apps checking for "AArch64" is a really silly idea. What do they
do with this information?
I'm rather inclined to merge this patch:
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470486f3..623d7d291dd6 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -127,7 +127,8 @@ static int c_show(struct seq_file *m, void *v)
* software which does already (at least for 32-bit).
*/
seq_puts(m, "Features\t:");
- if (personality(current->personality) == PER_LINUX32) {
+ if (is_compat_task() ||
+ personality(current->personality) == PER_LINUX32) {
#ifdef CONFIG_COMPAT
for (j = 0; compat_hwcap_str[j]; j++)
if (compat_elf_hwcap & (1 << j))
To make it even more in line with the AArch32 kernel, let's add the
"model name":
--8<-
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470486f3..6bda9d30a769 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -104,6 +105,8 @@ static const char *const compat_hwcap2_str[] = {
static int c_show(struct seq_file *m, void *v)
{
int i, j;
+ bool compat = is_compat_task() ||
+ personality(current->personality) == PER_LINUX32;
for_each_online_cpu(i) {
struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);
@@ -115,6 +118,9 @@ static int c_show(struct seq_file *m, void *v)
* "processor". Give glibc what it expects.
*/
seq_printf(m, "processor\t: %d\n", i);
+ if (compat)
+ seq_printf(m, "model name\t: ARMv8 Processor rev %d
(%s)\n",
+ MIDR_REVISION(midr), COMPAT_ELF_PLATFORM);
seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
loops_per_jiffy / (50UL/HZ),
@@ -127,7 +133,7 @@ static int c_show(struct seq_file *m, void *v)
* software which does already (at least for 32-bit).
*/
seq_puts(m, "Features\t:");
- if (personality(current->personality) == PER_LINUX32) {
+ if (compat) {
#ifdef CONFIG_COMPAT
for (j = 0; compat_hwcap_str[j]; j++)
if (compat_elf_hwcap & (1 << j))
--8<-
With the above, a compat task or a native one with PER_LINUX32
personality would get:
processor : 0
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS: 100.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 0
I have tested with your patch, the app still can not start up at all.
I'm sorry I didn't explan this exactly before, those apps are 32-bit
android apps(com.tencent.pao etc.). They want to get the information as
"*D m3e : GetCPUType:AArch64 Processor rev 0 (aarch64)*"
and I'm sure the process is forked by zygote not zygote64 in android M.
Finally, I find that apps need the information "Processor :", so when I
change your patch as below, the apps can start up.
--
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 3808470..f14ea4a 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -104,6 +104,8 @@ static const char *const compat_hwcap2_str[] = {
static int c_show(struct seq_file *m, void *v)
{
int i, j;
+ bool compat = is_compat_task() ||
+ personality(current->personality) == PER_LINUX32;
for_each_online_cpu(i) {
struct cpuinfo_arm64 *cpuinfo = &am
Re: [PATCH] powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change
(hope my email makes it everywhere, using a webmail client at the moment as I'm at plumbersconf Michael Ellerman hat am 16. Oktober 2014 um 05:22 geschrieben: > > > Commit 0b0b0893d49b "of/pci: Fix the conversion of IO ranges into IO > resources" changed the behaviour of of_pci_range_to_resource(). I just looked at this after benh mentioned the problem on IRC, here's a log dump :26 AMargh 9:27 AMthe whole ARM OF PCI rework seems to completely break PIO on powerpc 9:30 AM → willy joined (^willy@62.156.150.204) 9:35 AMand reverting it would mean reverting all of ARM new PCI stuff 9:35 AMcrap 9:35 AMthat business with IO space allocation taking over our code without understanding what it does 9:35 AMyuck 9:41 AM → markf , olaf , sarnold , gospo , cmarinas , Mahesh1 , joern , clark_ and benhjoined ⇐ gcl and clark quit ↔ willy , jbarnes , jbrandeb_ and Mahesh popped in ↔ sameo , jbrandeb , steved and jj nipped out • srikar → srikar_away , raghu → raghu_away Thursday, October 16th, 2014 12:06 AM → fweisbec , Mahesh , kamalesh , heiko , olaf , riel and willy joined ⇐ shaggy , sammj , sameo , clark_ , lenb and jj quit ↔ jbrandeb , cdub , Mahesh1 and gcl popped in ↔ jbrandeb_ , benh, joern and BenC nipped out • mpe|away → mpe|away , raghu_away → raghu , srikar_away → srikar 10:16 AMbenh: is it the of_pci_range_to_resource change? 10:17 AMthe new pci_ioremap_iospace logic should not get used on powerpc at all, so I didn't expect any breakage 10:18 AMI wasn't too happy with all the details of Liviu's series, bit in the end it seemed reasonable enough 10:20 AMhe really wanted to use the pci_address_to_pio code from powerpc and in the end I stopped complaining 10:21 AMthe new code can do a few things that simpler versions could not, e.g. handling multiple host bridges getting registered when they have the same I/O space window 10:23 AM → jj joined (^j...@static-50-53-60-87.bvtn.or.frontiernet.net) 10:33 AMbenh: I can see how it breaks your pci_process_bridge_OF_ranges, we had the same problem in some of the ARM platforms and Liviu fixed those but apparently didn't realize he had to change the ppc implementation (and get your ack) too 10:35 AMthe good news is that it should in fact simplify your code to fix it, but the fact that this bug got into the kernel in the first place is extremely annoying 10:39 AMbenh: the fixup that is done in your pcibios_reserve_legacy_regions is now already performed in of_pci_range_to_resource 10:39 AMwe had duplicated the same thing in each pci host driver (and they all got it wrong), so the intent was to move it into a common place 10:40 AMbut of course it's a bug to do it twice 10:43 AMpci_register_io_range is trying to do a more generalized version of how you assign hose->io_base_virt, you should probably override that to keep the current behavior 10:45 AMpcibios_map_phb_io_space I mean, for ppc64 10:52 AM → cmarinas joined (~cmari...@fw-tnat.cambridge.arm.com) 10:53 AMbenh: for 3.18, the best approach is likely to #ifdef <%23ifdef> PCI_IOBASE the changes in of_pci_range_to_resource 10:54 AMI suspect you are fine with effectively reverting Liviu's changes that way, and you can decide whether or not you want to later make the powerpc code use the common logic 11:01 AM → cdub and sarnold joined ⇐ cmarinas quit 11:28 AMarnd_: can you shoot the above in an email CCed to mpe ? 11:28 AMarnd_: he did a band aid that works 11:28 AMarnd_: and see the comment I made today about using his stuff if I can specify where I want the IO ranges 11:28 AMarnd_: I want to keep the way I do the layout on ppc64 > Previously it simply populated the resource based on the arguments. Now > it calls pci_register_io_range() and pci_address_to_pio(). These both > have two implementations depending on whether PCI_IOBASE is defined, > which it is not for powerpc. > > Further complicating matters, both routines are weak, and powerpc > implements it's own version of one - pci_address_to_pio(). However > powerpc's implementation depends on other initialisations which are done > later in boot. Right, sorry for missing this during the last review of the broken patches. > The end result is incorrectly initialised IO space. Often we can get > away with that, because we don't make much use of IO space. However > virtio requires it, so we see eg: > > pci_bus :00: root bus resource [io 0x] (bus address > [0x-0x]) > PCI: Cannot allocate resource region 0 of device :00:01.0, will remap > virtio-pci :00:01.0: can't enable device: BAR 0 [io size 0x0020] not > assigned > > The simplest fix for n
PROBLEM: Many games perform sluggishly after waking PC from suspend
Hello, I'm not sure who to report this to. I've already tried reporting it to Nvidia, but haven't heard any response. I also submitted it to Ubuntu's bug tracker. However, it occurred to me that it could be a general Linux issue. Anyway, I'll voice it here since it strikes me as the next step. Sorry I'm not following the prescribed bug reporting format. I'm not a developer, or very technical. I'm just a general end user who found a problem. Here is the issue. All of my Steam games run at great frame rates normally. However, upon waking my PC from a suspend, many of them perform sluggishly until my next reboot. It's like their frame rate gets cut in half. They're still playable, but not very enjoyably so. Some of these games (played through Steam) include Awesomenauts, Left 4 Dead 2, Dota 2, Counter-Strike: Source, Half-Life 2, Portal, Portal 2 and Team Fortress 2. However, some games continue to work just fine after a suspend. For example, Killing Floor. I know it uses the Unreal 3 engine, and perhaps it is optimized better for Linux. Also Nexuiz and Xonotic continue to work well after a wake from suspend. While the aforementioned games run sluggishly, the desktop still performs as snappy and responsive as before. It seems unaffected by the problem. The issue is only noticeable in games. I hope this will be addressed in future Linux versions, as I would like to continue gaming on this OS. If this has already been addressed in newer versions, please excuse this. Thank you, and take care. System Information: Ubuntu 12.04.5 LTS (64-bit) Asus M4A78LT-M LE Motherboard AMD Athlon II X4 645, 3.10 GHz Mushkin 8GB PC3 Blackline RAM (2x 4GB) 500 GB Hard Disk Nvidia GeForce GT 240 Nvidia Driver Version 331.113 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arm/arm64 perf build issue with mainline
Em Mon, May 11, 2015 at 02:33:04PM +0200, Ingo Molnar escreveu:
>
> * Will Deacon wrote:
>
> > On Mon, May 11, 2015 at 09:21:20AM +0100, Ingo Molnar wrote:
> > > * David Ahern wrote:
> > > > On 4/23/15 5:29 AM, Will Deacon wrote:
> > > > >Commit 6428c59a97de ("perf tools: Set JOBS based on CPU or processor")
> > > > >causes weird behaviour on arm/arm64 platforms because we use the "CPU"
> > > > >prefix for things like:
> > > > >
> > > > >CPU implementer : 0x41
> > > > >CPU architecture: 8
> > > > >CPU variant : 0x0
> > > > >CPU part: 0xd03
> > > > >CPU revision: 0
> > > > >
> > > > >in /proc/cpuinfo. Consequently, a 6 core machine ends up doing:
> > > > >
> > > > >will@confinement-loaf:~/linux/tools/perf$ make
> > > > > BUILD: Doing 'make -j36' parallel build
> > > > >
> > > > >which is a little overwhelming. Any chance we can predicate the extra
> > > > >part of the regex on $(ARCH) being sparc?
> > >
> > > That regex needs to be fixed or replaced with a more robust 'number of
> > > CPUs on the system' discovery method.
> >
> > That was already proposed here (as part of the fallback from getconf):
> >
> > https://lkml.kernel.org/r/20150427190356.gd...@krava.redhat.com
> >
> > but I'm not sure what happened to the patch.
>
> Sending out the latest/best version as a reminder for Arnaldo will
> sure help it along.
>
> Acked-by: Ingo Molnar
IIRC it was merged already, lemme check...
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: arm/arm64 perf build issue with mainline
Em Mon, May 11, 2015 at 12:58:14PM -0300, a...@redhat.com escreveu: > Em Mon, May 11, 2015 at 02:33:04PM +0200, Ingo Molnar escreveu: > > > That was already proposed here (as part of the fallback from getconf): > > > > > > https://lkml.kernel.org/r/20150427190356.gd...@krava.redhat.com > > > > > > but I'm not sure what happened to the patch. > > > > Sending out the latest/best version as a reminder for Arnaldo will > > sure help it along. > > > > Acked-by: Ingo Molnar > > IIRC it was merged already, lemme check... Yes, only for perf/core: [acme@zoo linux]$ git show 762abdc0c6c013425958cd9f5105f4e32268d434 commit 762abdc0c6c013425958cd9f5105f4e32268d434 Author: Will Deacon Date: Thu Apr 23 15:00:16 2015 +0100 perf tools: Use getconf to determine number of online CPUs Parsing /proc/cpuinfo is a fiddly, arch-dependent business and a recent change to get it working for Sparc broke arm and arm64 platforms. Use sysconf to determine the number of online CPUs only parsing /proc/cpuinfo when sysconf is not available. Signed-off-by: Will Deacon Acked-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Mark Rutland Cc: Namhyung Kim Link: http://lkml.kernel.org/r/20150423140454.gj1...@arm.com [ Made it fall back to parsing /proc when getconf not found ] Signed-off-by: Arnaldo Carvalho de Melo diff --git a/tools/perf/Makefile b/tools/perf/Makefile index c699dc35eef9..d31a7bbd7cee 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -24,7 +24,7 @@ unexport MAKEFLAGS # (To override it, run 'make JOBS=1' and similar.) # ifeq ($(JOBS),) - JOBS := $(shell egrep -c '^processor|^CPU' /proc/cpuinfo 2>/dev/null) + JOBS := $(shell (getconf _NPROCESSORS_ONLN || egrep -c '^processor|^CPU[0-9]' /proc/cpuinfo) 2>/dev/null) ifeq ($(JOBS),0) JOBS := 1 endif [acme@zoo linux]$ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 1/1] perf tool:perf diff support for different binaries
Em Wed, Feb 25, 2015 at 03:14:06PM +, Liang, Kan escreveu:
> Hi Arnaldo,
>
> Could you please review the patch?
> I've already updated the patch description to try to address your concern.
> Please let me know if you have any questions.
Just out of time, sorry, will get to it eventually.
- Arnaldo
> Thanks,
> Kan
>
> >
> > From: Kan Liang
> >
> > Currently, the perf diff only works with same binaries. That's because it
> > compares the symbol start address. It doesn't work if the perf.data comes
> > from different binaries. This patch matches the symbol names.
> >
> > Actually, perf diff once intended to compare the symbol names.
> > The commit as below can look for a pair by name.
> > 604c5c92972d (perf diff: Change the default sort order to "dso,symbol")
> > However, at that time, perf diff used a global list of dsos. That means the
> > binaries which has same name can only be loaded once. That's a problem
> > for different binaries compare. For example, we have an old binary and an
> > updated binary. They very likely have same name and most of the function,
> > so only dsos from old binary will be loaded. When processing the data from
> > updated binary, perf still use the symbol information from old binary.
> > That's wrong.
> >
> > Then the commit as below used IP to replace symbol name.
> > 9c443dfdd31e ("perf diff: Fix support for all --sort combinations") From
> > that
> > time, perf diff starts to compare the symbol address.
> >
> > The global dsos is discarded from a patch in 2010.
> > a1645ce12adb ("perf: 'perf kvm' tool for monitoring guest performance
> > from host") However, at that time, perf diff already compared by address.
> > So perf diff cannot work for different binaries as well.
> >
> > This patch actually rolls back the perf diff to original design. The
> > document
> > is also changed, so everybody knows the original design is to compare the
> > symbol names.
> >
> > Here is an examples.
> > The only difference between example_v1.c and example_v2.c is the
> > location of f2 and f3. There is no change in behavior, but the previous perf
> > diff display the wrong differential profile.
> >
> > example_v1.c
> > noinline void f3(void)
> > {
> > volatile int i;
> > for (i = 0; i < 1;) {
> >
> > if(i%2)
> > i++;
> > else
> > i++;
> > }
> > }
> >
> > noinline void f2(void)
> > {
> > volatile int a = 100, b, c;
> > for (b = 0; b < 10000; b++)
> > c = a * b;
> >
> > }
> >
> > noinline void f1(void)
> > {
> > f2();
> > f3();
> > }
> >
> > int main()
> > {
> > int i;
> > for (i = 0; i < 10; i++)
> > f1();
> > }
> >
> > example_v2.c
> > noinline void f2(void)
> > {
> > volatile int a = 100, b, c;
> > for (b = 0; b < 1; b++)
> > c = a * b;
> > }
> >
> > noinline void f3(void)
> > {
> > volatile int i;
> > for (i = 0; i < 1;) {
> > if(i%2)
> > i++;
> > else
> > i++;
> > }
> > }
> >
> > noinline void f1(void)
> > {
> > f2();
> > f3();
> > }
> >
> > int main()
> > {
> > int i;
> > for (i = 0; i < 10; i++)
> > f1();
> > }
> >
> > [lk@localhost perf_diff]$ gcc example_v1.c -o example [lk@localhost
> > perf_diff]$ perf record -o example_v1.data ./example [ perf record:
> > Woken up 4 times to write data ] [ perf record: Captured and wrote 0.813
> > MB example_v1.data (~35522
> > samples) ]
> >
> > [lk@localhost perf_diff]$ gcc example_v2.c -o example [lk@localhost
> > perf_diff]$ perf record -o example_v2.data ./example [ perf record:
> > Woken up 4 times to write data ] [ perf record: Captured and wrote 0.824
> > MB example_v2.data (~36015
> > samples) ]
> >
> > Old perf diff result.
> > [lk@localhost perf_diff]$ perf diff example_v1.data example_v2.data
> > Event 'cycles'
> > BaselineDelta Shared Object Symbol
>
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Laura Abbott hat am 6. Februar 2015 um 01:31 geschrieben: > > The requirement for this is based on a previous patch to add clock > support to the ARM SMMU driver[2]. Once we have clock support, it's > possible that the driver itself may need to be defered which breaks > a bunch of assumptions about how SMMU probing is supposed to work. Hi Laura, I was hoping that we would not need this, and instead treat the iommu in the same way as timers and SMP initialization, both of which need to be run early at boot time but may rely on clock controllers to be initialized first. Is there a specific requirement that makes this impossible here, or is your intention to solve the problem more nicely by allowing deferred probing over forcing the input clocks of the iommu to be early? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64
> Szabolcs Nagy hat am 11. Februar 2015 um 20:05 geschrieben:
> * Catalin Marinas [2015-02-11 17:39:19 +]:
> > (adding Marcus)
> >
> > On Tue, Feb 10, 2015 at 06:13:02PM +, Rich Felker wrote:
> > > I don't know if this has been discussed on libc-alpha yet or not, but
> > > I think we need to open a discussion of how it relates to open glibc
> > > bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64):
> > >
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=16437
> ...
> > So w.r.t. C11, the exported kernel timespec looks fine. But I think the
> > x32 kernel support (and the current ILP32 patches) assume a native
> > struct timespec with tv_nsec as 64-bit.
> >
> > If we are to be C11 conformant, glibc on x32 has a bug as it defines
> > timespec incorrectly. This hid a bug in the kernel handling the
> > corresponding x32 syscalls. What's the best fix for x32 I can't really
> > tell (we need people to agree on where the bugs are).
> >
> > At least for AArch64 ILP32 we are still free to change the user/kernel
> > ABI, so we could add wrappers for the affected syscalls to fix this up.
> >
>
> yes, afaik on x32 the 64bit kernel expects 64bit layout,
> arm64 can fix this
We have to fix it on all 32-bit architectures when we move to 64-bit time_t.
I think ideally you'd want a user space definition like
typedef long long time_t;
struct timespec {
time_t tv_sec;
long long tv_nsec;
};
which is the only way to avoid passing uninitialized tv_nsec into the kernel
from arbitrary user space doing ioctl. This is of course against POSIX and
C99. Changing POSIX to allow it is probably easier than the C standard,
but we have a couple of years before we need to make this the default.
In the kernel headers, the current plan is to provide interfaces taking
structures
typedef long long __kernel_time64_t;
struct __kernel_timespec64_t {
__kernel_time64_t tv_sec;
long long tv_nsec;
};
at least for ioctls, to avoid the ambiguity with libc headers specifying
something else.
A libc could use other definitions with added padding for what it exports
to user space though, or even make this depend on compile-time flags to
determine whether to make tv_nsec as long long, or to insert padding
in the right place based on endianess.
> > > While most of the other type changes proposed (I'm looking at
> > > https://lkml.org/lkml/2014/9/3/719) are permissible and simply
> > > ugly/undesirable,
> >
> > They may be ugly but definitely not undesirable ;).
> >
>
> several types have the same c level definition across all archs..
> except x32 because of
>
> typedef long long __kernel_long_t;
>
> this should not cause posix/c conformance issues (as you noted
> timespec is ok in the uapi header only the kernel side behaviour
> is wrong)
The kernel behavior is right for the syscalls except ioctl, the uapi
header is wrong (not according to C99, but according to common sense)
and needs to be changed in order to work with big-endian. For x32,
I wonder if we can just #define timespec as __kernel_timespec64
once we introduce that.
> > > Working around the discrepencies in userspace IS possible, but ugly.
> > > We do it in musl libc for x32 right now -- see:
> > >
> > > http://git.musl-libc.org/cgit/musl/tree/arch/x32/syscall_arch.h?id=v1.1.6
> > > http://git.musl-libc.org/cgit/musl/tree/arch/x32/src/syscall_cp_fixup.c?id=v1.1.6
> >
> > For AArch64 ILP32 I would rather see the fix-ups in kernel wrappers.
> >
> > Are you aware of other cases like this?
> >
>
> i know at least one android kernel issue: there is an ioctl for the
> alarm device that takes timespec argument
>
> (i think it's not in the mainline kernel and i guess android does
> not care about x32 so it was not an issue so far, but this is something
> that should not be fixed on the libc side)
ioctl is a known problem with x32 and the ARM ILP32 support. This is
not limited to timespec but to any driver that uses an ioctl with
a data structure that includes a __kernel_long_t or __kernel_ulong_t
argument. There are a couple of drivers using these, and we either
need to change the structures to use 'long' instead, or fix the driver
to be aware of the difference between old-style 32-bit compat and
x32-style compat ioctl handling.
The types affected by this are
include/uapi/asm-generic/posix_types.h:typedef __kernel_ulong_t __kernel_ino_t;
include/uapi/asm-generic/posix_types.h:typedef __kernel_ulong_t __kernel_size_t;
include/uapi/asm-generic/posix_types.h:typedef __kernel_long_t
__kernel_suseconds_t;
include/uapi/asm-generic/posix_types.h:typedef __kernel_long_t
__ker
Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64
Sorry about the HTML mail, I'm currently travelling without access to my regular
mail client.
> "a...@arndb.de" hat am 11. Februar 2015 um 22:02 geschrieben:
>
> Rich Felker hat am 11. Februar 2015 um 21:12 geschrieben:
> > On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote:
> > > > > At least for AArch64 ILP32 we are still free to change the
> > > > > user/kernel
> > > > > ABI, so we could add wrappers for the affected syscalls to fix this
> > > > > up.
> > > > yes, afaik on x32 the 64bit kernel expects 64bit layout,
> > > > arm64 can fix this
> > >
> > > We have to fix it on all 32-bit architectures when we move to 64-bit
> > > time_t.
> > >
> > > I think ideally you'd want a user space definition like
> > >
> > > typedef long long time_t;
> > > struct timespec {
> > > time_t tv_sec;
> > > long long tv_nsec;
> > > };
> > >
> > > which is the only way to avoid passing uninitialized tv_nsec into the
> > > kernel
> > > from arbitrary user space doing ioctl. This is of course against POSIX
> > > and
> > > C99. Changing POSIX to allow it is probably easier than the C standard,
> > > but we have a couple of years before we need to make this the default.
> >
> > I don't see why you want it to be long long. There is no harm in
> > passing uninitialized padding to the kernel; the kernel just needs to
> > do the right thing and ignore it (or avoid reading it to begin with).
>
> This would however mean having three different implementations
> in the kernel rather than just two: Every driver that can pass a timespec
> with this model needs to handle the native 64-bit case (64/64), the legacy
> 32-bit case (32/32) and the y2038-safe case (64/32). Most code can
> already handle the first two, and none today handles the third. If you
> want to make the handling explicitly incompatible with native 64-bit
> mode, you get a lot of untested code in obscure places that are never
> tested properly, while using the normal behavior in the kernel at least
> gives us the same bugs that we already have on native 64-bit systems.
>
> In some cases, there may also be a measurable performance penalty
> in interpreting a user space data structure manually over copying
> it (including the timespec values) in one chunk.
>
> An alternative would be to change the native 64-bit case to ignore the upper
> half of tv_nsec and always just copy the low bits. This should work
> fine almost all of the time, but I fear that there might be corner cases
> where existing 64-bit user space depends on passing large or negative
> tv_nsec values into the kernel.
>
> > The other direction, passing uninitialized data from the kernel to
> > userspace, would be dangerous. But it doesn't happen as long as the
> > userspace padding is positioned (in an endian-dependent manner) where
> > the high bits of the kernel type would lie. It could happen if you
> > used a separate conversion wrapper that ony wrote 32 bits, but if you
> > wanted to take that approach you'd just need the wrapper to also write
> > the padding field manually.
>
> Going from kernel to user space should not be an issue as long as we
> always just write two 64-bit words, and this will zero-fill the upper half.
>
> > > In the kernel headers, the current plan is to provide interfaces taking
> > > structures
> > >
> > > typedef long long __kernel_time64_t;
> > > struct __kernel_timespec64_t {
> > > __kernel_time64_t tv_sec;
> > > long long tv_nsec;
> > > };
> > >
> > > at least for ioctls, to avoid the ambiguity with libc headers specifying
> > > something else.
> >
> > This seems hideous from an application standpoint. Application
> > programmers don't want to know, and shouldn't need to know, these
> > silly implementation details that make no sense except as historical
> > baggage. They should just be able to use "struct timespec" everywhere
> > and have it work.
> The kernel does not even know how timespec is defined by libc, and we have
> to at least be able to handle the common cases of timespec being 32/32
> and 64/64 (or 64/32 plus explicit padding). For system calls, we can rely
> on libc calling the syscalls that match the definition (or convert the
> structure as necessary), while for ioctl the command number is chosen
> by the application and has to match the structure
Re: [PATCHv3 00/24] ILP32 support in ARM64
> Catalin Marinas hat am 12. Februar 2015 um 19:17
> geschrieben:
> On Wed, Feb 11, 2015 at 02:21:18PM -0500, Rich Felker wrote:
> > On Wed, Feb 11, 2015 at 05:39:19PM +, Catalin Marinas wrote:
> > > On Tue, Feb 10, 2015 at 06:13:02PM +, Rich Felker wrote:
> > > > I don't know if this has been discussed on libc-alpha yet or not, but
> > > > I think we need to open a discussion of how it relates to open glibc
> > > > bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64):
> > > >
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=16437
> > >
> > > I'm trying to understand the problem first. Quoting from the bug above
> > > (which I guess is quoted form C11):
> > >
> > > "The range and precision of times representable in clock_t and time_t
> > > are implementation-defined. The timespec structure shall contain at
> > > least the following members, in any order.
> > >
> > > time_t tv_sec; // whole seconds -- >= 0
> > > long tv_nsec; // nanoseconds -- [0, 9]"
> > >
> > > So changing time_t to 64-bit is fine on x32. The timespec struct
> > > exported by the kernel always uses a long for tv_nsec. However, glibc uses
> > > __syscall_slong_t which ends up as 64-bit for x32 (I guess it mirrors
> > > the __kernel_long_t definition).
> > >
> > > So w.r.t. C11, the exported kernel timespec looks fine. But I think the
> > > x32 kernel support (and the current ILP32 patches) assume a native
> > > struct timespec with tv_nsec as 64-bit.
> >
> > The exported kernel timespec is not fine if long is defined as a
> > 32-bit type, which it is for x32 and the proposed aarch64-ILP32 ABIs.
>
> The exported kernel headers comply with POSIX as they use long for
> tv_nsec. The exported headers can be used in user space and with an
> ILP32 ABI, long is 32-bit. The problem is the syscall handler which uses
> the same structure in kernel where long is 64-bit. But this doesn't
> change the fact that the exported header was still correct from a user
> perspective.
This is not ILP32 specific really, we need to add the same set of syscalls
for all 32-bit systems, in addition to the existing ones that take
a 32-bit time_t.
> The solution (for new ports) could be similar to the other such
> solutions in the compat layer. A kernel internal structure which is
> binary-compatible with the ILP32 user one (as exported by the kernel):
>
> struct ilp32_timespec_kernel_internal_only {
> __kernel_time_t tv_sec; /* seconds */
> int tv_nsec; /* nanoseconds */
> };
>
> and a syscall wrapper which converts between ilp32_timespec and timespec
> (take compat_sys_clock_settime as an example).
We then have to to this on all architectures, and not call it ilp32_timespec,
but call it something else.
I would much prefer to only have two versions of each syscall that takes a
timespec rather than three versions, or having a version that behaves
differently based on the type of program calling it. On native 32-bit
systems, we should have the native syscall taking the 16-byte structure
(using long long __kernel_time64_t) along with the compatibility syscall
with a 8-byte structure for existing applications.
On 64-bit systems, the same syscall source can be used for the normal 16-byte
structure on native 64-bit tasks, ilp32 tasks (x32, aarch64-32), and future
compat32 (i386, aarch32, ...) tasks, while the syscall for the 8-byte structure
deals with legacy compat32 tasks that do not yet use __kernel_time64_t.
> If the user structure has some padding (and as I've read in this thread
> it is allowed), it could be even easier for the kernel. The padding
> could be 32-bit before or after tv_nsec, depending on endianness.
The problem as pointed out before is that if you do this, 32-bit tasks
need to have the padding word zeroed at some stage for data passed into
the kernel, while 64-bit tasks need to return an error if the upper half
of the tv_nsec word is nonzero, at least for interfaces that are documented
to do this.
This can be done either in the kernel or in the libc. In the kernel, it
comes down to a function like
int get_user_timespec64(struct timespec64 *ts, struct __kernel_timespec64 __user
*uts, bool task_32bit)
{
struct __kernel_timespec64 input;
if (copy_from_user(&input, uts, sizeof(input))
return -EFAULT;
ts->tv_sec = input.tv_sec;
if (task_32bit)
ts->tv_nsec = (int)input.tv_nsec;
else
ts->tv_nsec = input.tv_nsec;
return 0;
}
with data types of
struct timespec64 {
time64_t tv_sec;
long tv_nsec;
};
struct __kernel_timespec64 {
Re: [PATCH 03/11] ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile
> Florian Fainelli hat am 12. Februar 2015 um 21:02 > geschrieben: > 2015-02-12 11:42 GMT-08:00 Arnd Bergmann : > > A recent cleanup rearranged the Kconfig file for mach-bcm and > > accidentally dropped the dependency on ARCH_MULTI_V7, which > > makes it possible to now build the two mobile SoC platforms > > on an ARMv6-only kernel, resulting in a log of Kconfig > > warnings like > > > > warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct > > dependencies (CPU_V7) > > > > and which of course cannot work on any machine. > > > > This puts back the dependencies as before. > > Since both of these Kconfig options also select ARCH_BCM_MOBILE, you > could put the select there instead? No, that would only work with 'select', but we need 'depends on' here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/1] perf/core: don't find side-band event from all pmus
Em Thu, Mar 31, 2016 at 02:05:46PM +, Liang, Kan escreveu:
>
>
> > > +static void perf_event_sb_mask(unsigned int sb_mask,
> > > +perf_event_aux_output_cb output,
> > > +void *data)
> > > +{
> > > + int sb;
> > > +
> > > + for (sb = 0; sb < sb_nr; sb++) {
> > > + if (!(sb_mask & (1 << sb)))
> > > + continue;
> > > + perf_event_sb_iterate(sb, output, data);
> > > + }
> > > +}
> >
> > > @@ -5852,7 +5910,8 @@ static void perf_event_task(struct task_struct
> > > *task,
> > >
> > > perf_event_aux(perf_event_task_output,
> > > &task_event,
> > > -task_ctx);
> > > +task_ctx,
> > > +(1 << sb_task) | (1 << sb_mmap) | (1 << sb_comm));
> > > }
> >
> > So one side-effect of this change is that the above event can be delivered
> > 3 times if you're 'lucky'.
> >
> > Acme; does userspace care?
>
> Hi Arnaldo,
>
> Do you think if it's an issue for userspace?
Trying to get context and decode what you guys wrote...
- Arnaldo
Re: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success
Em Thu, Nov 05, 2015 at 02:08:48PM +, 平松雅巳 / HIRAMATU，MASAMI escreveu: > From: Wang Nan [mailto:wangn...@huawei.com] > > > >It is possible that find_perf_probe_point_from_map() fails to find > >symbol but still returns 0 because of an small error when coding: > >find_perf_probe_point_from_map() set 'ret' to error code at first, > >but also use it to hold return value of > >kernel_get_symbol_address_by_name(). > > OK, I didn't expect that there is a symbol which can be found by > kernel_get_symbol_address_by_name() but not by __find_kernel_function()... > Would you have any example of the error? > > > > >This patch resets 'ret' to error even kernel_get_symbol_address_by_name() > >success, so if !sym, the whole function returns error correctly. > > Hmm, that sounds tricky. I'd rather like to add *psym to > kernel_get_symbol_address_by_name() > to save symbol and don't use __find_kernel_function() instead. Tricky? I don't think so, suboptimal? possibly, but it fixes an error, so should be processed quickly, right? I'm applying his patch and then whatever improvement can be done on top. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf,tools: check and re-organize evsel cpu maps
Em Tue, Jun 30, 2015 at 03:54:49PM +0200, Jiri Olsa escreveu:
> On Tue, Jun 30, 2015 at 01:42:49PM +, Liang, Kan wrote:
> > > > +static int perf_evlist__check_evsel_cpus(struct perf_evlist *evlist,
> > > > +struct perf_evsel *evsel) {
> > > > + const struct cpu_map *cpus = evlist->cpus;
> > > > + const int ncpus = cpu_map__nr(evlist->cpus);
> > > > + int j = 0, cpu_nr = 0, tmp = 0;
> > > > + int i;
> > > > +
> > > > + /* ensure we process id in increasing order */
> > > > + qsort(evlist->cpus->map, evlist->cpus->nr, sizeof(int),
> > > > cmp_ids);
> > >
> > > wouldn't sorting maps affect some other code?
> > >
> >
> > I didn't find any bad effect after sorting the maps.
> > Any codes I need to check?
>
> I dont think so, but I'm not sure either.. thats why I asked ;-)
>
> I guess any code dealing with cpu maps.. it might affect
> perf stat output.. but it looks sorted now anyway ;-)
> I dont think it's an issue
Is this being done at cpu_map__new time, i.e. when we first parse it?
That way any assumption about repositioning gets out of the way.
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] bonding: force enable lacp port after link state recovery for 802.3ad
> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: 2019年8月28日 6:05 > To: zhangsha (A) > Cc: j.vosbu...@gmail.com; vfal...@gmail.com; a...@greyhouse.net; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; yuehaibing > ; hunongda ; > Chenzhendong (alex) > Subject: Re: [PATCH v2] bonding: force enable lacp port after link state > recovery for 802.3ad > > From: > Date: Fri, 23 Aug 2019 11:42:09 +0800 > > > - If speed/duplex getting failed here, the link status > > will be changed to BOND_LINK_FAIL; > > How does it fail at this step? I suspect this is a driver specific problem. Hi, David, I'm really sorry for the delayed email and appreciated for your feedback. I was testing in kernel 4.19 with a Huawei hinic card when the problem occurred. I checked the dmesg and got the logs in the following order: 1) link status definitely down for interface eth6, disabling it 2) link status up again after 0 ms for interface eth6 3) the paterner's system mac becomes to "00:00:00:00:00:00". By reading the codes, I think that the link status of the slave should be changed to BOND_LINK_FAIL from BOND_LINK_DOWN. As this problem has only occurred once only, I am not very sure about whether this is a driver specific problem or not at the moment. But I find the commit 4d2c0cda, its log says " Some NIC drivers don't have correct speed/duplex settings at the time they send NETDEV_UP notification ...", so I prefer to believe it's not. To my problem I think it is not enough that link-monitoring (miimon) only set SPEED/DUPLEX right, the lacp port should be enabled too at the same time.
RE: [PATCH] bonding: force enable lacp port after link state recovery for 802.3ad
> -Original Message-
> From: Jay Vosburgh [mailto:jay.vosbu...@canonical.com]
> Sent: 2019年8月21日 7:15
> To: zhangsha (A)
> Cc: vfal...@gmail.com; a...@greyhouse.net; da...@davemloft.net;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; yuehaibing
> ; hunongda ;
> Chenzhendong (alex)
> Subject: Re: [PATCH] bonding: force enable lacp port after link state recovery
> for 802.3ad
>
> wrote:
>
> >From: Sha Zhang
> >
> >After the commit 334031219a84 ("bonding/802.3ad: fix slave link
> >initialization transition states") merged, the slave's link status will
> >be changed to BOND_LINK_FAIL from BOND_LINK_DOWN in the following
> >scenario:
> >- Driver reports loss of carrier and
> > bonding driver receives NETDEV_CHANGE notifier
> >- slave's duplex and speed is zerod and
> > its port->is_enabled is cleard to 'false';
> >- Driver reports link recovery and
> > bonding driver receives NETDEV_UP notifier;
> >- If speed/duplex getting failed here, the link status
> > will be changed to BOND_LINK_FAIL;
> >- The MII monotor later recover the slave's speed/duplex
> > and set link status to BOND_LINK_UP, but remains
> > the 'port->is_enabled' to 'false'.
> >
> >In this scenario, the lacp port will not be enabled even its speed and
> >duplex are valid. The bond will not send LACPDU's, and its state is
> >'AD_STATE_DEFAULTED' forever. The simplest fix I think is to force
> >enable lacp after port slave speed check in bond_miimon_commit. As
> >enabled, the lacp port can run its state machine normally after link
> >recovery.
> >
> >Signed-off-by: Sha Zhang
> >---
> > drivers/net/bonding/bond_main.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/net/bonding/bond_main.c
> >b/drivers/net/bonding/bond_main.c index 931d9d9..379253a 100644
> >--- a/drivers/net/bonding/bond_main.c
> >+++ b/drivers/net/bonding/bond_main.c
> >@@ -2194,6 +2194,7 @@ static void bond_miimon_commit(struct bonding
> >*bond) {
> > struct list_head *iter;
> > struct slave *slave, *primary;
> >+struct port *port;
> >
> > bond_for_each_slave(bond, slave, iter) {
> > switch (slave->new_link) {
> >@@ -2205,8 +2206,13 @@ static void bond_miimon_commit(struct bonding
> *bond)
> > * link status
> > */
> > if (BOND_MODE(bond) == BOND_MODE_8023AD &&
> >-slave->link == BOND_LINK_UP)
> >+slave->link == BOND_LINK_UP) {
> >
> bond_3ad_adapter_speed_duplex_changed(slave);
> >+if (slave->duplex == DUPLEX_FULL) {
> >+port = &(SLAVE_AD_INFO(slave)-
> >port);
> >+port->is_enabled = true;
> >+}
> >+}
>
> I don't believe that testing duplex here is correct; is_enabled is not
> controlled by duplex, but by carrier state. Duplex does affect whether or not
> a port is permitted to aggregate, but that's entirely separate logic (the
> AD_PORT_LACP_ENABLED flag).
>
> Would it be better to call bond_3ad_handle_link_change() here,
> instead of manually testing duplex and setting is_enabled?
>
> -J
Hi, Jay,
Thanks for the reply and I think bond_3ad_handle_link_change is indeed a
better way here.
I will send a new patch later after having it tested.
>
> > continue;
> >
> > case BOND_LINK_UP:
> >--
> >1.8.3.1
> >
>
> ---
> -Jay Vosburgh, jay.vosbu...@canonical.com
RE: [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad
> -Original Message-
> From: zhangsha (A)
> Sent: 2019年9月18日 21:06
> To: jay.vosbu...@canonical.com; vfal...@gmail.com; a...@greyhouse.net;
> da...@davemloft.net; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> yuehaibing ; hunongda ;
> Chenzhendong (alex) ; zhangsha (A)
>
> Subject: [PATCH v3] bonding: force enable lacp port after link state recovery
> for
> 802.3ad
>
> From: Sha Zhang
>
> After the commit 334031219a84 ("bonding/802.3ad: fix slave link initialization
> transition states") merged, the slave's link status will be changed to
> BOND_LINK_FAIL from BOND_LINK_DOWN in the following scenario:
> - Driver reports loss of carrier and
> bonding driver receives NETDEV_DOWN notifier
> - slave's duplex and speed is zerod and
> its port->is_enabled is cleard to 'false';
> - Driver reports link recovery and
> bonding driver receives NETDEV_UP notifier;
> - If speed/duplex getting failed here, the link status
> will be changed to BOND_LINK_FAIL;
> - The MII monotor later recover the slave's speed/duplex
> and set link status to BOND_LINK_UP, but remains
> the 'port->is_enabled' to 'false'.
>
> In this scenario, the lacp port will not be enabled even its speed and duplex
> are
> valid. The bond will not send LACPDU's, and its state is 'AD_STATE_DEFAULTED'
> forever. The simplest fix I think is to call bond_3ad_handle_link_change() in
> bond_miimon_commit, this function can enable lacp after port slave speed
> check.
> As enabled, the lacp port can run its state machine normally after link
> recovery.
>
> Signed-off-by: Sha Zhang
> ---
> drivers/net/bonding/bond_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c index 931d9d9..76324a5 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2206,7 +2206,8 @@ static void bond_miimon_commit(struct bonding
> *bond)
>*/
> if (BOND_MODE(bond) == BOND_MODE_8023AD &&
> slave->link == BOND_LINK_UP)
> -
> bond_3ad_adapter_speed_duplex_changed(slave);
> + bond_3ad_handle_link_change(slave,
> + BOND_LINK_UP);
> continue;
>
> case BOND_LINK_UP:
Hi, David,
I have replied your email for a while, I guess you may miss my email, so I
resend it.
The following link address is the last email, please review the new one again,
thank you.
https://patchwork.ozlabs.org/patch/1151915/
Last time, you doubted this is a driver specific problem,
I prefer to believe it's not because I find the commit 4d2c0cda,
its log says " Some NIC drivers don't have correct speed/duplex
settings at the time they send NETDEV_UP notification ...".
Anyway, I think the lacp status should be fixed correctly,
since link-monitoring (miimon) set SPEED/DUPLEX right here.
> --
> 1.8.3.1
RE: [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad
> -Original Message-
> From: Jay Vosburgh [mailto:jay.vosbu...@canonical.com]
> Sent: 2019年9月19日 16:12
> To: zhangsha (A)
> Cc: vfal...@gmail.com; a...@greyhouse.net; da...@davemloft.net;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; yuehaibing
> ; hunongda ;
> Chenzhendong (alex)
> Subject: Re: [PATCH v3] bonding: force enable lacp port after link state
> recovery for 802.3ad
>
> zhangsha (A) wrote:
>
> >> -Original Message-
> >> From: zhangsha (A)
> >> Sent: 2019年9月18日 21:06
> >> To: jay.vosbu...@canonical.com; vfal...@gmail.com;
> >> a...@greyhouse.net; da...@davemloft.net; net...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; yuehaibing ;
> >> hunongda ; Chenzhendong (alex)
> >> ; zhangsha (A)
> >> Subject: [PATCH v3] bonding: force enable lacp port after link state
> >> recovery for 802.3ad
> >>
> >> From: Sha Zhang
> >>
> >> After the commit 334031219a84 ("bonding/802.3ad: fix slave link
> >> initialization transition states") merged, the slave's link status
> >> will be changed to BOND_LINK_FAIL from BOND_LINK_DOWN in the
> following scenario:
> >> - Driver reports loss of carrier and
> >> bonding driver receives NETDEV_DOWN notifier
> >> - slave's duplex and speed is zerod and
> >> its port->is_enabled is cleard to 'false';
> >> - Driver reports link recovery and
> >> bonding driver receives NETDEV_UP notifier;
> >> - If speed/duplex getting failed here, the link status
> >> will be changed to BOND_LINK_FAIL;
> >> - The MII monotor later recover the slave's speed/duplex
> >> and set link status to BOND_LINK_UP, but remains
> >> the 'port->is_enabled' to 'false'.
> >>
> >> In this scenario, the lacp port will not be enabled even its speed
> >> and duplex are valid. The bond will not send LACPDU's, and its state is
> 'AD_STATE_DEFAULTED'
> >> forever. The simplest fix I think is to call
> >> bond_3ad_handle_link_change() in bond_miimon_commit, this function
> >> can enable lacp after port slave speed check.
> >> As enabled, the lacp port can run its state machine normally after link
> recovery.
> >>
> >> Signed-off-by: Sha Zhang
> >> ---
> >> drivers/net/bonding/bond_main.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/bonding/bond_main.c
> >> b/drivers/net/bonding/bond_main.c index 931d9d9..76324a5 100644
> >> --- a/drivers/net/bonding/bond_main.c
> >> +++ b/drivers/net/bonding/bond_main.c
> >> @@ -2206,7 +2206,8 @@ static void bond_miimon_commit(struct bonding
> >> *bond)
> >> */
> >>if (BOND_MODE(bond) == BOND_MODE_8023AD &&
> >>slave->link == BOND_LINK_UP)
> >> -
> >>bond_3ad_adapter_speed_duplex_changed(slave);
> >> + bond_3ad_handle_link_change(slave,
> >> + BOND_LINK_UP);
> >>continue;
> >>
> >>case BOND_LINK_UP:
> >
> >Hi, David,
> >I have replied your email for a while, I guess you may miss my email, so I
> resend it.
> >The following link address is the last email, please review the new one
> >again,
> thank you.
> >https://patchwork.ozlabs.org/patch/1151915/
> >
> >Last time, you doubted this is a driver specific problem, I prefer to
> >believe it's not because I find the commit 4d2c0cda, its log says "
> >Some NIC drivers don't have correct speed/duplex settings at the time
> >they send NETDEV_UP notification ...".
> >
> >Anyway, I think the lacp status should be fixed correctly, since
> >link-monitoring (miimon) set SPEED/DUPLEX right here.
>
> I suspect this is going to be related to the concurrent discussion with
> Aleksei, and would like to see the instrumentation results from his tests
> before
> adding another change to attempt to resolve this.
>
> Also, what device are you using for your testing, and are you able to
> run the instrumentation patch that I provided to Aleksei and provide its
> results?
>
> -J
>
Yes, I think it's the same problem.
I am using a Huawei hinic card with kernel 4.19 and got the same message and the
weird system mac "00:00:00:00:00:00":
"link status definitely down for interface eth6, disabling it
link status up again after 0 ms for interface eth6"
I will run your instrumentation patch, but maybe I need more times.
In fact, I have tried to reproduce the problem for thousands of times, but
never succeeded.
> ---
> -Jay Vosburgh, jay.vosbu...@canonical.com
[PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
On x86-64, for 32-bit PC-relacive branches, we can generate PLT32 relocation,
instead of PC32 relocation. and R_X86_64_PLT32 can be treated the same as
R_X86_64_PC32 since linux kernel doesn't use PLT.
In linux 4.4 commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32")
been fixed for the module loading, but not fixed for livepatch relocation,
which will fail to load livepatch with the error message as follow:
relocation failed for symbol at
Signed-off-by: chenzefeng
---
arch/x86/kernel/livepatch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c index
d1d35cc..579f8f8 100644
--- a/arch/x86/kernel/livepatch.c
+++ b/arch/x86/kernel/livepatch.c
@@ -58,6 +58,7 @@ int klp_write_module_reloc(struct module *mod, unsigned long
type,
val = (s32)value;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
val = (u32)(value - loc);
break;
default:
--
1.8.5.6
答复: [PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
HI, Jiri Kosina,
On Fri, 15 Feb 2019, Jiri Kosina wrote:
>On Fri, 15 Feb 2019, chenzefeng (A) wrote:
>> On x86-64, for 32-bit PC-relacive branches, we can generate PLT32
>> relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be
>> treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT.
>>
>> In linux 4.4 commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as
>> R_X86_64_PC32") been fixed for the module loading, but not fixed for
>> livepatch relocation, which will fail to load livepatch with the error
>> message as follow: relocation failed for symbol at
>> > address>
>>
>> Signed-off-by: chenzefeng
>What kernel version is this patch based on? We've got rid of x86-specific
>module loading stub and offloaded all the relocation handling to generic kmod
>loader long time ago.
The patch is based on kernel version Linux 4.4.174.
Thanks.
chenzefeng
Re: [PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
Hi,
I am sorry this email was sent by accident. Please ignore this email.
Best Regards
-邮件原件-
发件人: chenzefeng (A)
发送时间: 2019年2月19日 14:38
收件人: 'Petr Mladek' ; chengjian (D)
抄送: 'sta...@vger.kernel.org' ; Jiri Kosina
; hjl.to...@gmail.com; jpoim...@redhat.com;
sjenn...@redhat.com; vojt...@suse.com; t...@linutronix.de; mi...@redhat.com;
h...@zytor.com; gre...@linuxfoundation.org; x...@kernel.org;
live-patch...@vger.kernel.org; linux-kernel@vger.kernel.org; Xiexiuqi
主题: Re:[PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
On Mon 2019-02-18 17:22, Petr wrote:
> On Mon 2019-02-18 13:29:11, chengjian (D) wrote:
> > Hi，Jiri
> >
> >
> > This patch should be merged into 4.4 stable,
> >
> > which still use klp_write_module_reloc.
> >
> >
> > https://elixir.bootlin.com/linux/v4.4.174/source/arch/x86/kernel/livep
> > atch.c
> >
> >
> > ZeFeng may have sent a stable(4.4-y) patch to the wrong mail-list(mainline).
>
> ZeFeng or Chengjian, please, send the patch once again with
> sta...@vger.kernel.org in CC and explanation that it is needed only for 4.4
> and why.
>
> This thread is already too long and messed to be proceed by stable people
> effectively.
>
> Best Regards,
> Petr
On x86-64, for 32-bit PC-relacive branches, we can generate PLT32 relocation,
instead of PC32 relocation. and R_X86_64_PLT32 can be treated the same as
R_X86_64_PC32 since linux kernel doesn't use PLT.
commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") been fixed
for the module loading, but not fixed for livepatch relocation, which will fail
to load livepatch with the error message as follow:
relocation failed for symbol at
This issue only effacted the kernel version from 4.0 to 4.6, becauce the
function klp_write_module_reloc is introduced by:
commit b700e7f03df5 ("livepatch: kernel: add support for live patching") and
deleted by: commit 425595a7fc20
("livepatch: reuse module loader code to write relocations")
Signed-off-by: chenzefeng
---
arch/x86/kernel/livepatch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c index
d1d35cc..579f8f8 100644
--- a/arch/x86/kernel/livepatch.c
+++ b/arch/x86/kernel/livepatch.c
@@ -58,6 +58,7 @@ int klp_write_module_reloc(struct module *mod, unsigned long
type,
val = (s32)value;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
val = (u32)(value - loc);
break;
default:
--
1.8.5.6
Re: [PATCH] squashfs: fix mtime underflow on 64 bit system
Ping? On 2019/1/17 16:21, zhengbin wrote: > If we change the file mtime to 1969, mksquashfs and mount, > the atime/mtime of this file will be underflow. The reason is > treating timestamps with the high bit set as positive > times(before 1970), which should be set as negative times > just like on 32 bit system. After this, the poissble range > of timestamps will be 1901-2038(prev is 1970-2106) on 64 > bit system. > > Signed-off-by: zhengbin > --- > fs/squashfs/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/squashfs/inode.c b/fs/squashfs/inode.c > index e9793b1e49a5..03a6ef77a2d2 100644 > --- a/fs/squashfs/inode.c > +++ b/fs/squashfs/inode.c > @@ -72,7 +72,7 @@ static int squashfs_new_inode(struct super_block *sb, > struct inode *inode, > i_uid_write(inode, i_uid); > i_gid_write(inode, i_gid); > inode->i_ino = le32_to_cpu(sqsh_ino->inode_number); > - inode->i_mtime.tv_sec = le32_to_cpu(sqsh_ino->mtime); > + inode->i_mtime.tv_sec = (signed int)le32_to_cpu(sqsh_ino->mtime); > inode->i_atime.tv_sec = inode->i_mtime.tv_sec; > inode->i_ctime.tv_sec = inode->i_mtime.tv_sec; > inode->i_mode = le16_to_cpu(sqsh_ino->mode); > -- > 2.16.2.dirty > > > . >
RE: [PATCH v3] binderfs: fix error return code in binderfs_fill_super()
Sorry, please ignore this patch, missing reviewed-by line, I will send a new
version.
> -Original Message-
> From: weiyongjun (A)
> Sent: Wednesday, January 16, 2019 6:39 PM
> To: gre...@linuxfoundation.org; a...@android.com; tk...@android.com;
> m...@android.com; j...@joelfernandes.org; christ...@brauner.io
> Cc: weiyongjun (A) ;
> de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; kernel-
> janit...@vger.kernel.org
> Subject: [PATCH v3] binderfs: fix error return code in binderfs_fill_super()
>
> Fix to return a negative error code -ENOMEM from the new_inode() and
> d_make_root() error handling cases instead of 0, as done elsewhere in
> this function.
>
> Fixes: 849d540ddfcd ("binderfs: implement "max" mount option")
> Signed-off-by: Wei Yongjun
> ---
> v1 -> v2: move 'ret = -ENOMEM' out of if
> v2 -> v3: use correct fixes commit
> ---
> drivers/android/binderfs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 9518e2e..e4ff4c3 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -518,6 +518,7 @@ static int binderfs_fill_super(struct super_block *sb,
> void *data, int silent)
>
> sb->s_fs_info = info;
>
> + ret = -ENOMEM;
> inode = new_inode(sb);
> if (!inode)
> goto err_without_dentry;
>
>
Re: [PATCH] staging: android: ion: move map_kernel to ion_dma_buf_kmap
On 2019/1/3 6:36, Laura Abbott wrote:
On 12/24/18 12:19 AM, Qing Xia wrote:
Now, as Google's user guide, if userspace need clean ION buffer's
cache, they should call ioctl(fd, DMA_BUF_IOCTL_SYNC, sync). Then
we found that ion_dma_buf_begin_cpu_access/ion_dma_buf_end_cpu_access
will do ION buffer's map_kernel, it's not necessary. And if usersapce
only need clean cache, they will call ion_dma_buf_end_cpu_access by
dmabuf's ioctl, ION buffer's kmap_cnt will be wrong value -1, then
driver could not get right kernel vaddr by dma_buf_kmap.
The problem is this subtly violates how dma_buf is supposed
to work. All setup is supposed to happen in begin_cpu_access.
I agree calling map kernel each time isn't great but I think
this needs to be worked out with dma_buf.
Thanks,
Laura
Thanks for your explanation.
Signed-off-by: Qing Xia
---
drivers/staging/android/ion/ion.c | 46 ++-
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 9907332..f7e2812 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -303,45 +303,47 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
{
struct ion_buffer *buffer = dmabuf->priv;
+ void *vaddr;
- return buffer->vaddr + offset * PAGE_SIZE;
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ vaddr = ion_buffer_kmap_get(buffer);
+ mutex_unlock(&buffer->lock);
+ if (IS_ERR(vaddr))
+ return vaddr;
+
+ return vaddr + offset * PAGE_SIZE;
+ }
+
+ return NULL;
}
static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
void *ptr)
{
+ struct ion_buffer *buffer = dmabuf->priv;
+
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ ion_buffer_kmap_put(buffer);
+ mutex_unlock(&buffer->lock);
+ }
}
static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
enum dma_data_direction direction)
{
struct ion_buffer *buffer = dmabuf->priv;
- void *vaddr;
struct ion_dma_buf_attachment *a;
- int ret = 0;
-
- /*
- * TODO: Move this elsewhere because we don't always need a vaddr
- */
- if (buffer->heap->ops->map_kernel) {
- mutex_lock(&buffer->lock);
- vaddr = ion_buffer_kmap_get(buffer);
- if (IS_ERR(vaddr)) {
- ret = PTR_ERR(vaddr);
- goto unlock;
- }
- mutex_unlock(&buffer->lock);
- }
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
direction);
}
-
-unlock:
mutex_unlock(&buffer->lock);
- return ret;
+
+ return 0;
}
static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
@@ -350,12 +352,6 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
struct ion_dma_buf_attachment *a;
- if (buffer->heap->ops->map_kernel) {
- mutex_lock(&buffer->lock);
- ion_buffer_kmap_put(buffer);
- mutex_unlock(&buffer->lock);
- }
-
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
dma_sync_sg_for_device(a->dev, a->table->sgl, a->table->nents,
.
Re: [PATCH] squashfs: fix mtime underflow on 64 bit system
hi Phillip, when you have time, help to confirm it? Looking forward to your reply. On 2019/1/17 16:21, zhengbin wrote: > If we change the file mtime to 1969, mksquashfs and mount, > the atime/mtime of this file will be underflow. The reason is > treating timestamps with the high bit set as positive > times(before 1970), which should be set as negative times > just like on 32 bit system. After this, the poissble range > of timestamps will be 1901-2038(prev is 1970-2106) on 64 > bit system. > > Signed-off-by: zhengbin > --- > fs/squashfs/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/squashfs/inode.c b/fs/squashfs/inode.c > index e9793b1e49a5..03a6ef77a2d2 100644 > --- a/fs/squashfs/inode.c > +++ b/fs/squashfs/inode.c > @@ -72,7 +72,7 @@ static int squashfs_new_inode(struct super_block *sb, > struct inode *inode, > i_uid_write(inode, i_uid); > i_gid_write(inode, i_gid); > inode->i_ino = le32_to_cpu(sqsh_ino->inode_number); > - inode->i_mtime.tv_sec = le32_to_cpu(sqsh_ino->mtime); > + inode->i_mtime.tv_sec = (signed int)le32_to_cpu(sqsh_ino->mtime); > inode->i_atime.tv_sec = inode->i_mtime.tv_sec; > inode->i_ctime.tv_sec = inode->i_mtime.tv_sec; > inode->i_mode = le16_to_cpu(sqsh_ino->mode); > -- > 2.16.2.dirty > > > . >
