* GOODDAY:
From: Azizi Raman @ 2011-02-04 3:35 UTC (permalink / raw)
To: obc
My name is Aziz R Stars a senior advocate with A. Stars & Associates.
I found your contact/profile some where over the Internet and it gave me the greatest joy that you are the one I have been looking for. Whom I strongly believe could
execute this business with me $18 Million . Kindly get back to me for more Detail.
Best regards,
Mr Aziz R Sstars (Esq.)
VXFFTKMBKNYHIESMRCHISVMEHBKJCCXXTIYSJJ
^ permalink raw reply
* Re: [PATCH] net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT
From: Eric W. Biederman @ 2011-02-04 2:07 UTC (permalink / raw)
To: David Miller; +Cc: arnd, netdev, eric.dumazet, kaber
In-Reply-To: <20110203.171918.28815936.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sun, 30 Jan 2011 19:59:53 +0100
>
>> * ip multicast actually needs support for SIOCGETVIFCNT in
>> addition to SIOCGETSGCNT to be complete.
>> * ipv6 multicast needs the same patch as ipv4 multicast for
>> SIOCGETMIFCNT_IN6/SIOCGETSGCNT_IN6.
>>
>> It would probably be a good idea if someone could complete the
>> work on ipv4/v6 multicast compat_ioctl, on top of your patch.
>
> Actually, on top of this, Eric's patch is buggy.
Ouch. Thanks for catching that.
> He defines the "struct compat_sioc_sg_req" but doesn't actually
> use it.
>
> I'll fix that, then take care of the missing cases. Thanks Arnd.
Eric
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: H.K. Jerry Chu @ 2011-02-04 2:01 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, Netdev, therbert, hkchu
In-Reply-To: <alpine.DEB.2.00.1102040027060.25125@melkinpaasi.cs.helsinki.fi>
Hi Ilpo,
On Thu, Feb 3, 2011 at 2:43 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> It would perhaps be useful to change receiver advertized window to include
> some extra segs initially. It should be >= IW + peer's dupThresh-1 as
> otherwise limited transmit won't work for the initial window because we
> won't open more receiver window with dupacks (IIRC, I suppose Jerry might
> be able to correct me right away if I'm wrong and we open window with
> dupacks too?).
Sorry I don't know how the receive window is updated in Linux,
autotuning or not.
But I just wonder why would it have to do with dupacks, i.e., why would it not
slide forward as long as the left edge of the window slides forward,
regardless of
OOO pkt arrival?
I am of the opinion that rwnd is for flow control purpose only thus should be
fully decoupled from the cwnd of the other (sender) side. Therefore
initrwnd should
normally be based on projected BDP and local memory pressure, e.g., 64KB, not
bearing any relation with IW of the other side. Only under special
circumstances should it be used to constrain the sender, e.g., for
devices behind slow links with
very small buffer.
Jerry
>I think initial receiver window code used to have some
> surplus but it was broken by the rfc3390-func conversion (against my
> advice on how to do the conversion).
>
> --
> i.
>
^ permalink raw reply
* Re: [PATCH] net: Provide compat support for SIOCGETMIFCNT_IN6 and SIOCGETSGCNT_IN6.
From: David Miller @ 2011-02-04 2:00 UTC (permalink / raw)
To: netdev; +Cc: arnd, ebiederm
In-Reply-To: <20110203.175448.245404709.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 03 Feb 2011 17:54:48 -0800 (PST)
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> include/linux/mroute6.h | 1 +
> net/ipv6/ip6mr.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++
> net/ipv6/raw.c | 18 +++++++++++
> 3 files changed, 93 insertions(+), 0 deletions(-)
Build testing on x86_64 showed that net/ipv6/raw.c needs a linux/compat.h
include. I've made that change in my local repo.
^ permalink raw reply
* [PATCH] net: Provide compat support for SIOCGETMIFCNT_IN6 and SIOCGETSGCNT_IN6.
From: David Miller @ 2011-02-04 1:54 UTC (permalink / raw)
To: netdev; +Cc: arnd, ebiederm
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/mroute6.h | 1 +
net/ipv6/ip6mr.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++
net/ipv6/raw.c | 18 +++++++++++
3 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/include/linux/mroute6.h b/include/linux/mroute6.h
index 6091ab7..9d2deb2 100644
--- a/include/linux/mroute6.h
+++ b/include/linux/mroute6.h
@@ -136,6 +136,7 @@ extern int ip6_mroute_setsockopt(struct sock *, int, char __user *, unsigned int
extern int ip6_mroute_getsockopt(struct sock *, int, char __user *, int __user *);
extern int ip6_mr_input(struct sk_buff *skb);
extern int ip6mr_ioctl(struct sock *sk, int cmd, void __user *arg);
+extern int ip6mr_compat_ioctl(struct sock *sk, unsigned int cmd, void __user *arg);
extern int ip6_mr_init(void);
extern void ip6_mr_cleanup(void);
#else
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 9fab274..5c07092 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1804,6 +1804,80 @@ int ip6mr_ioctl(struct sock *sk, int cmd, void __user *arg)
}
}
+#ifdef CONFIG_COMPAT
+struct compat_sioc_sg_req6 {
+ struct sockaddr_in6 src;
+ struct sockaddr_in6 grp;
+ compat_ulong_t pktcnt;
+ compat_ulong_t bytecnt;
+ compat_ulong_t wrong_if;
+};
+
+struct compat_sioc_mif_req6 {
+ mifi_t mifi;
+ compat_ulong_t icount;
+ compat_ulong_t ocount;
+ compat_ulong_t ibytes;
+ compat_ulong_t obytes;
+};
+
+int ip6mr_compat_ioctl(struct sock *sk, unsigned int cmd, void __user *arg)
+{
+ struct compat_sioc_sg_req6 sr;
+ struct compat_sioc_mif_req6 vr;
+ struct mif_device *vif;
+ struct mfc6_cache *c;
+ struct net *net = sock_net(sk);
+ struct mr6_table *mrt;
+
+ mrt = ip6mr_get_table(net, raw6_sk(sk)->ip6mr_table ? : RT6_TABLE_DFLT);
+ if (mrt == NULL)
+ return -ENOENT;
+
+ switch (cmd) {
+ case SIOCGETMIFCNT_IN6:
+ if (copy_from_user(&vr, arg, sizeof(vr)))
+ return -EFAULT;
+ if (vr.mifi >= mrt->maxvif)
+ return -EINVAL;
+ read_lock(&mrt_lock);
+ vif = &mrt->vif6_table[vr.mifi];
+ if (MIF_EXISTS(mrt, vr.mifi)) {
+ vr.icount = vif->pkt_in;
+ vr.ocount = vif->pkt_out;
+ vr.ibytes = vif->bytes_in;
+ vr.obytes = vif->bytes_out;
+ read_unlock(&mrt_lock);
+
+ if (copy_to_user(arg, &vr, sizeof(vr)))
+ return -EFAULT;
+ return 0;
+ }
+ read_unlock(&mrt_lock);
+ return -EADDRNOTAVAIL;
+ case SIOCGETSGCNT_IN6:
+ if (copy_from_user(&sr, arg, sizeof(sr)))
+ return -EFAULT;
+
+ read_lock(&mrt_lock);
+ c = ip6mr_cache_find(mrt, &sr.src.sin6_addr, &sr.grp.sin6_addr);
+ if (c) {
+ sr.pktcnt = c->mfc_un.res.pkt;
+ sr.bytecnt = c->mfc_un.res.bytes;
+ sr.wrong_if = c->mfc_un.res.wrong_if;
+ read_unlock(&mrt_lock);
+
+ if (copy_to_user(arg, &sr, sizeof(sr)))
+ return -EFAULT;
+ return 0;
+ }
+ read_unlock(&mrt_lock);
+ return -EADDRNOTAVAIL;
+ default:
+ return -ENOIOCTLCMD;
+ }
+}
+#endif
static inline int ip6mr_forward2_finish(struct sk_buff *skb)
{
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 86c3952..e728804 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -1157,6 +1157,23 @@ static int rawv6_ioctl(struct sock *sk, int cmd, unsigned long arg)
}
}
+#ifdef CONFIG_COMPAT
+static int compat_rawv6_ioctl(struct sock *sk, unsigned int cmd, unsigned long arg)
+{
+ switch (cmd) {
+ case SIOCOUTQ:
+ case SIOCINQ:
+ return -ENOIOCTLCMD;
+ default:
+#ifdef CONFIG_IPV6_MROUTE
+ return ipmr6_compat_ioctl(sk, cmd, compat_ptr(arg));
+#else
+ return -ENOIOCTLCMD;
+#endif
+ }
+}
+#endif
+
static void rawv6_close(struct sock *sk, long timeout)
{
if (inet_sk(sk)->inet_num == IPPROTO_RAW)
@@ -1215,6 +1232,7 @@ struct proto rawv6_prot = {
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_rawv6_setsockopt,
.compat_getsockopt = compat_rawv6_getsockopt,
+ .compat_ioctl = compat_rawv6_ioctl,
#endif
};
--
1.7.4
^ permalink raw reply related
* [PATCH] net: Support compat SIOCGETVIFCNT ioctl in ipv4.
From: David Miller @ 2011-02-04 1:54 UTC (permalink / raw)
To: netdev; +Cc: arnd, ebiederm
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/ipmr.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index fce10a0..8b65a12 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1444,9 +1444,19 @@ struct compat_sioc_sg_req {
compat_ulong_t wrong_if;
};
+struct compat_sioc_vif_req {
+ vifi_t vifi; /* Which iface */
+ compat_ulong_t icount;
+ compat_ulong_t ocount;
+ compat_ulong_t ibytes;
+ compat_ulong_t obytes;
+};
+
int ipmr_compat_ioctl(struct sock *sk, unsigned int cmd, void __user *arg)
{
struct compat_sioc_sg_req sr;
+ struct compat_sioc_vif_req vr;
+ struct vif_device *vif;
struct mfc_cache *c;
struct net *net = sock_net(sk);
struct mr_table *mrt;
@@ -1456,6 +1466,26 @@ int ipmr_compat_ioctl(struct sock *sk, unsigned int cmd, void __user *arg)
return -ENOENT;
switch (cmd) {
+ case SIOCGETVIFCNT:
+ if (copy_from_user(&vr, arg, sizeof(vr)))
+ return -EFAULT;
+ if (vr.vifi >= mrt->maxvif)
+ return -EINVAL;
+ read_lock(&mrt_lock);
+ vif = &mrt->vif_table[vr.vifi];
+ if (VIF_EXISTS(mrt, vr.vifi)) {
+ vr.icount = vif->pkt_in;
+ vr.ocount = vif->pkt_out;
+ vr.ibytes = vif->bytes_in;
+ vr.obytes = vif->bytes_out;
+ read_unlock(&mrt_lock);
+
+ if (copy_to_user(arg, &vr, sizeof(vr)))
+ return -EFAULT;
+ return 0;
+ }
+ read_unlock(&mrt_lock);
+ return -EADDRNOTAVAIL;
case SIOCGETSGCNT:
if (copy_from_user(&sr, arg, sizeof(sr)))
return -EFAULT;
--
1.7.4
^ permalink raw reply related
* [PATCH] net: Fix bug in compat SIOCGETSGCNT handling.
From: David Miller @ 2011-02-04 1:54 UTC (permalink / raw)
To: netdev; +Cc: arnd, ebiederm
Commit 709b46e8d90badda1898caea50483c12af178e96 ("net: Add compat
ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT") added the
correct plumbing to handle SIOCGETSGCNT properly.
However, whilst definiting a proper "struct compat_sioc_sg_req" it
isn't actually used in ipmr_compat_ioctl().
Correct this oversight.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/ipmr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 7e41ac0..fce10a0 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1446,7 +1446,7 @@ struct compat_sioc_sg_req {
int ipmr_compat_ioctl(struct sock *sk, unsigned int cmd, void __user *arg)
{
- struct sioc_sg_req sr;
+ struct compat_sioc_sg_req sr;
struct mfc_cache *c;
struct net *net = sock_net(sk);
struct mr_table *mrt;
--
1.7.4
^ permalink raw reply related
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Dave Airlie @ 2011-02-04 1:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Keith Packard, Carlos Mafra, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTin-9a5Z3qq4t8UakRvgB1G3_CT2RLKMVaHXvnLr@mail.gmail.com>
On Fri, Feb 4, 2011 at 11:11 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard <keithp@keithp.com> wrote:
>>
>> The goal is to make it so that when you *do* set a mode, DPMS gets set
>> to ON (as the monitor will actually be "on" at that point). Here's a
>> patch which does the DPMS_ON precisely when setting a mode.
>
> Ok, patch looks sane, but it does leave me with the "what about the
> 'fb_changed' case?" question. Is that case basically guaranteed to not
> change any existing dpms state?
Yes its inconsistent behaviour but nothing in the fb_changed case will
affect the DPMS
state. I expect we should probably do that so all paths via that
function turn DPMS on,
and it'll be consistent, might be something for 39.
Dave.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Keith Packard @ 2011-02-04 1:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Carlos Mafra, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTin-9a5Z3qq4t8UakRvgB1G3_CT2RLKMVaHXvnLr@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
On Thu, 3 Feb 2011 17:11:14 -0800, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Ok, patch looks sane, but it does leave me with the "what about the
> 'fb_changed' case?" question. Is that case basically guaranteed to not
> change any existing dpms state?
None of the existing drivers turn anything on or off in the
mode_set_base code; the fix I intended was purely for the mode_set case,
which always turns on all of the connected outputs. I just screwed up
and stuck it in the wrong place.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT
From: David Miller @ 2011-02-04 1:19 UTC (permalink / raw)
To: arnd; +Cc: ebiederm, netdev, eric.dumazet, kaber
In-Reply-To: <201101301959.53661.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Sun, 30 Jan 2011 19:59:53 +0100
> * ip multicast actually needs support for SIOCGETVIFCNT in
> addition to SIOCGETSGCNT to be complete.
> * ipv6 multicast needs the same patch as ipv4 multicast for
> SIOCGETMIFCNT_IN6/SIOCGETSGCNT_IN6.
>
> It would probably be a good idea if someone could complete the
> work on ipv4/v6 multicast compat_ioctl, on top of your patch.
Actually, on top of this, Eric's patch is buggy.
He defines the "struct compat_sioc_sg_req" but doesn't actually
use it.
I'll fix that, then take care of the missing cases. Thanks Arnd.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-04 1:11 UTC (permalink / raw)
To: Keith Packard
Cc: Dave Airlie, Carlos Mafra, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <yund3n88v7x.fsf@aiko.keithp.com>
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard <keithp@keithp.com> wrote:
>
> The goal is to make it so that when you *do* set a mode, DPMS gets set
> to ON (as the monitor will actually be "on" at that point). Here's a
> patch which does the DPMS_ON precisely when setting a mode.
Ok, patch looks sane, but it does leave me with the "what about the
'fb_changed' case?" question. Is that case basically guaranteed to not
change any existing dpms state?
> (note, this patch compiles, but is otherwise only lightly tested).
Carlos? Takashi? Ignore my crazy patch, try this one instead. Does it
fix things for you?
Linus
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Keith Packard @ 2011-02-04 1:05 UTC (permalink / raw)
To: Linus Torvalds, Dave Airlie
Cc: Linux SCSI List, Linux ACPI, Takashi Iwai, Carlos Mafra,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Rafael J. Wysocki, Florian Mickler, Network Development,
Dave Airlie, Andrew Morton, Kernel Testers List, Linux PM List,
Maciej Rutecki
In-Reply-To: <AANLkTimQPPDyBwkN0HWM2+bPcbzVd8YHZvn2iR8MVzfL@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4011 bytes --]
On Thu, 3 Feb 2011 16:30:56 -0800, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <airlied@gmail.com> wrote:
> >
> > If we are setting a mode on a connector it automatically will end up
> > in a DPMS on state,
> > so this seemed correct from what I can see.
>
> The more I look at that function, the more I disagree with you and
> with that patch.
>
> The code is just crazy.
>
> First off, it isn't even necessarily setting a mode to begin with,
> because as far as I can tell. If the mode doesn't change, neither
> mode_changed nor fb_changed will be true, afaik. There seems to be a
> fair amount of code there explicitly to avoid changing modes if not
> necessary.
>
> But even _if_ we are setting a mode, if I read the code correctly, the
> mode may be set to NULL - which seems to mean "turn it off". In which
> case it looks to me that drm_helper_disable_unused_functions() will
> actually do a
>
> (*crtc_funcs->dpms)(crtc, DRM_MODE_DPMS_OFF);
>
> call on the crtc in question. So then blindly just saying "it's mode
> DRM_MODE_DPMS_ON" afterwards looks rather bogus to me.
>
> _Maybe_ it would work if it was done before that whole
> "disable_unused" logic. Or maybe it should just be done in
> drm_crtc_helper_set_mode(), which is what actually sets the mode (but
> there's the 'fb_changed' case too)
>
> > A future mode set shouldn't ever not turn the connector on, since
> > modesetting is an implicit
> > DPMS,
> >
> > It sounds like something more subtle than that, though I'm happy to
> > revert this for now, and let Keith
> > think about it a bit more.
>
> So I haven't heard anything from Keith. Keith? Just revert it? Or do
> you have a patch for people to try?
The goal is to make it so that when you *do* set a mode, DPMS gets set
to ON (as the monitor will actually be "on" at that point). Here's a
patch which does the DPMS_ON precisely when setting a mode.
Dave thinks we should instead force dpms to match crtc->enabled, I'd
rather have dpms get set when we know the hardware has been changed.
(note, this patch compiles, but is otherwise only lightly tested).
From 38507bb3a67441425e11085d17d727f3b230f927 Mon Sep 17 00:00:00 2001
From: Keith Packard <keithp@keithp.com>
Date: Thu, 3 Feb 2011 16:57:28 -0800
Subject: [PATCH] drm: Only set DPMS ON when actually configuring a mode
In drm_crtc_helper_set_config, instead of always forcing all outputs
to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a
mode set, as any mode set will turn all outputs on.
Signed-off-by: Keith Packard <keithp@keithp.com>
---
drivers/gpu/drm/drm_crtc_helper.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 952b3d4..17459ee 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -665,6 +665,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
ret = -EINVAL;
goto fail;
}
+ DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
+ for (i = 0; i < set->num_connectors; i++) {
+ DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", set->connectors[i]->base.id,
+ drm_get_connector_name(set->connectors[i]));
+ set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+ }
}
drm_helper_disable_unused_functions(dev);
} else if (fb_changed) {
@@ -681,12 +687,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
goto fail;
}
}
- DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
- for (i = 0; i < set->num_connectors; i++) {
- DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", set->connectors[i]->base.id,
- drm_get_connector_name(set->connectors[i]));
- set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
- }
kfree(save_connectors);
kfree(save_encoders);
--
1.7.2.3
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Dave Airlie @ 2011-02-04 0:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carlos Mafra, Keith Packard, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTimQPPDyBwkN0HWM2+bPcbzVd8YHZvn2iR8MVzfL@mail.gmail.com>
On Fri, Feb 4, 2011 at 10:30 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <airlied@gmail.com> wrote:
>>
>> If we are setting a mode on a connector it automatically will end up
>> in a DPMS on state,
>> so this seemed correct from what I can see.
>
> The more I look at that function, the more I disagree with you and
> with that patch.
>
> The code is just crazy.
Good point, I'm just trying to get -rc3 onto a machine where I can
reproduce this now, unfortunately that looks like the machine with the
1.8" disk, so this could take a little while.
hopefully Keith will decloak and tell us more.
Dave.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-04 0:30 UTC (permalink / raw)
To: Dave Airlie
Cc: Carlos Mafra, Keith Packard, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTin7kBur95H=UBcYEcjYsUkrdG8znX-7PFZ4rrHf@mail.gmail.com>
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <airlied@gmail.com> wrote:
>
> If we are setting a mode on a connector it automatically will end up
> in a DPMS on state,
> so this seemed correct from what I can see.
The more I look at that function, the more I disagree with you and
with that patch.
The code is just crazy.
First off, it isn't even necessarily setting a mode to begin with,
because as far as I can tell. If the mode doesn't change, neither
mode_changed nor fb_changed will be true, afaik. There seems to be a
fair amount of code there explicitly to avoid changing modes if not
necessary.
But even _if_ we are setting a mode, if I read the code correctly, the
mode may be set to NULL - which seems to mean "turn it off". In which
case it looks to me that drm_helper_disable_unused_functions() will
actually do a
(*crtc_funcs->dpms)(crtc, DRM_MODE_DPMS_OFF);
call on the crtc in question. So then blindly just saying "it's mode
DRM_MODE_DPMS_ON" afterwards looks rather bogus to me.
_Maybe_ it would work if it was done before that whole
"disable_unused" logic. Or maybe it should just be done in
drm_crtc_helper_set_mode(), which is what actually sets the mode (but
there's the 'fb_changed' case too)
> A future mode set shouldn't ever not turn the connector on, since
> modesetting is an implicit
> DPMS,
>
> It sounds like something more subtle than that, though I'm happy to
> revert this for now, and let Keith
> think about it a bit more.
So I haven't heard anything from Keith. Keith? Just revert it? Or do
you have a patch for people to try?
Linus
^ permalink raw reply
* [PATCH] niu: Fix races between up/down and get_stats.
From: David Miller @ 2011-02-04 0:25 UTC (permalink / raw)
To: netdev; +Cc: fleitner
As reported by Flavio Leitner, there is no synchronization to protect
NIU's get_stats method from seeing a NULL pointer in either
np->rx_rings or np->tx_rings. In fact, as far as ->ndo_get_stats
is concerned, these values are set completely asynchronously.
Flavio attempted to fix this using a RW semaphore, which in fact
works most of the time. However, dev_get_stats() can be invoked
from non-sleepable contexts in some cases, so this fix doesn't
work in all cases.
So instead, control the visibility of the np->{rx,tx}_ring pointers
when the device is being brough up, and use properties of the device
down sequence to our advantage.
In niu_get_stats(), return immediately if netif_running() is false.
The device shutdown sequence first marks the device as not running (by
clearing the __LINK_STATE_START bit), then it performans a
synchronize_rcu() (in dev_deactive_many()), and then finally it
invokes the driver ->ndo_stop() method.
This guarentees that all invocations of niu_get_stats() either see
netif_running() as false, or they see the channel pointers before
->ndo_stop() clears them out.
If netif_running() is true, protect against startup races by loading
the np->{rx,tx}_rings pointer into a local variable, and punting if
it is NULL. Use ACCESS_ONCE to prevent the compiler from reloading
the pointer on us.
Also, during open, control the order in which the pointers and the
ring counts become visible globally using SMP write memory barriers.
We make sure the np->num_{rx,tx}_rings value is stable and visible
before np->{rx,tx}_rings is.
Such visibility control is not necessary on the niu_free_channels()
side because of the RCU sequencing that happens during device down as
described above. We are always guarenteed that all niu_get_stats
calls are finished, or will see netif_running() false, by the time
->ndo_stop is invoked.
Reported-by: Flavio Leitner <fleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/niu.c | 61 +++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index 2541321..9fb59d3 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -4489,6 +4489,9 @@ static int niu_alloc_channels(struct niu *np)
{
struct niu_parent *parent = np->parent;
int first_rx_channel, first_tx_channel;
+ int num_rx_rings, num_tx_rings;
+ struct rx_ring_info *rx_rings;
+ struct tx_ring_info *tx_rings;
int i, port, err;
port = np->port;
@@ -4498,18 +4501,21 @@ static int niu_alloc_channels(struct niu *np)
first_tx_channel += parent->txchan_per_port[i];
}
- np->num_rx_rings = parent->rxchan_per_port[port];
- np->num_tx_rings = parent->txchan_per_port[port];
+ num_rx_rings = parent->rxchan_per_port[port];
+ num_tx_rings = parent->txchan_per_port[port];
- netif_set_real_num_rx_queues(np->dev, np->num_rx_rings);
- netif_set_real_num_tx_queues(np->dev, np->num_tx_rings);
-
- np->rx_rings = kcalloc(np->num_rx_rings, sizeof(struct rx_ring_info),
- GFP_KERNEL);
+ rx_rings = kcalloc(num_rx_rings, sizeof(struct rx_ring_info),
+ GFP_KERNEL);
err = -ENOMEM;
- if (!np->rx_rings)
+ if (!rx_rings)
goto out_err;
+ np->num_rx_rings = num_rx_rings;
+ smp_wmb();
+ np->rx_rings = rx_rings;
+
+ netif_set_real_num_rx_queues(np->dev, num_rx_rings);
+
for (i = 0; i < np->num_rx_rings; i++) {
struct rx_ring_info *rp = &np->rx_rings[i];
@@ -4538,12 +4544,18 @@ static int niu_alloc_channels(struct niu *np)
return err;
}
- np->tx_rings = kcalloc(np->num_tx_rings, sizeof(struct tx_ring_info),
- GFP_KERNEL);
+ tx_rings = kcalloc(num_tx_rings, sizeof(struct tx_ring_info),
+ GFP_KERNEL);
err = -ENOMEM;
- if (!np->tx_rings)
+ if (!tx_rings)
goto out_err;
+ np->num_tx_rings = num_tx_rings;
+ smp_wmb();
+ np->tx_rings = tx_rings;
+
+ netif_set_real_num_tx_queues(np->dev, num_tx_rings);
+
for (i = 0; i < np->num_tx_rings; i++) {
struct tx_ring_info *rp = &np->tx_rings[i];
@@ -6246,11 +6258,17 @@ static void niu_sync_mac_stats(struct niu *np)
static void niu_get_rx_stats(struct niu *np)
{
unsigned long pkts, dropped, errors, bytes;
+ struct rx_ring_info *rx_rings;
int i;
pkts = dropped = errors = bytes = 0;
+
+ rx_rings = ACCESS_ONCE(np->rx_rings);
+ if (!rx_rings)
+ goto no_rings;
+
for (i = 0; i < np->num_rx_rings; i++) {
- struct rx_ring_info *rp = &np->rx_rings[i];
+ struct rx_ring_info *rp = &rx_rings[i];
niu_sync_rx_discard_stats(np, rp, 0);
@@ -6259,6 +6277,8 @@ static void niu_get_rx_stats(struct niu *np)
dropped += rp->rx_dropped;
errors += rp->rx_errors;
}
+
+no_rings:
np->dev->stats.rx_packets = pkts;
np->dev->stats.rx_bytes = bytes;
np->dev->stats.rx_dropped = dropped;
@@ -6268,16 +6288,24 @@ static void niu_get_rx_stats(struct niu *np)
static void niu_get_tx_stats(struct niu *np)
{
unsigned long pkts, errors, bytes;
+ struct tx_ring_info *tx_rings;
int i;
pkts = errors = bytes = 0;
+
+ tx_rings = ACCESS_ONCE(np->tx_rings);
+ if (!tx_rings)
+ goto no_rings;
+
for (i = 0; i < np->num_tx_rings; i++) {
- struct tx_ring_info *rp = &np->tx_rings[i];
+ struct tx_ring_info *rp = &tx_rings[i];
pkts += rp->tx_packets;
bytes += rp->tx_bytes;
errors += rp->tx_errors;
}
+
+no_rings:
np->dev->stats.tx_packets = pkts;
np->dev->stats.tx_bytes = bytes;
np->dev->stats.tx_errors = errors;
@@ -6287,9 +6315,10 @@ static struct net_device_stats *niu_get_stats(struct net_device *dev)
{
struct niu *np = netdev_priv(dev);
- niu_get_rx_stats(np);
- niu_get_tx_stats(np);
-
+ if (netif_running(dev)) {
+ niu_get_rx_stats(np);
+ niu_get_tx_stats(np);
+ }
return &dev->stats;
}
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 0/3] r8169 driver fixes
From: David Miller @ 2011-02-04 0:11 UTC (permalink / raw)
To: romieu; +Cc: netdev, ivecera, hayeswang
In-Reply-To: <20110203235500.GA9137@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Fri, 4 Feb 2011 00:55:00 +0100
> David Miller <davem@davemloft.net> :
>> These are bug fixes, but this GIT branch is based upon net-next-2.6,
>> what is the intent here?
>
> It should have been based on $(git merge-base master net-2.6) instead
> of net-ext-2.6.
>
> I'll rebase it after some sleep.
Ok, thank you.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Dave Airlie @ 2011-02-04 0:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carlos Mafra, Keith Packard, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTi=7EOih=fY5FCvhQbewSc=3a49cYVaKJRWM+-3d@mail.gmail.com>
On Fri, Feb 4, 2011 at 8:10 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra <crmafra2@gmail.com> wrote:
>>>
>>> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
>>> post-2.6.36 regressions for further tracking.
>>
>> I also tested on 2.6.38-rc3+ now and the issue is not solved,
>> just like Takashi expected.
>
> Hmm. That commit (bf9dc102e284) still reverts cleanly.
>
> Keith, Dave, should we just revert it? It's definitely a regression,
> and we do _not_ allow "fixes" to one thing that just causes a
> regression to another.
>
> Quite frankly, I think it's totally wrong to just blindly set DPMS
> status to ON like that. It's as wrong as it was to leave it off, and
> the regressions reported are basically mirror images of the exact same
> bug that that commit tried to fix.
>
> IOW, the commit message says:
>
> When setting a new crtc configuration, force the DPMS state of all
> connectors to ON. Otherwise, they'll be left at OFF and a future mode set
> that disables the specified connector will not turn the connector off.
>
> but setting it to ON doesn't actually _fix_ anything, because you just
> get the exact same issue in reverse, ie you just get
>
> .. and a future mode set that ENables the specified connector will
> not turn the connector ON.
If we are setting a mode on a connector it automatically will end up
in a DPMS on state,
so this seemed correct from what I can see.
A future mode set shouldn't ever not turn the connector on, since
modesetting is an implicit
DPMS,
It sounds like something more subtle than that, though I'm happy to
revert this for now, and let Keith
think about it a bit more.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] r8169 driver fixes
From: Francois Romieu @ 2011-02-03 23:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ivecera, hayeswang
In-Reply-To: <20110203.151802.39181951.davem@davemloft.net>
David Miller <davem@davemloft.net> :
> These are bug fixes, but this GIT branch is based upon net-next-2.6,
> what is the intent here?
It should have been based on $(git merge-base master net-2.6) instead
of net-ext-2.6.
I'll rebase it after some sleep.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Yuchung Cheng @ 2011-02-03 23:54 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, Netdev, therbert, H.K. Jerry Chu, Nandita Dukkipati
In-Reply-To: <alpine.DEB.2.00.1102040027060.25125@melkinpaasi.cs.helsinki.fi>
On Thu, Feb 3, 2011 at 2:43 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> It would perhaps be useful to change receiver advertized window to include
> some extra segs initially. It should be >= IW + peer's dupThresh-1 as
That's a very good point.
Maybe IRW should be IW + ssthresh - 1 since Linux also performs
limited-transmit during fast-recovery as described in RFC 3517. This
way sender can keep sending new data during the recovery as long as
cwnd allows.
> otherwise limited transmit won't work for the initial window because we
> won't open more receiver window with dupacks (IIRC, I suppose Jerry might
> be able to correct me right away if I'm wrong and we open window with
> dupacks too?). I think initial receiver window code used to have some
> surplus but it was broken by the rfc3390-func conversion (against my
> advice on how to do the conversion).
>
> --
> i.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: David Miller @ 2011-02-03 23:53 UTC (permalink / raw)
To: fleitner; +Cc: netdev
In-Reply-To: <20110203234748.GB3710@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Thu, 3 Feb 2011 21:47:48 -0200
> On Thu, Feb 03, 2011 at 03:22:14PM -0800, David Miller wrote:
>> One thing I'm worried about with your patch is that the statistics
>> method can be called in basically any context, therefore a sleeping
>> lock like the rw_semaphore is probably not usable.
>>
>> In fact I'm going to revert your patch for now because of this issue.
>
> Oops, I didn't see it there. I thought all calls there were process
> context. Anyway, RCU then...
Yes, one example is the dev_get_stats() call made in
drivers/net/bonding/bond_main.c, which occurs with a
rw spinlock held and BH disabled.
> thanks for reviewing it,
No problem. I think I even have a way to fix this without using RCU
(directly). Just some memory barriers during allocation of the
channels.
I'll post the patch after I'm done with it, thanks again Falvio.
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: Flavio Leitner @ 2011-02-03 23:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110203.152214.59684545.davem@davemloft.net>
On Thu, Feb 03, 2011 at 03:22:14PM -0800, David Miller wrote:
> From: Flavio Leitner <fleitner@redhat.com>
> Date: Thu, 3 Feb 2011 21:18:05 -0200
>
> > Ok, I can write a new version using RCU if you like.
>
> Don't worry, I'll take care of it, I actually have the
> hardware to test on :-)
Ok. Having the hardware around indeed helps :)
> > I've chose rwsem because I think those operations aren't
> > frequent. The RCU leaves an operation to run later during
> > a safe context, so I thought the cost doesn't worth it.
>
> One thing I'm worried about with your patch is that the statistics
> method can be called in basically any context, therefore a sleeping
> lock like the rw_semaphore is probably not usable.
>
> In fact I'm going to revert your patch for now because of this issue.
Oops, I didn't see it there. I thought all calls there were process
context. Anyway, RCU then...
thanks for reviewing it,
--
Flavio
^ permalink raw reply
* Re: [E1000-devel] [PATCH] fixing hw timestamping in igb
From: Jeff Kirsher @ 2011-02-03 23:23 UTC (permalink / raw)
To: Anders Berggren
Cc: Ronciak, John, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, Ohly, Patrick
In-Reply-To: <9D02360A-8016-4BCB-B14A-DAFE22EF558E@halon.se>
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
On Thu, 2011-02-03 at 02:39 -0800, Anders Berggren wrote:
> Hardware timestamping for Intel 82580 didn't work in either 2.6.36 or 2.6.37. Comparing it to Intel's igb-2.4.12 I found that the timecounter_init clock/counter initialization was done too early.
>
> Anders Berggren
> Halon Security
Thanks Anders, I will add this patch to my queue of igb patches.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: David Miller @ 2011-02-03 23:22 UTC (permalink / raw)
To: fleitner; +Cc: netdev
In-Reply-To: <20110203231805.GA3710@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Thu, 3 Feb 2011 21:18:05 -0200
> Ok, I can write a new version using RCU if you like.
Don't worry, I'll take care of it, I actually have the
hardware to test on :-)
> I've chose rwsem because I think those operations aren't
> frequent. The RCU leaves an operation to run later during
> a safe context, so I thought the cost doesn't worth it.
One thing I'm worried about with your patch is that the statistics
method can be called in basically any context, therefore a sleeping
lock like the rw_semaphore is probably not usable.
In fact I'm going to revert your patch for now because of this issue.
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: Flavio Leitner @ 2011-02-03 23:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110203.142145.183054407.davem@davemloft.net>
On Thu, Feb 03, 2011 at 02:21:45PM -0800, David Miller wrote:
> From: Flavio Leitner <fleitner@redhat.com>
> Date: Thu, 3 Feb 2011 16:45:17 -0200
>
> > It's possible to trigger a crash if one CPU is opening
> > the device while another CPU gets its statistics.
> >
> > It happens because niu_alloc_channels() called from
> > niu_open() sets num_tx/rx_rings before allocating the
> > ring, so the other thread crashes when accessing
> > np->tx_rings[i].tx_packets at niu_get_tx_stats().
> >
> > Signed-off-by: Flavio Leitner <fleitner@redhat.com>
> ...
> > Compile tested only because I don't have the hardware.
>
> I'll apply this and give it a quick test, thanks.
>
> Can you have the person who reported this crash to you test the patch
> out at least? That's how you learned about this problem, right,
> someone else hit the crash?
>
> In such cases I'd really appreciate it if you got positive testing
> feedback from the reporter before posting the patch.
>
> Longer term a better way to fix this is to RCU free the ring data
> structures, and use a quick NULL test at the top of the get stats
> implementation.
Ok, I can write a new version using RCU if you like.
I've chose rwsem because I think those operations aren't
frequent. The RCU leaves an operation to run later during
a safe context, so I thought the cost doesn't worth it.
I'm trying to get testing feedback as well, not sure yet
if it will be possible though. Anyway, I'll update here
when I heard something.
thanks!
--
Flavio
^ permalink raw reply
* Re: [PATCH 0/3] r8169 driver fixes
From: David Miller @ 2011-02-03 23:18 UTC (permalink / raw)
To: romieu; +Cc: netdev, ivecera, hayeswang
In-Reply-To: <20110203172557.GA9024@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 3 Feb 2011 18:26:11 +0100
> The following series includes Ivan Rx fifo overflow fix and similar
> changes I did after testing with various 8168 chipsets.
>
> The series is available as
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r8169-davem
These are bug fixes, but this GIT branch is based upon net-next-2.6,
what is the intent here?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox