77.1 proto esp reqid 1 mode tunnel
ip xfrm policy add src 0.0.0.0/0 dst 192.168.77.35 dir out tmpl src
192.168.77.1 dst 192.168.77.35 proto esp reqid 2 mode tunnel
works well.
May be anybody can help me with this?
Thanks!
--
Олег Неманов (Oleg Nemanov)
ueues each and 32 cpu cores.
Can i scale nic interrupt handling to all this cores with smp_affinity?
Thanks.
--
Олег Неманов (Oleg Nemanov)
On 04/27/2018 01:28 AM, Marcelo Ricardo Leitner wrote:
> On Fri, Apr 27, 2018 at 01:14:56AM +0300, Oleg Babin wrote:
>> Hi Marcelo,
>>
>> On 04/24/2018 12:33 AM, Marcelo Ricardo Leitner wrote:
>>> Hi,
>>>
>>> On Mon, Apr 23, 2018 at 09:41:04PM +03
On 04/24/2018 12:33 AM, Marcelo Ricardo Leitner wrote:
> On Mon, Apr 23, 2018 at 09:41:05PM +0300, Oleg Babin wrote:
>> This patch introduces wrappers for accessing in/out streams indirectly.
>> This will enable to replace physically contiguous memory arrays
>> of streams wit
Hi Marcelo,
On 04/24/2018 12:33 AM, Marcelo Ricardo Leitner wrote:
> Hi,
>
> On Mon, Apr 23, 2018 at 09:41:04PM +0300, Oleg Babin wrote:
>> Each SCTP association can have up to 65535 input and output streams.
>> For each stream type an array of sctp_stream_in or sctp_stream
This patch introduces wrappers for accessing in/out streams indirectly.
This will enable to replace physically contiguous memory arrays
of streams with flexible arrays (or maybe any other appropriate
mechanism) which do memory allocation on a per-page basis.
Signed-off-by: Oleg Babin
This path replaces physically contiguous memory arrays
allocated using kmalloc_array() with flexible arrays.
This enables to avoid memory allocation failures on the
systems under a memory stress.
Signed-off-by: Oleg Babin
---
include/net/sctp/structs.h | 1 +
net/sctp/stream.c | 78
native).
* Second patch replaces kmalloc_array() with flex_array usage.
Oleg Babin (2):
net/sctp: Make wrappers for accessing in/out streams
net/sctp: Replace in/out stream arrays with flex_array
include/net/sctp/structs.h | 31 +---
net/sctp/chunk.c | 6 +-
net/sctp/outq
On 11/17, Yonghong Song wrote:
>
> On 11/17/17 9:25 AM, Oleg Nesterov wrote:
> >On 11/15, Yonghong Song wrote:
> >>
> >>v3 -> v4:
> >> . Revert most of v3 change as 32bit emulation is not really working
> >> on x86_64 platform
is ongoing to address this issue.
Reviewed-by: Oleg Nesterov
Please test your patch with the fix below, in this particular case the
TIF_IA32 check should be fine. Although this is not what we really want,
we should probably use user_64bit_mode(regs) which checks ->cs. But this
needs more c
On 11/15, Oleg Nesterov wrote:
>
> So please, check if uprobe_init_insn() fails or not in this case. After that
> we will know whether your patch needs the additional is_64bit_mm() check in
> push_setup_xol_ops() or not.
OK, I did the check for you.
uprobe_init_insn() doesn't f
On 11/14, Yonghong Song wrote:
>
>
> On 11/14/17 8:03 AM, Oleg Nesterov wrote:
> >Ah, no, sizeof_long() is broken by the same reason, so you can't test it...
>
> Right. I hacked the emulate_push_stack (original name: push_ret_address)
> with sizeof_long = 4, and 32bi
On 11/14, Yonghong Song wrote:
>
> On 11/14/17 7:51 AM, Oleg Nesterov wrote:
> >
> >And test_thread_flag(TIF_ADDR32) is not right too. The caller is not
> >necessarily the probed task. See is_64bit_mm(mm) in
> >arch_uprobe_analyze_insn().
>
> I printed out some
On 11/14, Oleg Nesterov wrote:
>
> > +#ifdef CONFIG_X86_64
> > + if (test_thread_flag(TIF_ADDR32))
> > + return -ENOSYS;
> > +#endif
>
> No, this doesn't look right, see my previous email. You should do this
> check in the "if (insn-&g
_area() looks very
wrong although I need to re-check.
I didn't have time for this problem so far. But emulation should work, so
you can hopefully test your patch.
Oleg.
On 11/13, Yonghong Song wrote:
>
> On 11/13/17 4:59 AM, Oleg Nesterov wrote:
> >>+ switch (opc1) {
> >>+ case 0x50:
> >>+ reg_offset = offsetof(struct pt_regs, r8);
> >>+ break;
> >>+
r15);
> + break;
> + }
> +#else
> + return -ENOSYS;
> +#endif
OK, but shouldn't we also return ENOSYS if CONFIG_X86_64=y but the probed task
is 32bit?
Or in this case uprobe_init_insn(x86_64 => false) should fail and
push_setup_xol_ops()
won't be called?
Oleg.
ret = uprobe_setup_push_ops(...);
if (ret != -ENOSYS)
return ret;
at the start of arch_uprobe_analyze_insn(), right after the similar
branch_setup_xol_ops() call.
Btw... please add v2 into the subject when you send the new version.
Oleg.
ease make a separate method for this code. Let me repeat, the
main reason for branch_xol_ops/etc is that we simply can not execute these
insns out-of-line, we have to emulate them. "push" differs, the only reason
why we may want to emulate it is optimization.
Oleg.
On 11/09, Oleg Nesterov wrote:
>
> And. Do you really need ->post_xol() method to emulate "push"? Why we can't
> simply execute it out-of-line if copy_to_user() fails?
>
> branch_post_xol_op() is needed because we can't execute "call" out-of-line,
&g
duplication would be fine in this case.
And. Do you really need ->post_xol() method to emulate "push"? Why we can't
simply execute it out-of-line if copy_to_user() fails?
branch_post_xol_op() is needed because we can't execute "call" out-of-line,
we need to restart and try again if copy_to_user() fails, but I don not
understand why it is needed to emulate "push".
Oleg.
On 06/30, Paul E. McKenney wrote:
>
> On Fri, Jun 30, 2017 at 05:20:10PM +0200, Oleg Nesterov wrote:
> >
> > I do not think the overhead will be noticeable in this particular case.
> >
> > But I am not sure I understand why do we wa
mance-wise this is almost the same, and if we do not really care about
overhead we can simplify the code: this way it is obvious that we can't race
with task_work_cancel().
Oleg.
and other entries.
>*/
> - raw_spin_unlock_wait(&task->pi_lock);
> + raw_spin_lock(&task->pi_lock);
> + raw_spin_unlock(&task->pi_lock);
Well, bit the you need spin_lock_irq(). And this is one of the reasons
why I personally think unlock_wait have some sense...
Oleg.
ee struct iphdr together with struct ip in
my netinet/ip.h. So, i thought that this answer may be inexact or incorrect.
Thanks!
--
Олег Неманов (Oleg Nemanov)
On Thu, May 04, 2017 at 12:52:48PM -0400, Sowmini Varadhan wrote:
> BSD vs linux?
>
> struct ip is a BSD-ism, intended to be used if you were porting
> some BSD app.
Thanks!
--
Олег Неманов (Oleg Nemanov)
Hi, all.
It seems struct ip and struct iphdr are similar: struct ip, despite of
it name, doesn't contain anything but ip header.
So, my noob question, what is the difference between them?
Thanks.
--
Олег Неманов (Oleg Nemanov)
On 01/23, Eric Dumazet wrote:
>
> On Mon, 2017-01-23 at 11:56 -0500, Jason Baron wrote:
> > On 01/23/2017 09:30 AM, Oleg Nesterov wrote:
> > > Hello,
> > >
> > > smp_mb__after_atomic() looks wrong and misleading, sock_reset_flag() does
> > > the
&g
t which really looks as a
missed wakeup in epoll, but this kernel is old and in particular it lacks
the commit 128dd1759 "epoll: prevent missed events on EPOLL_CTL_MOD" which
looks more promising. But we are not sure it can fully explain the problem
we can't reproduce, so we are looking for anything else which may contribute
to the problem.
Oleg.
;
and the patch looks correct in that we need the barriers in tcp_check_space()
and tcp_poll() in theory, so it seems tcp_check_space() needs smp_mb() ?
Oleg.
On Aug 31, 2016, at 5:31 PM, David Miller wrote:
> From: Oleg Drokin
> Date: Fri, 26 Aug 2016 23:14:06 -0400
>
>> %ul would print an unsigned with a letter l at the end which does
>> not seem to be desired here, on the other hand the value being printed
>> is u32 so
On Aug 27, 2016, at 12:18 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 8/27/2016 6:58 PM, Oleg Drokin wrote:
>
>>>> %ul would print an unsigned value and a letter l,
>>>> likely it was %lu that was meant to print the long int,
>>>> but in reality
On Aug 27, 2016, at 11:13 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 8/27/2016 6:10 AM, Oleg Drokin wrote:
>
>> %ul would print an unsigned value and a letter l,
>> likely it was %lu that was meant to print the long int,
>> but in reality the values printed
%ul would print an unsigned with a letter l at the end which does
not seem to be desired here, on the other hand the value being printed
is u32 so just drop the l instead of converting to %lu
Signed-off-by: Oleg Drokin
---
drivers/net/irda/vlsi_ir.c | 2 +-
1 file changed, 1 insertion(+), 1
%ul would print an unsigned value and a letter l,
likely it was %lu that was meant to print the long int,
but in reality the values printed there are just regular signed
ints, so just dropping the l altogether.
Signed-off-by: Oleg Drokin
---
net/bridge/br_stp_bpdu.c | 2 +-
1 file changed, 1
node value is set according to information provided by BIOS _PXM
table.
This can be related to your question:
https://patchwork.ozlabs.org/patch/400073/
--
wbr, Oleg.
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
--
To unsubscribe from this list:
On 08/04, Marcelo Ricardo Leitner wrote:
>
> On Tue, Aug 04, 2015 at 06:33:34PM +0200, Oleg Nesterov wrote:
> > Commit 1fbe4b46caca "net: pktgen: kill the Wait for kthread_stop
> > code in pktgen_thread_worker()" removed (in particular) the final
> > __set_curren
() after return.
Afaics, we can simply remove both set_current_state()'s, and we
could do this a long ago right after ef87979c273a2 "pktgen: better
scheduler friendliness" which changed pktgen_thread_worker() to
use wait_event_interruptible_timeout().
Reported-by: Huang Ying
Signed-o
ux.kernel.api/12201
--
wbr, Oleg.
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
pktgen_thread_worker() doesn't need to wait for kthread_stop(), it
can simply exit. Just pktgen_create_thread() and pg_net_exit() should
do get_task_struct()/put_task_struct(). kthread_stop(dead_thread) is
fine.
Signed-off-by: Oleg Nesterov
---
net/core/pktgen.c | 11 ++-
1
Hello,
I am not familiar with this code and I have no idea how to test
these changes, so 2/2 comes as a separate change. 1/2 looks like
the obvious bugfix, and probably candidate for -stable.
Oleg.
net/core/pktgen.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
--
To
pktgen_thread_worker() is obviously racy, kthread_stop() can come
between the kthread_should_stop() check and set_current_state().
Signed-off-by: Oleg Nesterov
Reported-by: Jan Stancek
Reported-by: Marcelo Leitner
---
net/core/pktgen.c |4 +++-
1 files changed, 3 insertions(+), 1
On 10/22, Jarek Poplawski wrote:
>
> On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
> > On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
> > > On 10/18, Jarek Poplawski wrote:
> > > >
> > > > +/**
> > > > +
r this work and blocks.
We still need some retry logic to handle the queueing is in progress
of course, but we won't spin waiting for the other works.
What do you think?
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
tr)" chunk?
Andrew, could I get the kernel source after bisection somehow? (I am not
familiar with guilt, will try to study it later)
Mathieu, could you try the patch below?
Oleg.
--- kernel/fork.c~ 2007-10-13 15:41:35.0 +0400
+++ kernel/fork.c 2007-10-13 15:41:41.000
On 10/13, Oleg Nesterov wrote:
>
> On 10/12, Andrew Morton wrote:
> >
> > Bisection shows that this problem is caused by these two patches:
> >
> > pid-namespaces-allow-cloning-of-new-namespace.patch
>
> This? http://marc.info/?l=linux-mm-commits&m=1187
> Hallo.
>
> I have a very strange problem.
[]
> Any advise on how to debug this will be very appreciated. Thanks.
Thanks...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
Hallo.
I have a very strange problem.
Server (with Debian Etch) was running for 80 days perfectly. Then, (after
some lighting, i believe) i noticed, that connection, that isn't active
(i.e. is not transferring something) frizzes (on linux) and then
dies (connections reset).
Logs are empty. Ping
tion */
flush_scheduled_work();
}
Jarek, I don't understand net/, a silly question. Why do we need the #2 chunk?
Isn't it better to move skb_queue_purge(&npinfo->txq) after cancel_..._work()
instead?
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
l_rearming_delayed_work(&npinfo->tx_work);
> flush_scheduled_work();
While you are here, could you also delete this flush_scheduled_work() ?
It is not needed any longer.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ld avoid signals when it
comes to kernel threads.
One can always use force_sig() or allow_signal() + send_sig() when
it is really needed, like cifs does.
> On 6/26/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> >Personally, I don't think we should do this.
>
(tsk)
kthread_stop(tsk);
This "if(tsk)" looks wrong to me. Can srvTcp->tsk be NULL? If yes, send_sig()
is not safe. Can srvTcp->tsk become NULL after send_sig() ? If yes, this
check is racy, and kthread_stop() is not safe.
Oleg.
-
To unsubscribe from this list:
On 04/25, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Yes sure. Note that this is documented:
> >
> > /*
> > * Kill off a pending schedule_delayed_work(). Note that the work
> > callback
> >
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Sure, I'll grep for cancel_delayed_work(). But unless I missed something,
> > this change should be completely transparent for all users. Otherwise, it
> > is buggy.
>
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Great. I'll send the s/del_timer_sync/del_timer/ patch.
>
> I didn't say I necessarily agreed that this was a good idea. I just meant
> that
> I agree that it will w
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > The current code uses del_timer_sync(). It will also return 0. However, it
> > will spin waiting for timer->function() to complete. So we are just wasting
> > CP
On 04/24, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > > > We only care when del_timer() returns true. In that case, if the timer
> > > > function still runs (possible for single-threaded wqs), it has already
> > > > pa
.
When del_timer() returns true and delayed_work_timer_fn() doesn't run we are
safe, this doesn't differ from del_timer_sync().
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
but making changes of this nature against
> 2.6.21 might lead to grief.
I think it is better to use cancel_delayed_work(), but change it to use
del_timer(). I belive cancel_delayed_work() doesn't need del_timer_sync().
We only care when del_timer() returns true. In that case, if the time
On 02/21, Stephen Hemminger wrote:
>
> I would rather put it in a bugfix patchset for 2.6.21 and 2.6.20-stable
OK. Even better. Could you also remove br_private.h:BR_PORT_DEBOUNCE then?
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a m
May I ask you to redo this patch on top of
[PATCH 1/3] net/bridge/br_if.c: don't use _WORK_NAR
http://marc.theaimsgroup.com/?l=linux-kernel&m=117183517612775
?
We are removing the _NAR stuff, it would be nice to do this in a separate
patch.
Thanks!
Oleg.
-
To unsubscr
On 02/21, Jarek Poplawski wrote:
>
> > On Wed, 21 Feb 2007 01:19:41 +0300
> > Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> > > + p = container_of(work, struct net_bridge_port, carrier_check.work);
> > >
> > > rtnl_lock();
> > >
On 02/20, Stephen Hemminger wrote:
>
> On Wed, 21 Feb 2007 01:19:41 +0300
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > static void release_nbp(struct kobject *kobj)
> > {
> > struct net_bridge_port *p
> > = conta
the container.
port_carrier_check() uses p->dev->br_port == NULL as indication that
net_bridge_port
is under destruction. Otherwise it assumes that p->dev->br_port == p.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Acked-By: David Howells <[EMAIL PROTECTED]>
--- WQ/net/br
On 2006-11-16, Ian McDonald wrote:
> I've searched lkml archives but can't find anything there apart from
> one person complaining.
>
> Can anybody basically tell me how to get access to git trees in a way
> that works at present?
>
> I've tried git://git.kernel.org, git://git2.kernel.org,
> http:/
On Wed, Nov 01, 2006 at 09:57:46PM +0300, Evgeniy Polyakov wrote:
> On Wed, Nov 01, 2006 at 06:20:43PM +0000, Oleg Verych ([EMAIL PROTECTED])
> wrote:
[]
> > Where's real-life application to do configure && make && make install?
>
> Your real life or mi
On 2006-11-02, Meelis Roos wrote:
>> There should only be one space before the "void" in the patch,
>> your email client (or something else) put another space there.
>>
>> Also, your email client likes to turn lines containing only
>> spaces into empty lines, which also corrupts the patch.
>
> cg-d
Hallo, Evgeniy Polyakov.
On 2006-11-01, you wrote:
[]
>> Quantifying "how much more scalable" would be nice, as would be some
>> example where it is useful. ("It makes my webserver twice as fast on
>> monster 64-cpu box").
>
> Trivial kevent web-server can handle 3960+ req/sec on Xeon 2.4Ghz with
68 matches
Mail list logo
