Hello, I'm a new entry in this kernel mailing list.
I'm working on udp functions (those in ipv4/udp.c) and I'm focusing on
"udp_sendmsg(..)" and "udp_recvmsg". I'm trying to understand what is the
duty, what these next functions(used by udp_sendmsg and/or udp_recvmsg) really
do:
ip_cmsg_
Hi,
On this list new version of XFS for Linux has just been announced.
Reiserfs has been included into official kernel tree. My question is
about benchmarks beetween XFS and rfs. XFS is said to a very flexible
and fast journaling filesystem (well, at least by SGI ;-) and rfs seems
to be cool too.
Hello all,
I am developing a UDP application and wish to receive
the ICMP unreachable messages that some hosts send in
response to a UDP datagram that hits a closed port. I
use the IP_RECVERR on my socket, recvmsg (fd, &msg,
MSG_ERRQUEUE) and all that, however the returned port
in the sock_extended
2012/10/16 Andrew Morton :
> On Mon, 15 Oct 2012 19:38:46 +0800
> Qing Z wrote:
>
>> >> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
>> >>
>> >> + /*
>> >> + * Unlock the console anyway here, in case it&#x
2012/10/18 Andrew Morton :
> On Wed, 17 Oct 2012 18:44:32 +0800
> Qing Z wrote:
>
>> In ./drivers/video/fbmem.c, codes below cause issues:
>>
>> case FBIOPAN_DISPLAY:
>> ...
>
Hello,
booting vanilla 3.7-rc8 kernel on Acer Aspire 1810TZ yields these
errors (I was using 3.6.9-1 and 3.5.5-1 from Debian experimental
before without these errors)
[9.265058] attempt to access beyond end of device
[9.265063] sda1: rw=0, want=968382504, limit=968382503
[9.265066
On Mon, Dec 10, 2012 at 12:06 PM, Lekensteyn wrote:
> On Monday 10 December 2012 11:42:22 M Z wrote:
>> booting vanilla 3.7-rc8 kernel on Acer Aspire 1810TZ yields these
>> errors (I was using 3.6.9-1 and 3.5.5-1 from Debian experimental
>> before without these errors)
> On Thu, 11 Oct 2012 16:03:07 +0800
> Qing Zhu wrote:
>
>> Panic log should be printed on the console, but if someone lock the
>> console when panic, console won't print out panic log.
>>
>> The incomplete panic log issue will happen in below scenarios:
>> 1. One task call console_lock(), then pa
2012/10/16 Andrew Morton :
> On Mon, 15 Oct 2012 19:38:46 +0800
> Qing Z wrote:
>
>> >> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
>> >>
>> >> + /*
>> >> + * Unlock the console anyway here, in case it&#x
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> After v5.10 was officially declared an LTS kernel, I had a look around
> the Arm platforms that look like they have not seen any patches from
> their maintainers or users that are actually running the hardware for
> at least five year
(resending this email in case the first one got caught in your spam
filter. sorry.)
On Thu, Jul 17, 2014 at 06:25:26PM +0100, Will Deacon wrote:
> On Thu, Jul 17, 2014 at 04:59:10PM +0100, Alexei Starovoitov wrote:
> > On Thu, Jul 17, 2014 at 2:19 AM, Will Deacon wrote:
> > > On Wed, Jul 16, 2014
(resending this email in case the first one got caught in your spam
filter. sorry.)
On Thu, Jul 17, 2014 at 10:41:02AM +0100, Will Deacon wrote:
> On Wed, Jul 16, 2014 at 11:04:22PM +0100, Zi Shen Lim wrote:
> > On Wed, Jul 16, 2014 at 05:17:15PM +0100, Will Deacon wrote:
> > > On Tue, Jul 15, 201
On Thu, Sep 11, 2014 at 3:45 AM, Will Deacon wrote:
> On Thu, Sep 11, 2014 at 10:36:48AM +0100, Daniel Borkmann wrote:
>> On ARM64, when the BPF JIT compiler fills the JIT image body with
>> opcodes during translation of eBPF into ARM64 opcodes, we may fail
>> for several reasons during that phase
On Fri, Sep 12, 2014 at 10:35 AM, Daniel Borkmann wrote:
> This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
> jit against spraying attacks").
>
> Thanks to commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX
> support") which added necessary infrastructure, we ca
On Tue, Sep 16, 2014 at 9:25 AM, Will Deacon wrote:
> On Tue, Sep 16, 2014 at 08:48:50AM +0100, Daniel Borkmann wrote:
>> This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf
>> jit against spraying attacks").
>>
>> Thanks to commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_M
optimizations that'll generate code that
loops at 0xa8 instead of 0xa0. w1 only needs to loaded with the
constant once, but here we're reloading it on every iteration of the
loop.
Thanks,
z
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Wed, Jul 2, 2014 at 2:28 PM, Alexei Starovoitov wrote:
> On Tue, Jul 1, 2014 at 10:20 PM, Zi Shen Lim wrote:
>> The JIT compiler emits A64 instructions. It supports eBPF only.
>> Legacy BPF is supported thanks to conversion by BPF core.
>>
>> JIT is enabled in the same way as for other archite
On Wed, Jul 2, 2014 at 9:57 PM, Z Lim wrote:
> On Wed, Jul 2, 2014 at 2:28 PM, Alexei Starovoitov wrote:
>> On Tue, Jul 1, 2014 at 10:20 PM, Zi Shen Lim wrote:
>> Do you really need 'jump by register' then? Regular 'bl' would be much
>> faster.
On Thu, Jul 3, 2014 at 1:10 AM, Daniel Borkmann wrote:
> Hi Zi,
>
>
> On 07/03/2014 09:52 AM, Zi Shen Lim wrote:
>>
>> load_pointer() is already a static inline function.
>> Let's move it into filter.h so BPF JIT implementations can reuse this
>> function.
>>
>> Signed-off-by: Zi Shen Lim
>> ---
On Tue, Jul 8, 2014 at 2:24 AM, Alexei Starovoitov wrote:
> On Tue, Jul 8, 2014 at 12:06 AM, Zi Shen Lim wrote:
[...]
>> Also, per discussion with Alexei, and additional suggestion from
>> Daniel:
>> - moved load_pointer() from net/core/filter.c into filter.h
>> as bpf_load_pointer()
>>
ly overlap at this point is B/BL codegen.
A whole lot more, e.g. arithmetic, logical, and memory ops, will need
to be shuffled in.
Let me address Alexei's review comments and send out a v2.
After that, I can take a stab at consolidating bpf_jit.h into
insn.{c,h}. Sounds good to you?
Thanks,
z
>
> Cheers,
>
> Will
--
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/
On Mon, Jul 21, 2014 at 8:49 AM, Alexei Starovoitov wrote:
> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon wrote:
[...]
>>> This series applies against net-next and is tested working
>>> with lib/test_bpf on ARMv8 Foundation Model.
>>
>> Looks like it works on my Juno board too, so:
>>
>> Acked-
On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
wrote:
> On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
>> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon wrote:
>> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
[...]
>> >> This series applies against net-next a
Hi
03.02.2014, 05:15, "David Fries" :
> I could submit these patches as in, which would require the previous
> set, or I could merge the documentation into the previous set and
> resubmit them all since they haven't made it into the kernel tree yet.
> Opinions?
>
> Here's a small refcnt fix,
Hi Will,
On Tue, Aug 26, 2014 at 2:58 AM, Will Deacon wrote:
> Hi Z Lim,
>
> On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote:
>> On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
>> wrote:
>> > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wro
Hi Andre,
On Thu, Oct 23, 2014 at 10:00 AM, Andre Przywara wrote:
> Hi,
>
> I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump
> below). Userland tries to carry on afterwards, but eventually hangs in
> RCU stalls.
> The kernel has just CONFIG_BPF_JIT enabled, I guess Ubuntu
g the lines of: this is an
optimization saving 2 instructions per jited BPF program.
Thanks :)
z
> Apply on top of Daniel's blinding constant patchset.
>
> arch/arm64/net/bpf_jit_comp.c | 32
> 1 file changed, 4 insertions(+), 28 deletions(-)
>
On Thu, Nov 12, 2015 at 1:57 PM, Yang Shi wrote:
> BPF fp should point to the top of the BPF prog stack. The original
> implementation made it point to the bottom incorrectly.
> Move A64_SP to fp before reserve BPF prog stack space.
>
> CC: Zi Shen Lim
> CC: Xi Wang
> Signed-off-by: Yang Shi
>
On Thu, Nov 12, 2015 at 1:57 PM, Yang Shi wrote:
>
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during function call so it m
On Thu, Nov 12, 2015 at 11:33 AM, Shi, Yang wrote:
> On 11/11/2015 4:39 AM, Will Deacon wrote:
>>
>> Wait a second, we're both talking rubbish here :) The STR (immediate)
>> form is referring to the addressing mode, whereas this patch wants to
>> store an immediate value to memory, which does need
Yang, I noticed another thing...
On Fri, Nov 13, 2015 at 10:09 AM, Yang Shi wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> ch
On Wed, Nov 18, 2015 at 1:07 PM, Shi, Yang wrote:
> On 11/18/2015 12:56 AM, Zi Shen Lim wrote:
>> emit_a64_mov_i64(r3, size, ctx);
>> - emit(A64_ADD_I(1, r4, fp, MAX_BPF_STACK), ctx);
>> + emit(A64_SUB_I(1, r4, fp, STACK_SIZE), ctx);
>
>
> Should not it
Hi Alexei,
On Sat, Nov 29, 2014 at 2:46 PM, Alexei Starovoitov wrote:
> classic BPF has a restriction that last insn is always BPF_RET.
> eBPF doesn't have BPF_RET instruction and this restriction.
> It has BPF_EXIT insn which can appear anywhere in the program
> one or more times and it doesn't
On Sat, Nov 7, 2015 at 6:27 PM, Alexei Starovoitov
wrote:
> On Fri, Nov 06, 2015 at 09:36:17PM -0800, Yang Shi wrote:
>> ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to
>> change during function call so it may cause the BPF prog stack base address
>> change too. Whenever, it po
On Mon, Nov 9, 2015 at 10:08 AM, Shi, Yang wrote:
> I added it to stay align with ARMv8 AAPCS to maintain the correct FP during
> function call. It makes us get correct stack backtrace.
>
> I think we'd better to keep compliant with ARMv8 AAPCS in BPF JIT prologue
> too.
>
> If nobody thinks it is
On Tue, Nov 10, 2015 at 2:41 PM, Yang Shi wrote:
> aarch64 doesn't have native store immediate instruction, such operation
Actually, aarch64 does have "STR (immediate)". For arm64 JIT, we can
consider using it as an optimization.
You may also want to consider adding a note about the correspondin
Yang,
On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
wrote:
> On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
>> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
>> >On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
>> >>aarch64 doesn't have native support for XADD instruction, impleme
On Tue, Nov 10, 2015 at 11:46 AM, Shi, Yang wrote:
> On 11/9/2015 12:00 PM, Z Lim wrote:
>>
>> How about splitting this into two patches? One for the BPF-related
>> bug, and another for A64 FP-handling.
>
> I'm not sure if this is a good approach or not. IMHO, th
On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during function call so it may
On Wed, Nov 4, 2015 at 10:21 AM, Shi, Yang wrote:
> On 11/3/2015 11:04 PM, Xi Wang wrote:
>>
>> On Tue, Nov 3, 2015 at 10:56 PM, Zi Shen Lim wrote:
>>>
>>> case BPF_ALU | BPF_DIV | BPF_X:
>>> case BPF_ALU64 | BPF_DIV | BPF_X:
>>> + {
>>> + const u8 r0 = bpf2a
On Wed, Nov 4, 2015 at 11:36 AM, Yang Shi wrote:
> When running "mod X" operation, if X is 0 the filter has to be halt.
> Add new test cases to cover A = A mod X if X is 0, and A = A mod 1.
>
> CC: Xi Wang
> CC: Zi Shen Lim
> Signed-off-by: Yang Shi
> ---
Acked-by: Zi Shen Lim
--
To unsubscri
Hi Will,
On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon wrote:
> On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
>> Remove superfluous stack frame, saving us 3 instructions for
>> every JMP_CALL.
>>
>> Signed-off-by: Zi Shen Lim
>> ---
>> arch/arm64/net/bpf_jit_comp.c | 3 ---
>> 1 f
ettings from DHCP server
> if IPv6 is enabled on "Dumb AP" board. If IPv6 is disabled I may see that
> wireless client sends "DHCP Discover" then server replies with "DHCP Offer"
> but
> that offer never reaches wireless client.
Do you have WDS enabled? If not, DHCP has issues in that scenario:
https://wiki.openwrt.org/doc/howto/clientmode
Aaron Z
of
>> 'ERR_PTR' was here
>> return ERR_PTR(-EOPNOTSUPP);
>> ^
>> cc1: some warnings being treated as errors
>
>
> Looks like including linux/bpf.h at the very beginning causes issues when
> bpf
> syscall is disabled. We
>
> Le Sun, Oct 20, 2024 at 08:51:19PM +0800, Zqiang a écrit :
> > Currently, running rcutorture test with torture_type=rcu fwd_progress=8
> > n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60
> > test_boost=2, will trigger the following warning:
> >
> > WARNING: CPU: 19 PID: 100
>
> >
> > Le Sun, Oct 20, 2024 at 08:51:19PM +0800, Zqiang a écrit :
> > > Currently, running rcutorture test with torture_type=rcu fwd_progress=8
> > > n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60
> > > test_boost=2, will trigger the following warning:
> > >
> > > WARNING: C
>
> Le Mon, Oct 21, 2024 at 07:01:02PM +0800, Z qiang a écrit :
> > > For the non-nocb cpus set during boot, the corresponding
> > > rcuop kthread, we should park directly, otherwise
> > > WARN_ON_ONCE(!rcu_rdp_is_offloaded(rdp)) will be triggered.
>
> Ah b
>
> On Sat, Dec 14, 2024 at 09:53:13PM +0100, Greg Kroah-Hartman wrote:
> > I'm announcing the release of the 6.1.120 kernel.
> >
> > All users of the 6.1 kernel series must upgrade.
> >
> > The updated 6.1.y git tree can be found at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/l
>
> This commit adds a new rcutorture.n_up_down kernel boot parameter
> that specifies the number of outstanding SRCU up/down readers, which
> begin in kthread context and end in an hrtimer handler. There is a new
> kthread ("rcu_torture_updown") that scans an per-reader array looking
> for elemen
>
> >
> > Le Mon, Apr 28, 2025 at 05:54:03PM +0800, Zqiang a écrit :
> > > For Preempt-RT kernel, when enable CONFIG_PROVE_RCU Kconfig,
> > > disable local bh in rcuc kthreads will not affect preempt_count(),
> > > this resulted in the following splat:
> > >
> > > WARNING: suspicious RCU usage
> >
>
>
>
> On 4/28/2025 6:59 AM, Z qiang wrote:
> >>
> >> Le Mon, Apr 28, 2025 at 05:54:03PM +0800, Zqiang a écrit :
> >>> For Preempt-RT kernel, when enable CONFIG_PROVE_RCU Kconfig,
> >>> disable local bh in rcuc kthreads will not affect preem
>
>
>
> On 4/30/2025 12:14 PM, Joel Fernandes wrote:
> >
> >
> > On 4/30/2025 10:57 AM, Z qiang wrote:
> >>>
> >>>
> >>>
> >>> On 4/28/2025 6:59 AM, Z qiang wrote:
> >>>>>
> >>&
>
> Le Mon, Apr 28, 2025 at 05:54:03PM +0800, Zqiang a écrit :
> > For Preempt-RT kernel, when enable CONFIG_PROVE_RCU Kconfig,
> > disable local bh in rcuc kthreads will not affect preempt_count(),
> > this resulted in the following splat:
> >
> > WARNING: suspicious RCU usage
> > kernel/rcu/tree_
On Thu, May 8, 2025 at 12:25 AM Frederic Weisbecker wrote:
>
> Le Wed, May 07, 2025 at 07:26:04PM +0800, Zqiang a écrit :
> > For built with CONFIG_PROVE_RCU=y and CONFIG_PREEMPT_RT=y kernels,
> > Disable BH does not change the SOFTIRQ corresponding bits in
> > preempt_count(), but change current-
>
> On Thu, May 8, 2025 at 12:25 AM Frederic Weisbecker
> wrote:
> >
> > Le Wed, May 07, 2025 at 07:26:04PM +0800, Zqiang a écrit :
> > > For built with CONFIG_PROVE_RCU=y and CONFIG_PREEMPT_RT=y kernels,
> > > Disable BH does not change the SOFTIRQ corresponding bits in
> > > preempt_count(), bu
>
> On Wed, May 07, 2025 at 07:26:05PM +0800, Zqiang wrote:
> > In the preparation stage of CPU online, if the corresponding
> > the rdp's->nocb_cb_kthread does not exist, will be created,
> > there is a situation where the rdp's rcuop kthreads creation fails,
> > and then de-offload this CPU's rdp
>
> On 5/9/2025 3:07 PM, Joel Fernandes wrote:
> >
> >
> > On 5/7/2025 7:26 AM, Zqiang wrote:
> >> In the preparation stage of CPU online, if the corresponding
> >> the rdp's->nocb_cb_kthread does not exist, will be created,
> >> there is a situation where the rdp's rcuop kthreads creation fails,
>
>
> Hi Linus,
>
> When the merge window opens, please pull the RCU changes for v6.16:
>
> The following changes since commit 0af2f6be1b4281385b618cb86ad946eded089ac8:
>
> Linux 6.15-rc1 (2025-04-06 13:11:33 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linu
Some error paths did not handle ref counting properly, and some trace files need
ref counting.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c| 34 +++---
kernel/trace/trace_events.c | 21
ftrace_trace_arrays.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ca2743b..4ea9967 100644
--- a/kernel/trace/trace.c
David Rientjes wrote on 2013-04-18:
> On Wed, 17 Apr 2013, Randy Dunlap wrote:
>
>> On 04/17/13 16:12, David Rientjes wrote:
>>> The build fails when CONFIG_SMP is disabled:
>>>
>>> arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt':
>>> arch/x86/kvm/vmx.c:3950:3: error: 'apic
Randy Dunlap wrote on 2013-04-18:
> On 04/17/13 17:35, Zhang, Yang Z wrote:
>> David Rientjes wrote on 2013-04-18:
>>> On Wed, 17 Apr 2013, Randy Dunlap wrote:
>>>
>>>> On 04/17/13 16:12, David Rientjes wrote:
>>>>> The build fails when CON
There are multiple places where the ftrace_trace_arrays list is accessed in
trace_events.c without the trace_types_lock held.
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace_events.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff
The trace_marker file was present for each new instance created, but it
added the trace mark to the global trace buffer instead of to
the instance's buffer.
Cc: David Sharp
Cc: Vaibhav Nagarnaik
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c | 3 ++-
1
on a system with many cores. If this fails, the new instance is not
created, precluding the user from setting a smaller buffer for which
allocation might succeed.
Cc: David Sharp
Cc: Vaibhav Nagarnaik
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c
There are multiple places where the ftrace_trace_arrays list is accessed in
trace_events.c without the trace_types_lock held.
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c| 2 +-
kernel/trace/trace.h| 2 ++
kernel/trace
Releasing the free_buffer file in an instance causes the global buffer
to be stopped when TRACE_ITER_STOP_ON_FREE is enabled. Operate on the
correct buffer.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c | 2 +-
1 file
Allow tracer instances to disable tracing by cpu by moving
the static global tracing_cpumask into trace_array.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c | 37 -
kernel/trace/trace.h
harp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 9bfb889..678a88b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace
Allow tracer instances to disable tracing by cpu by moving
the static global tracing_cpumask into trace_array.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c | 37 -
kernel/trace/trace.h
Sorry, it slipped my mind to actually test tracing_cpumask_read().
Changed
struct trace_array *tr = file_inode(filp);
to
struct trace_array *tr = file_inode(filp)->i_private;
Alexander Z Lam (1):
tracing: Make tracing_cpumask available for all instances
kernel/trace/trac
Some error paths did not handle ref counting properly, and some trace files need
ref counting.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c| 32 ++--
kernel/trace/trace_events.c | 21
Some error paths did not handle ref counting properly, and some trace files need
ref counting.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c| 24 ++--
kernel/trace/trace_events.c | 21
From: Lin Chen
We hit a panic while doing cpu hotplug test.
<0>[ 627.982857] Kernel panic - not syncing: smp_callin: CPU1 started up but
did not get a callout!
<0>[ 627.982864]
<4>[ 627.982876] Pid: 0, comm: kworker/0:1 Tainted: G ...
<4>[ 627.982883] Call Trace:
<4>[ 627.982903] [] panic
From: Lin Chen
We hit a panic while doing cpu hotplug test.
<0>[ 627.982857] Kernel panic - not syncing: smp_callin: CPU1 started up but
did not get a callout!
<0>[ 627.982864]
<4>[ 627.982876] Pid: 0, comm: kworker/0:1 Tainted: G ...
<4>[ 627.982883] Call Trace:
<4>[ 627.982903] [] panic
lo lo,
I'm trying to compile 2.6.32.60 with gcc 4.7.2, and getting the
following error:
CC arch/x86/kernel/ptrace.o
arch/x86/kernel/ptrace.c:1472:17: error: conflicting types for
'syscall_trace_enter'
In file included from
/usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/vm86.h:130
* Pete Zaitcev <[EMAIL PROTECTED]>:
| > > pwc Too many ISOC errors, bailing out.
| > > pwc pwc_isoc_handler() called with status -84 [CRC/Timeout (could be
anything)].
|
| There is no other way but to start splitting patches and diff-ing.
| We can narrow this down a little by looking at what _mi
Dear linux-kernel developers,
oops with 2.4.28
Feb 10 10:33:28 gateway Unable to handle kernel NULL pointer dereference at
virtual address 0010
Feb 10 10:33:29 gateway <1>Unable to handle kernel paging request at virtual
address 35f90157
Feb 10 10:33:41 gateway <1>Unable to handle kernel pa
tion anyway).
>
Hello Doug,
Does this package also tell the kernel to "re-establish" a
reservation for all devices after a bus reset, or at least inform a
user level program? Finding out when there has been a bus reset has
been a stumbling block for me.
-Eric.
--
Eric Z. A
er can access the disk at the same
time. The data on the disk should be in a state where the second
system in the cluster could start a recovery task and begin to provide
the service hosted on the disk.
-Eric.
--
Eric Z. Ayers Lead Software Engineer
Phone: +
a disk is
"stolen" from under a running service and there is a "network
partition" in the cluster.
A network partition occurs when multiple machines in the cluster are
runnig, but the HA software agents on two nodes can't communicate via
the network to arbitrate
I have a Philips 750 webcam camera, equipped with a
Sony CCD sensor + TDA878.
It was working fine with 2.4.29 and earlier kernels, often with
100-150 days uptime.
As I upgraded to 2.4.30-rc kernels, started getting such error in my
kernel log:
pwc Too many ISOC errors, bailing out.
pwc pwc_isoc_
strsep to ignore blanks?
Thanks,
Z. Cliffe Schreuders
Please cc me.
-
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/
f existing code which already uses strtok_r to a kernel security
module.
Thanks,
Cliffe.
Jan Engelhardt wrote:
On Jul 16 2007 16:52, Z. Cliffe Schreuders wrote:
I am aware strtok was removed from the kernel in 2002. However strtok_r is more
desirable than strsep as I do not want to know ab
Casey Schaufler wrote:
--- "Z. Cliffe Schreuders" <[EMAIL PROTECTED]> wrote:
What I need is to ignore double delimiters such as (::). This can be
done trivially with a string comparison to check for "\0". What I want
to know is if it is ok to include the st
Hi Michael,
If you have time, could you help to review this patch set?
Thanks!
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Wednesday, June 29, 2016 6:32 PM
> To: m...@redhat.com
> Cc: linux-kernel@vger.kernel.org; virtualizat...@lists.linux-foun
> Subject: Re: [PATCH v2 repost 6/7] mm: add the related functions to get free
> page info
>
> On 07/26/2016 06:23 PM, Liang Li wrote:
> > + for_each_migratetype_order(order, t) {
> > + list_for_each(curr, &zone->free_area[order].free_list[t]) {
> > + pfn = page_to_pf
> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate
> process
>
> On 07/26/2016 06:23 PM, Liang Li wrote:
> > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn());
> > + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_PER_LON
> > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap
> > + * to prevent a very large page bitmap, there are two reasons for this:
> > + * 1) to save memory.
> > + * 2) allocate a large bitmap may fail.
> > + *
> > + * The actual limit of pfn is determined by:
> > + * pfn_limit
> Subject: Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate
> process
>
> On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote:
> > On 07/26/2016 06:23 PM, Liang Li wrote:
> > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > > + vb->pfn_limit = min(vb->pfn_limit, get_max
> > +/*
> > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap
> > + * to prevent a very large page bitmap, there are two reasons for this:
> > + * 1) to save memory.
> > + * 2) allocate a large bitmap may fail.
> > + *
> > + * The actual limit of pfn is determined by:
> > + * p
> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote:
> >> On 07/26/2016 06:23 PM, Liang Li wrote:
> >>> + for_each_migratetype_order(order, t) {
> >>> + list_for_each(curr, &zone->free_area[order].free_list[t]) {
> >>> +
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7da61ad..3ad8b10
> > 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void) }
> > EXPORT_SYMBOL(get_max_pfn);
> >
> > +static void mark_free_pages_bitmap(struct zone *zone, unsig
> > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big.
> > > How big was the pfn buffer before?
> >
> > Yes, it is if the max pfn is more than 32GB.
> > The size of the pfn buffer use before is 256*4 = 1024 Bytes, it's too
> > small, and it's the main reason for bad performance.
>
> > }
> >
> > +static void update_free_pages_stats(struct virtio_balloon *vb,
>
> why _stats?
Will change.
> > + max_pfn = get_max_pfn();
> > + mutex_lock(&vb->balloon_lock);
> > + while (pfn < max_pfn) {
> > + memset(vb->page_bitmap, 0, vb->bmap_len);
> > + ret = get_
> On Thu, Jul 28, 2016 at 03:06:37AM +, Li, Liang Z wrote:
> > > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page
> > > > +bitmap
> > > > + * to prevent a very large page bitmap, there are two reasons for this:
> > > > + *
> On Thu, Jul 28, 2016 at 06:36:18AM +, Li, Liang Z wrote:
> > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big.
> > > > > How big was the pfn buffer before?
> > > >
> > > > Yes, it is if the max pfn is more than 3
> > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote:
> > > > On 07/26/2016 06:23 PM, Liang Li wrote:
> > > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> > > > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn());
> > > > > + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_P
Hi Michael,
I know you are very busy. If you have time, could you help to take a look at
this patch set?
Thanks!
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Thursday, August 18, 2016 9:06 AM
> To: Michael S. Tsirkin
> Cc: virtualizat...@lists.linux-founda
> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast
> (de)inflating
> & fast live migration
>
> 2016-08-08 14:35 GMT+08:00 Liang Li :
> > This patch set contains two parts of changes to the virtio-balloon.
> >
> > One is the change for speeding up the inflating & deflating process
1 - 100 of 297 matches
Mail list logo
