will think about it once again, do some more tests
with this locking scheme, and will let you know.
Thanks,
--
Jiri Kosina
-
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
however
pretty convinced now that this is the right fix.
Thanks,
--
Jiri Kosina
-
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
On Wed, 16 May 2007, Jiri Kosina wrote:
since Jiri has a good test case for it, I leave it to him for testing.
If he confirms that this fixes the locking issues, then this is
Signed-off-by: Marcel Holtmann [EMAIL PROTECTED]
I will verify later this evening and will let you know. I am
On Wed, 16 May 2007, David Miller wrote:
I have just verified that this locking scheme is indeed correct. So you
can add
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
if you wish to, and submit the patch to Andrew.
I guess I don't get sent networking patches any more
[PATCH] sk98lin: handle pci_enable_device() return value in skge_resume()
properly
Fix missing handling of pci_enable_device() return value in skge_resume()
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
---
drivers/net/sk98lin/skge.c |6 +-
1 files changed, 5 insertions(+), 1
-by: Jiri Kosina [EMAIL PROTECTED]
---
drivers/net/sk98lin/skge.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c
index d4913c3..1f03cf8 100644
--- a/drivers/net/sk98lin/skge.c
+++ b/drivers/net/sk98lin/skge.c
prefer:
ret = pci_enable_device(pdev);
As you wish.
[PATCH] fix sk98lin driver, ignoring return value from pci_enable_device()
add check of return value to _resume() function of sk98lin driver.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
---
drivers/net/sk98lin/skge.c |8 +++-
1
driver, ignoring return value from pci_enable_device()
add check of return value to _resume() function of sk98lin driver.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
---
drivers/net/sk98lin/skge.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers
*
laptop with 8168, not only Asus. I guess the disk-usage-crash was some
other bug.
Confusing ... the other day you stated that r1000 has the exactly same
problem?
Thanks,
--
Jiri Kosina
SUSE Labs
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
whether this will be processed properly in time when
going to suspend.
Thanks,
--
Jiri Kosina
-
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
currently supported by USB HID
force-feedback code, which have a bluetooth version, please?
I'd propose the patch below, until I make the usbhid force-feedback code
transport independent. Thanks.
From: Jiri Kosina [EMAIL PROTECTED]
[Bluetooth] HIDP - don't initialize force feedback
The current
(extra control URB is required to make it operational), probably something
similar will be needed for BT version too.
From: Jiri Kosina [EMAIL PROTECTED]
[Bluetooth] HIDP - don't initialize force feedback
The current implementation of force feedback for HID devices is
USB-transport only
in regressions list, as at
least Chris Stromsoe has reported bonding-related problems with skge that
don't happen with sklin -
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0707.1/1158.html
--
Jiri Kosina
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
came for :( )
I've also tried with the latest code from git, the behaviour is the same
as 2.6.23-rc2.
This needs to go to netdev, CC added.
Also, git-bisect will help a lot here to find the commit which caused the
regression you are seeing.
--
Jiri Kosina
-
To unsubscribe from this list: send
in an usual
way.
--
Jiri Kosina
-
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
From: Jiri Kosina [EMAIL PROTECTED]
[PATCH] IPV6: fix source address selection
The commit 95c385 broke proper source address selection for cases in which
there is a address which is makred 'deprecated'. The commit mistakenly
changed ifa-flags to ifa_result-flags (probably copy/paste error from
in a different machine, etc.
Otherwise I am afraid this is going to be just a totally wild guessing.
Thanks,
--
Jiri Kosina
===
Code: cb 04 76 c7 83 c1 01 83 ee 01 39 d1 75 8d eb d7 83 7c cb 04 0f 77 b4 83
c1 01 83 ee 01 39 d1 0f 85 76 ff ff ff eb c0 8d 74 26 00 8b 4a 04 8d 0c cd
10 00 00 00 29 48 5c 8d 42 08 ba 10 40 38 c0
EIP: [c0383fa0] sk_filter_delayed_uncharge+0x0/0x20 SS:ESP 0068:c5dcbef8
--
Jiri
No response from developers
Hi,
it is assigned to '[EMAIL PROTECTED]', so I didn't
notice, it's as simple as that.
--
Jiri Kosina
-
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
This reverts commit 45b503548210fe6f23e92b856421c2a3f05fd034.
It contains deadlock, and breaks userspace applications (wpa_supplicant,
networkmanager). References:
http://bugzilla.kernel.org/show_bug.cgi?id=10002
http://bugzilla.kernel.org/show_bug.cgi?id=10002
---
net/core/rtnetlink.c | 36
tippex [c0105757] do_IRQ+0x47/0x80
Feb 21 20:46:33 tippex [c01039c3] common_interrupt+0x23/0x28
Feb 21 20:46:33 tippex ===
This needs to be CCed to netdev.
Any chance that
git revert 69cc64d8d92
makes this report go away?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe
On Fri, 22 Feb 2008, Anders Eriksson wrote:
This needs to be CCed to netdev.
Any chance that
git revert 69cc64d8d92
makes this report go away?
I'll have to install a git repo to check, or maybe you can send me the diff
to
reverse vs. 2.6.25-rc2?
diff --git
you have
any idea? (the thread started at http://lkml.org/lkml/2008/2/22/105).
--
Jiri Kosina
SUSE Labs
--
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
e both (i.e accept this
patchset) or have neither of them (i.e. drop list_is_last()).
Otherwise people are likely to be confused by such an asymetric API and
will keep posting patches for it over and over again.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "
On Thu, 14 Apr 2016, Jiri Kosina wrote:
> In a nutshell, is this expected behavior or bug?
Just to clarify what seems to suggest to me that this is rather a bug that
needs to be fixed (but apparently one that has been there for quite a long
time) can be demonstra
(195.47.235.3) 56(84) bytes of data.
[ ... nothing happens ... ]
^C
jikos:~ # tc qdisc add dev eth0 parent 10:1 sfq
jikos:~ # ping -c 1 nix.cz | head -2
PING nix.cz (195.47.235.3) 56(84) bytes of data.
64 bytes from info.nix.cz (195.47.235.3): icmp_seq=1 ttl=89 time=1.66 ms
=
Thanks,
--
Jiri
root refcnt 2 rate 800Mbit burst 131000b lat
1.0ms
It's hard to spot a difference (hint: there is none).
Thanks,
--
Jiri Kosina
SUSE Labs
QFQ) assign the default
> one upon deletion instead of noop_qdisc, hence I would describe
> the situation using the words 'inconsistent' and 'accident' rather than
> 'expected'. :)
Would a patch that'd unify this in a sense that all qdiscs would assign
the default one upon deletion acceptable?
Thanks,
--
Jiri Kosina
SUSE Labs
;
> url:
> https://github.com/0day-ci/linux/commits/Jiri-Kosina/net-sched-convert-qdisc-linked-list-to-hashtable/20160711-220527
> config: arm-tct_hammer_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
> reproduce:
> wget
>
From: Jiri Kosina <jkos...@suse.cz>
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linke
rove the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Jiri-Kosina/net-sched-convert-qdisc-linked-list-to-hashtable/20160728-182303
> config: i386-randconfig-s0-201630 (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
>
From: Jiri Kosina <jkos...@suse.cz>
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linke
From: Jiri Kosina <jkos...@suse.cz>
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linke
mistake afterwards. This is fixed in v5 of
the patch.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina <jkos...@suse.cz>
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linke
-by:, as code-wise this series is identical
to the original v6 of the patch.
[1] lkml.kernel.org/r/alpine.lnx.2.00.1608011220580.22...@cbobk.fhfr.pm
--
Jiri Kosina
SUSE Labs
qdisc_match_from_root(struct Qdisc
*root, u32 handle)
{
struct Qdisc *q;
+ if (!qdisc_dev(root))
+ return (root->handle == handle ? root : NULL);
+
if (!(root->flags & TCQ_F_BUILTIN) &&
root->handle == handle)
return root;
Thanks!
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina <jkos...@suse.cz>
There are a couple of leftover symbol conflicts caused by hashtable.h
being included by netdevice.h; those were not caught as build failure
(they're "only" a warning, but in fact real bugs). Fix those up.
Fixes: e87a8f24c ("net: res
: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Hmm, no immediate idea where those are coming from, we'll have to figure
it out. The mq device used here has 4 queues, right?
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina <jkos...@suse.cz>
This is a preparatory patch for converting qdisc linked list into a
hashtable. As we'll need to include hashtable.h in netdevice.h, we first
have to make sure that this will not introduce symbol conflicts for any of
the netdevice.h users.
Reviewed-by
be surrounded by CONFIG_NET_SCHED?
> To save several bytes for !CONFIG_NET_SCHED case.
Makes sense. I'll wait a bit for more feedback (if there is any) before
including this in potential v4.
Thanks,
--
Jiri Kosina
SUSE Labs
Whenever an interface is created, the pfifo_fast qdisc is
automatically used as a queue. If another qdisc is
attached, it preempts the default pfifo_fast, which automatically
returns to function when an existing qdisc is detached.
In this sense this qdisc is magic,
to bring the patch below up for consideration.
Thanks.
From: Jiri Kosina <jkos...@suse.cz>
Subject: [PATCH] sch_tbf: avoid silent fallback to noop_qdisc
TBF started its life as a classless qdisc with a single builtin FIFO queue
which was being shaped.
When it got later turned into classf
isting script if we change that.
While I do understand that reasoning, I'd argue that unpredictable and
unexpected behavior of TBF causing systems with non-working networking is
much more likely than any userspace having hard dependency on the fact
that default (*) qdisc for TBF is noop.
(*) whe
ict on HASH_SIZE
definition in ip6_tunnel.c, ip6_gre.c and sit.c due to hashtable.h include
in netdevice.h that needs to be resolved as well) that'd make RCU usage
consistent.
Any other objections/comments? I was namely curious about any opinions
regarding the hashtable size.
Thanks,
--
Jiri Kosina
SUSE Labs
of qdiscs.
So how about something like the patch below? I already have preliminary
patches on top which unhide the default qdiscs, but let's make this one
step after the other.
Thanks.
From: Jiri Kosina <jkos...@suse.cz>
Subject: [PATCH] net: sched: convert qdisc linked list to hasht
From: Jiri Kosina <jkos...@suse.cz>
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linke
From: Jiri Kosina <jkos...@suse.cz>
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linke
ssigning to struct net_device's Qdisc pointer is
enough to "initialize" the linked list and have it contain one (root)
item. With hashtable, this is not the case, it needs to be explicitly
added.
Hmm, dev_init_scheduler() (and perhaps also dev_shutdown()) would possibly
need similar treatment in order to have accurate data there 100% of the
time even during initialization.
--
Jiri Kosina
SUSE Labs
the primary goal here is not to actually ultimately
improve speed of qdisc lookup per se, but rather to make it possible to
unhide the qdiscs which are currently omitted as the linked list takes too
long to walk. The static hashtable is going help here.
Thanks,
--
Jiri Kosina
SUSE Labs
. the
code in question doesn't indirectly pull in netdevice.h)?
I just did allmodconfig build with v6, and it passed. Fengguang's 0-day
bot didn't report any failures either.
> Then we can add the qdisc hash facility.
Thanks,
--
Jiri Kosina
SUSE Labs
isc hash
conversion, given the fact that the whole tree is building properly?
> Thank you.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 16 Aug 2016, Jiri Kosina wrote:
> > I am hitting a kernel panic with '/etc/init.d/openvswitch-switch
> > restart' Stack trace below. Reverting 59cc1f61f09c ("net: sched: convert
> > qdisc linked list to hashtable") clears the problem.
>
> Thanks a lo
it
fixes any issues you are seeing? Applying the attached patches on top of
net-next or testing with the git branch above should be equivalent test
wrt. qdiscs.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina <jkos...@suse.cz>
qdisc_match_from_root() is now iterating over per-netdevice qdisc
hashtable instead of going through a linked-list of qdiscs (independently
on the actual underlying netdev), which used to be the case before the
switch to hashtable for qdiscs.
For sin
ope of this patchset (but already on my todo).
Thanks a lot to Daniel Borkmann and David Ahern for reporting the issues
and testing the patches promptly.
Jiri Kosina (2):
net: sched: fix handling of singleton qdiscs with qdisc_hash
net: sched: avoid duplicates in qdisc dump
net/
From: Jiri Kosina <jkos...@suse.cz>
tc_dump_qdisc() performs dumping of the per-device qdiscs in two phases;
first, the "standard" dev->qdisc is being dumped. Second, if there is/are
ingress queue(s), they are being dumped as well.
After conversion of netdevice'
On Tue, 16 Aug 2016, Jiri Kosina wrote:
> From: Jiri Kosina <jkos...@suse.cz>
>
> qdisc_match_from_root() is now iterating over per-netdevice qdisc
> hashtable instead of going through a linked-list of qdiscs (independently
> on the actual underlying netdev), which used
From: Jiri Kosina <jkos...@suse.cz>
qdisc_match_from_root() is now iterating over per-netdevice qdisc
hashtable instead of going through a linked-list of qdiscs (independently
on the actual underlying netdev), which was the case before the switch to
hashtable for qdiscs.
For singleton
From: Jiri Kosina <jkos...@suse.cz>
Rebuilding libnetlink doesn't trigger rebuild of tc, which is wrong
(especially so for builds where libnetlink.a gets statically linked into
tc). Fix that by introducing an explicit dependency.
Signed-off-by: Jiri Kosina <jkos...@suse.cz>
---
From: Jiri Kosina <jkos...@suse.cz>
The original reason [1] for having hidden qdiscs (potential scalability
issues in qdisc_match_from_root() with single linked list in case of large
amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
qdisc linked list t
From: Jiri Kosina <jkos...@suse.cz>
Support the new TCA_DUMP_INVISIBLE netlink attribute that allows asking
kernel to perform 'full qdisc dump', as for historical reasons some of the
default qdiscs are being hidden by the kernel.
The command syntax is being extended by voluntary 'inv
. First patch adds the new
TCA_DUMP_INVISIBLE netlink attribute and its handling in the kernel, the
second one adds the iproute2 counterpart.
--
Jiri Kosina
SUSE Labs
On Sat, 25 Feb 2017, Jiri Kosina wrote:
> This is a followup to a patchset submitted back in October 2016
No idea what happened that my usual patchset sending process broke and
there is no 'References/In-reply-to' in the actual patches :/ I will
investigate that. Please let me know in c
ngletons. I've been
completely off the grid for the past three days, but I plan to submit this
as a proper followup fix tomorrow if noone has any objections.
> I will try to work on a patch tomorrow.
What still needs to be looked into are the duplicate clsact entries for
multiqueue.
Thanks,
--
Jiri Kosina
SUSE Labs
ess qdisc to the hashtable whenever it
materializes should be enough to get rid of the "we have to walk two
linked lists" heritage and the ingress special-casing for dumps.
Will look into it next week unless someone is faster.
Thanks,
--
Jiri Kosina
SUSE Labs
o be
inconsistent in this way.
Random shot into darkness -- how about making this a
CONFIG/sysctl-selectable?
Thanks,
--
Jiri Kosina
SUSE Labs
nging more clarity and determinism into the dump by
making default pfifo qdiscs visible.
[1]
http://lkml.kernel.org/r/1460732328.10638.74.ca...@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Jiri Kosina <jkos...@suse.cz>
---
Tested for cbq, htb and tbf.
net/sched/sch_cbq.c| 4
it is the default qdisc
> at this point.
>
> Fixes: 59cc1f61f09c ("net: sched: convert qdisc linked list to hashtable")
> Reported-by: Dmitry Vyukov <dvyu...@google.com>
> Cc: Jiri Kosina <jkos...@suse.cz>
> Signed-off-by: Cong Wang <xiyou.wangc..
From: Jiri Kosina <jkos...@suse.cz>
The original reason [1] for having hidden qdiscs (potential scalability
issues in qdisc_match_from_root() with single linked list in case of large
amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
qdisc linked list t
ase to catch cases where
singleton qdisc would make it there from other places by mistake. By
putting this test there we'll effectively giving up on this warning should
it ever point to a bug.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina <jkos...@suse.cz>
The original reason [1] for having hidden qdiscs (potential scalability
issues in qdisc_match_from_root() with single linked list in case of large
amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
qdisc linked list t
From: Jiri Kosina <jkos...@suse.cz>
Support the new TCA_DUMP_INVISIBLE netlink attribute that allows asking
kernel to perform 'full qdisc dump', as for historical reasons some of the
default qdiscs are being hidden by the kernel.
The command syntax is being extended by voluntary 'inv
from the very beginning;
I am unlikely to find time for this during coming weeks though. But OTOH
this whole thing is very low priority anyway
What do you think?
Thanks,
--
Jiri Kosina
SUSE Labs
ly any more.
Fully agreed.
I'd be inclined to just live with the fact that noop qdisc would never
ever be visible in the dump. I think that in this particular case this can
be easily justified, as the behavior is consistent with what is seen in
the dump ("nothing happens to the packets"). All other cases will be
covered.
If there are no objections to this, I'll send out v2 shortly.
Thanks,
--
Jiri Kosina
SUSE Labs
mmand syntax is being extended by voluntary 'invisible' argument to
> > 'tc qdisc show'.
> >
> > Signed-off-by: Jiri Kosina <jkos...@suse.cz>
> > ---
> > tc/tc_qdisc.c | 25 +++--
> > 1 file changed, 23 insertions(+), 2 deletions(-)
&g
ssue moving qdisc_hash_add() right
> after the child qdisc creation. It additionally removes unneeded checks
> for noop_qdisc.
>
> Reported-by: Hangbin Liu <liuhang...@gmail.com>
> Fixes: 49b499718fa1 ("net: sched: make default fifo qdiscs appear in the
> dump")
Acked-by: Jiri Kosina <jkos...@suse.cz>
Thanks for fixing this Paolo.
--
Jiri Kosina
SUSE Labs
, and something comparable for eBPF JIT?
Is this going to be handled in eBPF in some other way?
Without that in place, and considering Jann Horn's paper, it would seem
like PTI doesn't really lock it down fully, right?
[1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=287305
--
Jiri Kosina
SUSE Labs
On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote:
> > > On Fri, 5 Jan 2018, Dan Williams wrote:
> > >
> > > [ ... snip ...
79 matches
Mail list logo
