* Re: TCP: orphans broken by RFC 2525 #2.17
From: Rick Jones @ 2010-09-27 20:08 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Herbert Xu, netdev
In-Reply-To: <20100927200018.GY12373@1wt.eu>
Willy Tarreau wrote:
> Hi Herbert,
>
> On Mon, Sep 27, 2010 at 04:02:22PM +0800, Herbert Xu wrote:
>
>>Willy Tarreau <w@1wt.eu> wrote:
>>
>>>Looking more closely, I noticed that in traces showing the issue,
>>>the client was sending an additional CRLF after the data in a
>>>separate packet (permitted eventhough not recommended).
>>
>>Where is this permitted? RFC2616 says:
>>
>> Certain buggy HTTP/1.0 client implementations generate
>> extra CRLF's after a POST request. To restate what is
>> explicitly forbidden by the BNF, an HTTP/1.1 client MUST
>> NOT preface or follow a request with an extra CRLF.
>
>
> And the paragraph just before says :
>
> In the interest of robustness, servers SHOULD ignore any empty
> line(s) received where a Request-Line is expected. In other words, if
> the server is reading the protocol stream at the beginning of a
> message and receives a CRLF first, it should ignore the CRLF.
It is the HTTP server code being addressed there, not the underlying TCP stack
is it not?
rick jones
^ permalink raw reply
* Re: [PATCH] iwl3945: queue the right work if the scan needs to be aborted
From: Guy, Wey-Yi @ 2010-09-27 20:11 UTC (permalink / raw)
To: Florian Mickler
Cc: linux-wireless@vger.kernel.org, Chatre, Reinette,
Intel Linux Wireless, John W. Linville, Berg, Johannes, Zhu Yi,
Cahill, Ben M, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1285345323-4250-1-git-send-email-florian@mickler.org>
On Fri, 2010-09-24 at 09:22 -0700, Florian Mickler wrote:
> iwl3945's scan_completed calls into the mac80211 stack which triggers a
> warn on if there is no scan outstanding.
>
> This can be avoided by not calling scan_completed but abort_scan in
> iwl3945_request_scan in the done: branch of the function which is used
> as an error out.
>
> The done: branch seems to be an error-out branch, as, for example, if
> iwl_is_ready(priv) returns false the done: branch is executed.
>
> NOTE:
> I'm not familiar with the driver at all.
> I just quickly scanned as a reaction to
>
> https://bugzilla.kernel.org/show_bug.cgi?id=17722
>
> the users of scan_completed in the iwl3945 driver and noted the odd
> discrepancy between the comment above this instance and the comment in
> mac80211 scan_completed function.
> Signed-off-by: Florian Mickler <florian@mickler.org>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
go into wireless-2.6 and stable only, scan fix already in
wireless-next-2.6
Thanks
Wey
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> index 9dd9e64..8fd00a6 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> @@ -1411,7 +1411,7 @@ void iwlagn_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
> clear_bit(STATUS_SCAN_HW, &priv->status);
> clear_bit(STATUS_SCANNING, &priv->status);
> /* inform mac80211 scan aborted */
> - queue_work(priv->workqueue, &priv->scan_completed);
> + queue_work(priv->workqueue, &priv->abort_scan);
> }
>
> int iwlagn_manage_ibss_station(struct iwl_priv *priv,
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index 59a308b..d31661c 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -3018,7 +3018,7 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
> clear_bit(STATUS_SCANNING, &priv->status);
>
> /* inform mac80211 scan aborted */
> - queue_work(priv->workqueue, &priv->scan_completed);
> + queue_work(priv->workqueue, &priv->abort_scan);
> }
>
> static void iwl3945_bg_restart(struct work_struct *data)
^ permalink raw reply
* Re:
From: David Stevens @ 2010-09-27 20:14 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Lameter, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <20100927200500.GB25879-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote on 09/27/2010
01:05:00 PM:
> On Mon, Sep 27, 2010 at 12:32:45PM -0700, David Stevens wrote:
>
> > You can, of course, add a querier (or configure it, assuming an
> > attached switch supports it) and set the query interval and
> > robustness count as appropriate for that network.
>
> Presumably the IPoIB multicast router should already be the querier..
> How does this help handling joins to new groups?
Because a querier can set the robustness value and
query interval to anything you want. In the original report,
he's not running a querier. The fact that it's a new group
doesn't matter -- these are per-interface.
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Ohad Ben-Cohen @ 2010-09-27 20:18 UTC (permalink / raw)
To: John W. Linville; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100927194408.GG11086@tuxdriver.com>
On Mon, Sep 27, 2010 at 9:44 PM, John W. Linville
<linville@tuxdriver.com> wrote:
>> On Mon, Sep 27, 2010 at 9:01 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> >> CONFIG_MACH_OMAP_ZOOM2=y
>> >> CONFIG_WL12XX_PLATFORM_DATA=n
>>
>> That's a good point (it's a separate issue); we need to have a select there.
>>
>> I'll send a patch.
>
> No, maybe you don't need it -- the bool line by itself means there
> is no menu item. So the default y does the job of selecting it all
> the time (which kinda sucks for non-OMAP)...
The default y will kick in only if WL1271_SDIO is selected:
>> > config WL12XX_PLATFORM_DATA
>> > bool
>> > depends on WL1271_SDIO != n
>> > default y
But if we don't select this driver at all, we better have something like:
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 95deae3..51e4ba9 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -32,7 +32,20 @@ struct wl12xx_platform_data {
int board_ref_clock;
};
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+
int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
+
+#else
+
+static inline int wl12xx_set_platform_data(const struct
+ wl12xx_platform_data *data)
+{
+ return -ENOSYS;
+}
+
+#endif
+
const struct wl12xx_platform_data *wl12xx_get_platform_data(void);
#endif
It's better than forcing a select - if we don't need the driver, we
don't need this piece of code too.
I'll give this a spin tomorrow and send it over nicely.
> Can't we do this? It seems to work (i.e. the symbols from
> wl12xx_platform_data.o end-up in built-in.o).
Yes, this one looks good !
Thanks a lot, John.
>
> From d8ddd0ebe8ae3791ba9c76a506bfcdd60be40f5b Mon Sep 17 00:00:00 2001
> From: John W. Linville <linville@tuxdriver.com>
> Date: Mon, 27 Sep 2010 14:00:51 -0400
> Subject: [PATCH] wl12xx: fix separate-object-folder builds
>
> Make this go away (happens when building with a separate object
> directory):
>
> Assembler messages:
> Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/net/wireless/Makefile | 3 +--
> drivers/net/wireless/wl12xx/Makefile | 3 +++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
> index 85af697..a13a602 100644
> --- a/drivers/net/wireless/Makefile
> +++ b/drivers/net/wireless/Makefile
> @@ -50,7 +50,6 @@ obj-$(CONFIG_ATH_COMMON) += ath/
> obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
>
> obj-$(CONFIG_WL12XX) += wl12xx/
> -# small builtin driver bit
> -obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
> +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/
>
> obj-$(CONFIG_IWM) += iwmc3200wifi/
> diff --git a/drivers/net/wireless/wl12xx/Makefile b/drivers/net/wireless/wl12xx/Makefile
> index 078b439..0d334d6 100644
> --- a/drivers/net/wireless/wl12xx/Makefile
> +++ b/drivers/net/wireless/wl12xx/Makefile
> @@ -16,3 +16,6 @@ wl1271-$(CONFIG_NL80211_TESTMODE) += wl1271_testmode.o
> obj-$(CONFIG_WL1271) += wl1271.o
> obj-$(CONFIG_WL1271_SPI) += wl1271_spi.o
> obj-$(CONFIG_WL1271_SDIO) += wl1271_sdio.o
> +
> +# small builtin driver bit
> +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
> --
> 1.7.2.3
>
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
>
^ permalink raw reply related
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-27 20:20 UTC (permalink / raw)
To: Rick Jones; +Cc: Herbert Xu, netdev
In-Reply-To: <4CA0F9AD.5050302@hp.com>
On Mon, Sep 27, 2010 at 01:08:13PM -0700, Rick Jones wrote:
> Willy Tarreau wrote:
> >Hi Herbert,
> >
> >On Mon, Sep 27, 2010 at 04:02:22PM +0800, Herbert Xu wrote:
> >
> >>Willy Tarreau <w@1wt.eu> wrote:
> >>
> >>>Looking more closely, I noticed that in traces showing the issue,
> >>>the client was sending an additional CRLF after the data in a
> >>>separate packet (permitted eventhough not recommended).
> >>
> >>Where is this permitted? RFC2616 says:
> >>
> >> Certain buggy HTTP/1.0 client implementations generate
> >> extra CRLF's after a POST request. To restate what is
> >> explicitly forbidden by the BNF, an HTTP/1.1 client MUST
> >> NOT preface or follow a request with an extra CRLF.
> >
> >
> >And the paragraph just before says :
> >
> > In the interest of robustness, servers SHOULD ignore any empty
> > line(s) received where a Request-Line is expected. In other words, if
> > the server is reading the protocol stream at the beginning of a
> > message and receives a CRLF first, it should ignore the CRLF.
>
> It is the HTTP server code being addressed there, not the underlying TCP
> stack is it not?
yes, precisely.
regards,
Willy
^ permalink raw reply
* Re: igmp: Allow mininum interval specification for igmp timers.
From: Christoph Lameter @ 2010-09-27 20:20 UTC (permalink / raw)
To: David Stevens; +Cc: David Miller, linux-rdma, netdev, netdev-owner, rda
In-Reply-To: <OFC4EC0538.26831D99-ON882577AB.006B8055-882577AB.006D75FF@us.ibm.com>
On Mon, 27 Sep 2010, David Stevens wrote:
> > With bad luck this thing times out way too fast because the total of
> > all of the randomized intervals can end up being very small, and I
> > think we should fix that independently of the other issues hit by the
> > IB folks.
>
> I think I'm caught up on the discussion now. For IGMPv3, we
> would send all the reports always in < 2 secs, and the average would
> be < 1 sec, so I'm not sure any sort of tweaks we do to enforce a
> minimum randomized interval are compatible with IGMPv3 and still
> solve IB's problem.
Ok thanks for the effort but so far I do not see you having caught up. I'd
rather avoid responding to the misleading statements you made in other
replies and just respond to where you missed the boat here.
> As I said before, I think per protocol, back-to-back is both
> allowed and not a problem, even if both subsequent randomized reports
> come out to 0 time. But if we wanted to enforce a minimum interval
> of, say, X, then I think the better way to do that is to set the
> timer to X + rand(Interval-X) and not a table of fixed intervals
The second patch sets the intervals to X .. X + Rand (interval) and not to
a table of fixed intervals as you state here. I have pointed this out
before.
> as in the original patch. For v2, X=1 or 2 sec and Interval=10
> might work well, but for v3, the entire interval is 1 sec and I
> think I saw that the set-up time for the fabric may be on the
> order of 1 sec.
Again there is no knowledge about V2 or V3 without a query and this is
during the period when no querier is known yet. You stated elsewhere that
I can assume V3 by default? So 1 sec?
> I also don't think that we want those kinds of delays on
> Ethernet. A program may join and send lots of traffic in 1 sec,
> and if the immediate join is lost, one of the quickly-following
> <1 sec duplicate reports will make it recover and work. Delaying
> the minimum would guarantee it wouldn't work until that minimum
> and drop all that traffic if the immediate report is lost, then.
There can be any number of reasons that a short outage could prevent the
packets from going through. A buffer overrun (that you mentioned
elsewhere) usually causes lots of packets to be lost. Buffer overrun
scenarios usually mean that all igmp queries are lost.
> Really, of course, I think the solution belongs in IB, but
> if we did anything in IGMP, I'd prefer it were a per-interface
> tunable that defaults as in the RFC. Since you can change the
> interval and # of reports through a querier now, exporting the
> default values of (10,2) for v2 and (1,2) for v3 to instead be
> per-interface tunables and then bumped as needed for IB would
> allow tweaking without running a querier. But a querier that's
> using default values would also override that and cause the
> problem all over again. Queuing in the driver until the MAC
> address is usable solves it generally.
There is no solution on the IB layer since there is no notification when
the fabric reconfiguration necessary for an multicast group is complete.
The querier is of not use since (for the gazillionth of times) this is an
unsolicited IGMP report. If there is a querier then the unsolicited igmp
reports would not be used but the timeout indicated by the querier would
be used.
^ permalink raw reply
* Re:
From: Christoph Lameter @ 2010-09-27 20:23 UTC (permalink / raw)
To: David Stevens
Cc: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <OF056C7E7C.A9A5EFC7-ON882577AB.006E6B89-882577AB.006F2C1E-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
On Mon, 27 Sep 2010, David Stevens wrote:
> Because a querier can set the robustness value and
> query interval to anything you want. In the original report,
> he's not running a querier. The fact that it's a new group
> doesn't matter -- these are per-interface.
The per interface settings are used to force an IGMP version overriding
any information by the queriers. You would not want to enable that because
it disables support for other IGMP versions. Without the override
different version of IGMP can be handled per MC group.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re:
From: Bob Arendt @ 2010-09-27 20:54 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Stevens, Jason Gunthorpe,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <alpine.DEB.2.00.1009271521510.14117-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On 09/27/10 13:23, Christoph Lameter wrote:
> On Mon, 27 Sep 2010, David Stevens wrote:
>
>> Because a querier can set the robustness value and
>> query interval to anything you want. In the original report,
>> he's not running a querier. The fact that it's a new group
>> doesn't matter -- these are per-interface.
>
> The per interface settings are used to force an IGMP version overriding
> any information by the queriers. You would not want to enable that because
> it disables support for other IGMP versions. Without the override
> different version of IGMP can be handled per MC group.
>
If a network vlan has IGMPv3 capability, then it should be able
to support both v2 and v3 Joins (clients). But if the vlan is
IGMPv2 only, then an initial Join from a Linux client might go out
as v3 (if it hasn't seen a query yet) and be ignored. I believe
this is the case that force_igmp_version really addresses.
And it turns out that force_igmp_version=2 doesn't fully work.
If the host sees a IGMPv3 query, it still responds with a v3 Join
despite the flag. Bug report and candidate patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=18212
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v11 13/17] Add mp(mediate passthru) device.
From: Ben Hutchings @ 2010-09-27 21:23 UTC (permalink / raw)
To: xiaohui.xin; +Cc: netdev, kvm, linux-kernel, mingo, davem, herbert, jdike
In-Reply-To: <2c954a831e2d9a93437aaf06386cd3a5af6b73b9.1285385607.git.xiaohui.xin@intel.com>
On Sat, 2010-09-25 at 12:27 +0800, xiaohui.xin@intel.com wrote:
> From: Xin Xiaohui <xiaohui.xin@intel.com>
>
> The patch add mp(mediate passthru) device, which now
> based on vhost-net backend driver and provides proto_ops
> to send/receive guest buffers data from/to guest vitio-net
> driver.
>
> Signed-off-by: Xin Xiaohui <xiaohui.xin@intel.com>
> Signed-off-by: Zhao Yu <yzhao81new@gmail.com>
> Reviewed-by: Jeff Dike <jdike@linux.intel.com>
> ---
> drivers/vhost/mpassthru.c | 1407 +++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 1407 insertions(+), 0 deletions(-)
> create mode 100644 drivers/vhost/mpassthru.c
>
> diff --git a/drivers/vhost/mpassthru.c b/drivers/vhost/mpassthru.c
> new file mode 100644
> index 0000000..d86d94c
> --- /dev/null
> +++ b/drivers/vhost/mpassthru.c
[...]
> +/* #define MPASSTHRU_DEBUG 1 */
> +
> +#ifdef MPASSTHRU_DEBUG
> +static int debug;
> +
> +#define DBG if (mp->debug) printk
> +#define DBG1 if (debug == 2) printk
This is unsafe; consider this usage:
if (foo)
DBG("bar\n");
else
baz();
You should use the standard pr_debug() or dev_dbg() instead.
[...]
> +struct page_ctor {
> + struct list_head readq;
> + int wq_len;
> + int rq_len;
> + spinlock_t read_lock;
Only one queue?!
I would have appreciated some introductory comments on these structures.
I still don't have any sort of clear picture of how this is all supposed
to work.
[...]
> +/* The main function to allocate external buffers */
> +static struct skb_ext_page *page_ctor(struct mpassthru_port *port,
> + struct sk_buff *skb, int npages)
> +{
> + int i;
> + unsigned long flags;
> + struct page_ctor *ctor;
> + struct page_info *info = NULL;
> +
> + ctor = container_of(port, struct page_ctor, port);
> +
> + spin_lock_irqsave(&ctor->read_lock, flags);
> + if (!list_empty(&ctor->readq)) {
> + info = list_first_entry(&ctor->readq, struct page_info, list);
> + list_del(&info->list);
> + ctor->rq_len--;
> + }
> + spin_unlock_irqrestore(&ctor->read_lock, flags);
> + if (!info)
> + return NULL;
> +
> + for (i = 0; i < info->pnum; i++)
> + get_page(info->pages[i]);
> + info->skb = skb;
> + return &info->ext_page;
> +}
Why isn't the npages parameter used?
[...]
> +static void relinquish_resource(struct page_ctor *ctor)
> +{
> + if (!(ctor->dev->flags & IFF_UP) &&
> + !(ctor->wq_len + ctor->rq_len))
> + printk(KERN_INFO "relinquish_resource\n");
> +}
Looks like something's missing here.
> +static void mp_ki_dtor(struct kiocb *iocb)
> +{
> + struct page_info *info = (struct page_info *)(iocb->private);
> + int i;
> +
> + if (info->flags == INFO_READ) {
> + for (i = 0; i < info->pnum; i++) {
> + if (info->pages[i]) {
> + set_page_dirty_lock(info->pages[i]);
> + put_page(info->pages[i]);
> + }
> + }
> + mp_hash_delete(info->ctor, info);
> + if (info->skb) {
> + info->skb->destructor = NULL;
> + kfree_skb(info->skb);
> + }
> + info->ctor->rq_len--;
Doesn't rq_len represent the number of buffers queued between the guest
and the driver? It is already decremented in page_ctor() so it seems
like it gets decremented twice for each buffer. Also don't you need to
hold the read_lock when updating rq_len?
> + } else
> + info->ctor->wq_len--;
Maybe you should define rq_len and wq_len both as atomic_t.
[...]
> +static void __mp_detach(struct mp_struct *mp)
> +{
> + mp->mfile = NULL;
> +
> + mp_dev_change_flags(mp->dev, mp->dev->flags & ~IFF_UP);
> + page_ctor_detach(mp);
> + mp_dev_change_flags(mp->dev, mp->dev->flags | IFF_UP);
This is racy; you should hold rtnl_lock over all these changes.
[...]
> +typedef u32 key_mp_t;
> +static inline key_mp_t mp_hash(struct page *page, int buckets)
> +{
> + key_mp_t k;
> +
> + k = ((((unsigned long)page << 32UL) >> 32UL) / 0x38) % buckets ;
> + return k;
> +}
This is never going to work on a 32-bit machine, and what is the purpose
of the magic number 0x38?
Try using hash_ptr() from <linux/hash.h>.
> +static struct page_info *mp_hash_delete(struct page_ctor *ctor,
> + struct page_info *info)
> +{
> + key_mp_t key = mp_hash(info->pages[0], HASH_BUCKETS);
> + struct page_info *tmp = NULL;
> + int i;
> +
> + tmp = ctor->hash_table[key];
> + while (tmp) {
> + if (tmp == info) {
> + if (!tmp->prev) {
> + ctor->hash_table[key] = tmp->next;
> + if (tmp->next)
> + tmp->next->prev = NULL;
> + } else {
> + tmp->prev->next = tmp->next;
> + if (tmp->next)
> + tmp->next->prev = tmp->prev;
> + }
> + return tmp;
> + }
> + tmp = tmp->next;
> + }
> + return tmp;
> +}
> +
> +static struct page_info *mp_hash_lookup(struct page_ctor *ctor,
> + struct page *page)
> +{
> + key_mp_t key = mp_hash(page, HASH_BUCKETS);
> + struct page_info *tmp = NULL;
> +
> + int i;
> + tmp = ctor->hash_table[key];
> + while (tmp) {
> + for (i = 0; i < tmp->pnum; i++) {
> + if (tmp->pages[i] == page)
> + return tmp;
> + }
> + tmp = tmp->next;
> + }
> + return tmp;
> +}
How are thse serialised?
> +/* The main function to transform the guest user space address
> + * to host kernel address via get_user_pages(). Thus the hardware
> + * can do DMA directly to the external buffer address.
> + */
> +static struct page_info *alloc_page_info(struct page_ctor *ctor,
> + struct kiocb *iocb, struct iovec *iov,
> + int count, struct frag *frags,
> + int npages, int total)
> +{
> + int rc;
> + int i, j, n = 0;
> + int len;
> + unsigned long base, lock_limit;
> + struct page_info *info = NULL;
> +
> + lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
> + lock_limit >>= PAGE_SHIFT;
> +
> + if (ctor->lock_pages + count > lock_limit && npages) {
> + printk(KERN_INFO "exceed the locked memory rlimit.");
> + return NULL;
> + }
What if the process is locking pages with mlock() as well? Doesn't this
allow it to lock twice as many pages as it should be able to?
> + info = kmem_cache_alloc(ext_page_info_cache, GFP_KERNEL);
> +
> + if (!info)
> + return NULL;
> + info->skb = NULL;
> + info->next = info->prev = NULL;
> +
> + for (i = j = 0; i < count; i++) {
> + base = (unsigned long)iov[i].iov_base;
> + len = iov[i].iov_len;
> +
> + if (!len)
> + continue;
> + n = ((base & ~PAGE_MASK) + len + ~PAGE_MASK) >> PAGE_SHIFT;
> +
> + rc = get_user_pages_fast(base, n, npages ? 1 : 0,
> + &info->pages[j]);
> + if (rc != n)
> + goto failed;
> +
> + while (n--) {
> + frags[j].offset = base & ~PAGE_MASK;
> + frags[j].size = min_t(int, len,
> + PAGE_SIZE - frags[j].offset);
> + len -= frags[j].size;
> + base += frags[j].size;
> + j++;
> + }
> + }
> +
> +#ifdef CONFIG_HIGHMEM
> + if (npages && !(dev->features & NETIF_F_HIGHDMA)) {
> + for (i = 0; i < j; i++) {
> + if (PageHighMem(info->pages[i]))
> + goto failed;
> + }
> + }
> +#endif
Shouldn't you try to allocate lowmem pages explicitly, rather than
failing at this point?
[...]
> +static int mp_recvmsg(struct kiocb *iocb, struct socket *sock,
> + struct msghdr *m, size_t total_len,
> + int flags)
> +{
> + struct mp_struct *mp = container_of(sock->sk, struct mp_sock, sk)->mp;
> + struct page_ctor *ctor;
> + struct iovec *iov = m->msg_iov;
> + int count = m->msg_iovlen;
> + int npages, payload;
> + struct page_info *info;
> + struct frag frags[MAX_SKB_FRAGS];
> + unsigned long base;
> + int i, len;
> + unsigned long flag;
> +
> + if (!(flags & MSG_DONTWAIT))
> + return -EINVAL;
> +
> + ctor = mp->ctor;
> + if (!ctor)
> + return -EINVAL;
> +
> + /* Error detections in case invalid external buffer */
> + if (count > 2 && iov[1].iov_len < ctor->port.hdr_len &&
> + mp->dev->features & NETIF_F_SG) {
> + return -EINVAL;
> + }
> +
> + npages = ctor->port.npages;
> + payload = ctor->port.data_len;
> +
> + /* If KVM guest virtio-net FE driver use SG feature */
> + if (count > 2) {
> + for (i = 2; i < count; i++) {
> + base = (unsigned long)iov[i].iov_base & ~PAGE_MASK;
> + len = iov[i].iov_len;
> + if (npages == 1)
> + len = min_t(int, len, PAGE_SIZE - base);
> + else if (base)
> + break;
> + payload -= len;
> + if (payload <= 0)
> + goto proceed;
> + if (npages == 1 || (len & ~PAGE_MASK))
> + break;
> + }
> + }
> +
> + if ((((unsigned long)iov[1].iov_base & ~PAGE_MASK)
> + - NET_SKB_PAD - NET_IP_ALIGN) >= 0)
> + goto proceed;
> +
> + return -EINVAL;
> +
> +proceed:
> + /* skip the virtnet head */
> + if (count > 1) {
> + iov++;
> + count--;
> + }
> +
> + if (!ctor->lock_pages || !ctor->rq_len) {
> + set_memlock_rlimit(ctor, RLIMIT_MEMLOCK,
> + iocb->ki_user_data * 4096 * 2,
> + iocb->ki_user_data * 4096 * 2);
> + }
> +
> + /* Translate address to kernel */
> + info = alloc_page_info(ctor, iocb, iov, count, frags, npages, 0);
> + if (!info)
> + return -ENOMEM;
I'm not convinced that the checks above this ensure that there will be
<= MAX_SKB_FRAGS fragments.
[...]
> +static int mp_chr_open(struct inode *inode, struct file * file)
> +{
> + struct mp_file *mfile;
> + cycle_kernel_lock();
Seriously?
[...]
> +static ssize_t mp_chr_aio_write(struct kiocb *iocb, const struct iovec *iov,
> + unsigned long count, loff_t pos)
> +{
> + struct file *file = iocb->ki_filp;
> + struct mp_struct *mp = mp_get(file->private_data);
> + struct sock *sk = mp->socket.sk;
> + struct sk_buff *skb;
> + int len, err;
> + ssize_t result = 0;
> +
> + if (!mp)
> + return -EBADFD;
> +
> + /* currently, async is not supported.
> + * but we may support real async aio from user application,
> + * maybe qemu virtio-net backend.
> + */
> + if (!is_sync_kiocb(iocb))
> + return -EFAULT;
> +
> + len = iov_length(iov, count);
> +
> + if (unlikely(len) < ETH_HLEN)
> + return -EINVAL;
The first close-paren is in the wrong place.
> + skb = sock_alloc_send_skb(sk, len + NET_IP_ALIGN,
> + file->f_flags & O_NONBLOCK, &err);
> +
> + if (!skb)
> + return -EFAULT;
Why EFAULT?
> + skb_reserve(skb, NET_IP_ALIGN);
> + skb_put(skb, len);
> +
> + if (skb_copy_datagram_from_iovec(skb, 0, iov, 0, len)) {
> + kfree_skb(skb);
> + return -EAGAIN;
> + }
> +
> + skb->protocol = eth_type_trans(skb, mp->dev);
Why are you calling eth_type_trans() on transmit?
[...]
> +static int mp_device_event(struct notifier_block *unused,
> + unsigned long event, void *ptr)
> +{
> + struct net_device *dev = ptr;
> + struct mpassthru_port *port;
> + struct mp_struct *mp = NULL;
> + struct socket *sock = NULL;
> + struct sock *sk;
> +
> + port = dev->mp_port;
> + if (port == NULL)
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case NETDEV_UNREGISTER:
> + sock = dev->mp_port->sock;
> + mp = container_of(sock->sk, struct mp_sock, sk)->mp;
> + do_unbind(mp->mfile);
[...]
This can deadlock - netdev notifiers are called under the RTNL lock and
do_unbind() acquires the mp_mutex, whereas in other places they are
acquired in the opposite order.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: BUG - qdev - partial loss of network connectivity
From: Leszek Urbanski @ 2010-09-27 21:32 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-nfs, qemu-devel, virtualization
In-Reply-To: <20100926154324.GD21843@redhat.com>
<20100926154324.GD21843@redhat.com>; from Michael S. Tsirkin on Sun, Sep 26, 2010 at 17:43:24 +0200
> > > >It's vanilla 2.6.32.22, but I also reproduced this on Debian's 2.6.32-23
> > > >(based on 2.6.32.21).
> > > >
> > > >If offload is the only difference, I'll play with different offload
> > > >options and check which one causes it.
> > > >
> > >
> > > It's not technically the only difference but it's the most likely
> > > culprit IMHO.
> >
> > udp fragmentation offload is definitely the culprit.
>
> I see. Most likely guest bug - won't be the first bug around UFO.
> If so pls copy netdev linux-nfs and virtualization.
> Do you see anything in dmesg? Can try 2.6.36-rc5?
(for reference: first post is at:
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01685.html )
I can't reproduce it on 2.6.36-rc5. Do you have an idea which patch may have
fixed it, or should I dissect?
2.6.32.x - there's nothing interesting in dmesg, apart from traces related
to tasks in D state waiting on the NFS mounts:
[ 84.396127] nfs: server 10.0.0.1 not responding, still trying
[ 240.568162] INFO: task cp:1838 blocked for more than 120 seconds.
[ 240.569715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 240.571486] cp D 0000000000000002 0 1838 1831 0x00000000
[ 240.573340] ffff88011fa5b880 0000000000000082 0000000000000000 ffff88011e45bb44
[ 240.575508] ffff88011e45bcc8 ffffffff8102cdac 000000000000f9e0 ffff88011e45bfd8
[ 240.578827] 0000000000015780 0000000000015780 ffff88011c7ce2e0 ffff88011c7ce5d8
[ 240.580502] Call Trace:
[ 240.581132] [<ffffffff8102cdac>] ? pvclock_clocksource_read+0x3a/0x8b
[ 240.582427] [<ffffffff8102cdac>] ? pvclock_clocksource_read+0x3a/0x8b
[ 240.583869] [<ffffffff810b3bdd>] ? sync_page+0x0/0x46
[ 240.585034] [<ffffffff810b3bdd>] ? sync_page+0x0/0x46
[ 240.586087] [<ffffffff812f9939>] ? io_schedule+0x73/0xb7
[ 240.587287] [<ffffffff810b3c1e>] ? sync_page+0x41/0x46
[ 240.588202] [<ffffffff812f9e46>] ? __wait_on_bit+0x41/0x70
[ 240.589314] [<ffffffff810b3da2>] ? wait_on_page_bit+0x6b/0x71
[ 240.590630] [<ffffffff81064a1c>] ? wake_bit_function+0x0/0x23
[ 240.591906] [<ffffffff810bb9ea>] ? pagevec_lookup_tag+0x1a/0x21
[ 240.592954] [<ffffffff810b4577>] ? wait_on_page_writeback_range+0x69/0x11b
[ 240.594403] [<ffffffff810b536e>] ? filemap_write_and_wait+0x26/0x32
[ 240.595563] [<ffffffffa02c0d35>] ? nfs_setattr+0xb9/0x117 [nfs]
[ 240.596670] [<ffffffff810b3a0b>] ? find_get_page+0x1a/0x77
[ 240.598012] [<ffffffff810b3bb9>] ? lock_page+0x9/0x1f
[ 240.598878] [<ffffffff810b41ee>] ? filemap_fault+0xb9/0x2f6
[ 240.599839] [<ffffffff810ca3c2>] ? __do_fault+0x38c/0x3c3
[ 240.601003] [<ffffffff810ee1ce>] ? do_sync_write+0xce/0x113
[ 240.602082] [<ffffffff81051e75>] ? current_fs_time+0x1e/0x24
[ 240.602968] [<ffffffff811009b7>] ? notify_change+0x180/0x2c5
[ 240.604245] [<ffffffff8110b7b5>] ? utimes_common+0x12d/0x14d
[ 240.605355] [<ffffffff8110b856>] ? do_utimes+0x81/0xca
[ 240.606558] [<ffffffff8110b9ab>] ? sys_utimensat+0x5b/0x6a
[ 240.607817] [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
[ 240.609124] INFO: task find:1866 blocked for more than 120 seconds.
[ 240.610409] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 240.612066] find D 0000000000000000 0 1866 1863 0x00000000
[ 240.613490] ffffffff8145d1f0 0000000000000086 0000000000000000 ffff88011e2d2350
[ 240.615188] 00000022b63d07c7 ffff88011c55e000 000000000000f9e0 ffff8800c78a5fd8
[ 240.616576] 0000000000015780 0000000000015780 ffff88011e2d2350 ffff88011e2d2648
[ 240.618297] Call Trace:
[ 240.618777] [<ffffffff810e5369>] ? virt_to_head_page+0x9/0x2a
[ 240.619906] [<ffffffff812fa07a>] ? __mutex_lock_common+0x122/0x192
[ 240.621324] [<ffffffff812fa1a2>] ? mutex_lock+0x1a/0x31
[ 240.622543] [<ffffffff81102c11>] ? mntput_no_expire+0x23/0xee
[ 240.623860] [<ffffffffa02c0b03>] ? nfs_getattr+0x3b/0xda [nfs]
[ 240.625219] [<ffffffff810f1839>] ? vfs_fstatat+0x43/0x57
[ 240.626290] [<ffffffff810f185e>] ? sys_newfstatat+0x11/0x30
[ 240.627594] [<ffffffff81102c11>] ? mntput_no_expire+0x23/0xee
[ 240.628768] [<ffffffff8101195b>] ? device_not_available+0x1b/0x20
[ 240.629644] [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
--
Leszek "Tygrys" Urbanski, SCSA, SCNA
"Unix-to-Unix Copy Program;" said PDP-1. "You will never find a more
wretched hive of bugs and flamers. We must be cautious." -- DECWARS
http://cygnus.moo.pl/ -- Cygnus High Altitude Balloon
^ permalink raw reply
* Re: [PATCH v11 17/17]add two new ioctls for mp device.
From: Ben Hutchings @ 2010-09-27 21:36 UTC (permalink / raw)
To: xiaohui.xin; +Cc: netdev, kvm, linux-kernel, mingo, davem, herbert, jdike
In-Reply-To: <b74412a16bc32fe2550461f25156e5b2563c5a2c.1285385607.git.xiaohui.xin@intel.com>
On Sat, 2010-09-25 at 12:27 +0800, xiaohui.xin@intel.com wrote:
> From: Xin Xiaohui <xiaohui.xin@intel.com>
>
> The patch add two ioctls for mp device.
> One is for userspace to query how much memory locked to make mp device
> run smoothly. Another one is for userspace to set how much meory locked
> it really wants.
[...]
> diff --git a/include/linux/mpassthru.h b/include/linux/mpassthru.h
> index ba8f320..083e9f7 100644
> --- a/include/linux/mpassthru.h
> +++ b/include/linux/mpassthru.h
> @@ -7,6 +7,8 @@
> /* ioctl defines */
> #define MPASSTHRU_BINDDEV _IOW('M', 213, int)
> #define MPASSTHRU_UNBINDDEV _IO('M', 214)
> +#define MPASSTHRU_SET_MEM_LOCKED _IOW('M', 215, unsigned long)
> +#define MPASSTHRU_GET_MEM_LOCKED_NEED _IOR('M', 216, unsigned long)
[...]
These will need compat handling. You can avoid that by defining them to
use a parameter type of u32 or u64.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next-2.6 16/17] tg3: Use netif_set_real_num_{rx,tx}_queues()
From: Matt Carlson @ 2010-09-27 21:41 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, netdev@vger.kernel.org,
linux-net-drivers@solarflare.com, Matthew Carlson, Michael Chan
In-Reply-To: <1285612357.2263.319.camel@achroite.uk.solarflarecom.com>
On Mon, Sep 27, 2010 at 11:32:37AM -0700, Ben Hutchings wrote:
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> This *always* sets real_num_tx_queues to 1, so this could be improved.
> For now, do a simple conversion.
>
> Ben.
>
> drivers/net/tg3.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index fdb438d..ca41140 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -8821,7 +8821,11 @@ static bool tg3_enable_msix(struct tg3 *tp)
> for (i = 0; i < tp->irq_max; i++)
> tp->napi[i].irq_vec = msix_ent[i].vector;
>
> - tp->dev->real_num_tx_queues = 1;
> + netif_set_real_num_tx_queues(tp->dev, 1);
> + if (netif_set_real_num_rx_queues(tp->dev, tp->irq_cnt)) {
This should be tp->irq_cnt - 1, not tp->irq_cnt. The first MSI-X vector
only handles link interrupts and device errors.
> + pci_disable_msix(tp->pdev);
> + return false;
> + }
> if (tp->irq_cnt > 1)
> tp->tg3_flags3 |= TG3_FLG3_ENABLE_RSS;
>
> @@ -8856,7 +8860,7 @@ defcfg:
> if (!(tp->tg3_flags2 & TG3_FLG2_USING_MSIX)) {
> tp->irq_cnt = 1;
> tp->napi[0].irq_vec = tp->pdev->irq;
> - tp->dev->real_num_tx_queues = 1;
> + netif_set_real_num_tx_queues(tp->dev, 1);
> }
> }
>
> --
> 1.7.2.1
>
>
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
^ permalink raw reply
* [PATCH] de2104x: fix ethtool
From: Ondrej Zary @ 2010-09-27 21:41 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Kernel development list
When the interface is up, using ethtool breaks it because:
a) link is put down but media_timer interval is not shortened to NO_LINK
b) rxtx is stopped but not restarted
Also manual 10baseT-HD (and probably FD too - untested) mode does not work -
the link is forced up, packets are transmitted but nothing is received.
Changing CSR14 value to match documentation (not disabling link check) fixes this.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.36-rc3-/drivers/net/tulip/de2104x.c 2010-09-26 21:58:42.000000000 +0200
+++ linux-2.6.36-rc3/drivers/net/tulip/de2104x.c 2010-09-27 23:36:51.000000000 +0200
@@ -364,9 +364,9 @@ static u16 t21040_csr15[] = { 0, 0, 0x00
/* 21041 transceiver register settings: TP AUTO, BNC, AUI, TP, TP FD*/
static u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
-static u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, };
+static u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x7F3F, 0x7F3D, };
/* If on-chip autonegotiation is broken, use half-duplex (FF3F) instead */
-static u16 t21041_csr14_brk[] = { 0xFF3F, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, };
+static u16 t21041_csr14_brk[] = { 0xFF3F, 0xF7FD, 0xF7FD, 0x7F3F, 0x7F3D, };
static u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, };
@@ -1596,12 +1596,15 @@ static int __de_set_settings(struct de_p
return 0; /* nothing to change */
de_link_down(de);
+ mod_timer(&de->media_timer, jiffies + DE_TIMER_NO_LINK);
de_stop_rxtx(de);
de->media_type = new_media;
de->media_lock = media_lock;
de->media_advertise = ecmd->advertising;
de_set_media(de);
+ if (netif_running(de->dev))
+ de_start_rxtx(de);
return 0;
}
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH net-next-2.6 16/17] tg3: Use netif_set_real_num_{rx,tx}_queues()
From: Matt Carlson @ 2010-09-27 21:44 UTC (permalink / raw)
To: Matt Carlson
Cc: Ben Hutchings, David Miller, netdev@vger.kernel.org,
linux-net-drivers@solarflare.com, Michael Chan
In-Reply-To: <20100927214107.GA32336@mcarlson.broadcom.com>
On Mon, Sep 27, 2010 at 02:41:07PM -0700, Matt Carlson wrote:
> On Mon, Sep 27, 2010 at 11:32:37AM -0700, Ben Hutchings wrote:
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > ---
> > This *always* sets real_num_tx_queues to 1, so this could be improved.
> > For now, do a simple conversion.
> >
> > Ben.
> >
> > drivers/net/tg3.c | 8 ++++++--
> > 1 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> > index fdb438d..ca41140 100644
> > --- a/drivers/net/tg3.c
> > +++ b/drivers/net/tg3.c
> > @@ -8821,7 +8821,11 @@ static bool tg3_enable_msix(struct tg3 *tp)
> > for (i = 0; i < tp->irq_max; i++)
> > tp->napi[i].irq_vec = msix_ent[i].vector;
> >
> > - tp->dev->real_num_tx_queues = 1;
> > + netif_set_real_num_tx_queues(tp->dev, 1);
> > + if (netif_set_real_num_rx_queues(tp->dev, tp->irq_cnt)) {
>
> This should be tp->irq_cnt - 1, not tp->irq_cnt. The first MSI-X vector
> only handles link interrupts and device errors.
I need to correct myself. If the irq_cnt > 1, then it needs to be
tp->irq_cnt - 1. If the irq_cnt == 1, then it should be 1.
> > + pci_disable_msix(tp->pdev);
> > + return false;
> > + }
> > if (tp->irq_cnt > 1)
> > tp->tg3_flags3 |= TG3_FLG3_ENABLE_RSS;
> >
> > @@ -8856,7 +8860,7 @@ defcfg:
> > if (!(tp->tg3_flags2 & TG3_FLG2_USING_MSIX)) {
> > tp->irq_cnt = 1;
> > tp->napi[0].irq_vec = tp->pdev->irq;
> > - tp->dev->real_num_tx_queues = 1;
> > + netif_set_real_num_tx_queues(tp->dev, 1);
> > }
> > }
> >
> > --
> > 1.7.2.1
> >
> >
> >
> > --
> > Ben Hutchings, Senior Software Engineer, Solarflare Communications
> > Not speaking for my employer; that's the marketing department's job.
> > They asked us to note that Solarflare product names are trademarked.
> >
> >
>
^ permalink raw reply
* Re: igmp: Allow mininum interval specification for igmp timers.
From: David Stevens @ 2010-09-27 21:45 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Miller, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, rda-x0S3BwdUo6DQT0dZR+AlfA
In-Reply-To: <alpine.DEB.2.00.1009271503420.14117-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote on 09/27/2010 01:20:54 PM:
>
> > As I said before, I think per protocol, back-to-back is both
> > allowed and not a problem, even if both subsequent randomized reports
> > come out to 0 time. But if we wanted to enforce a minimum interval
> > of, say, X, then I think the better way to do that is to set the
> > timer to X + rand(Interval-X) and not a table of fixed intervals
>
> The second patch sets the intervals to X .. X + Rand (interval) and not
to
> a table of fixed intervals as you state here. I have pointed this out
> before.
Sorry if I've misunderstood something you're proposing, but what
you describe above would be certainly technically incorrect. There are
really no circumstances for sending a report greater than <Interval>
that is protocol-compliant. You can enforce a minimum greater than 0,
which is a departure from both RFCs, though IGMPv2 uses wishy-washy
language. The intent for both was to explicitly allow 0, IMO.
>
> > as in the original patch. For v2, X=1 or 2 sec and Interval=10
> > might work well, but for v3, the entire interval is 1 sec and I
> > think I saw that the set-up time for the fabric may be on the
> > order of 1 sec.
>
> Again there is no knowledge about V2 or V3 without a query and this is
> during the period when no querier is known yet. You stated elsewhere
that
> I can assume V3 by default? So 1 sec?
Yes, without a querier or the tunable to force it to IGMPv2,
the default is IGMPv3. It appears there is a bug where IGMPv3 is also
using a 10sec interval (haven't verified that), but a 1 sec interval
as required makes your situation worse, not better. It makes it even
more likely that all the initial reports will occur before your set-up
is done.
> There can be any number of reasons that a short outage could prevent the
> packets from going through. A buffer overrun (that you mentioned
> elsewhere) usually causes lots of packets to be lost. Buffer overrun
> scenarios usually mean that all igmp queries are lost.
You're arguing against protocol compliance. I didn't define
the protocol, I only implemented it. And your view is through the
IB lens, but I don't believe this is an actual problem in any way
for typical networks. If you wrote a standards-track RFC that modifies
IGMP for NBMA networks that require a delay or different parameters
there, I'd have no objection to implementing that. Unilaterally
changing linux's behavior on all network types without cause for
departing from RFC on the most common types is another matter.
> There is no solution on the IB layer since there is no notification when
> the fabric reconfiguration necessary for an multicast group is complete.
Certainly that's not true; without notification, you can queue for
first use of a new hardware multicast address and send the queue after an
appropriate delay (1 sec? If that covers your set-up time). If you had
positive acknowledgement from the IB network, you'd know exactly when to
do it, but there's no need to change anything for non-IB networks here.
> The querier is of not use since (for the gazillionth of times) this is
an
> unsolicited IGMP report. If there is a querier then the unsolicited igmp
> reports would not be used but the timeout indicated by the querier would
> be used.
A querier affects unsolicited reports because it sets both the
query interval and the robustness value. If you want to send 10 reports,
you can cause that by having a querier that sets it to that many. The
initial join would then send 10 reports and the query interval can also
be as low as you like.
But the linux code is not just for your particular problem or
particular configuration. You can solve your problem by adding a querier,
but I know you're trying to do it without. The mail I was responding to
referred also to the case of a querier present, which is actually the
"normal" case for using full IGMP is. I'm saying that for the non-querier
case, making those per-interface configurable is reasonable because
they *are* querier-changeable, but you can also use a querier to change
it _for_the_unsolicited_reports_, as well as making the querier interval
small enough that you don't have to care at all whether any or all of
the unsolicited reports are lost.
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] xmit_compl_seq: information to reclaim vmsplice buffers
From: Tom Herbert @ 2010-09-27 21:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Michael S. Tsirkin, netdev, davem, sridharr
In-Reply-To: <1285614757.2512.6.camel@edumazet-laptop>
> Alternative would be to copy data on retransmits, for tcp sockets using
> SOCK_XMIT_COMPL_SEQ. (ie not using skb_clone but skb_copy())
>
That's coming awfully close to COW! ;-)
>
>
>
>
^ permalink raw reply
* Re:
From: David Stevens @ 2010-09-27 21:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <alpine.DEB.2.00.1009271521510.14117-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote on 09/27/2010 01:23:00 PM:
> From: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
> To: David Stevens/Beaverton/IBM@IBMUS
> Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>, linux-
> rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bob Arendt <rda-x0S3BwdUo6DQT0dZR+AlfA@public.gmane.org>
> Date: 09/27/2010 01:23 PM
> Subject: Re:
>
> On Mon, 27 Sep 2010, David Stevens wrote:
>
> > Because a querier can set the robustness value and
> > query interval to anything you want. In the original report,
> > he's not running a querier. The fact that it's a new group
> > doesn't matter -- these are per-interface.
>
> The per interface settings are used to force an IGMP version overriding
> any information by the queriers.
No. I'm not talking about the force_igmp_tunable here, I'm talking
about the per-interface robustness and interval settings which come from
the querier (whatever version you are using).
> You would not want to enable that because
> it disables support for other IGMP versions. Without the override
> different version of IGMP can be handled per MC group.
No. IGMPv3 includes backward compatibility for both IGMPv2 and
IGMPv1. If queries for an earlier version are present, that is the
IGMP version all use, and the features of the later version are not
available to anyone.
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] fix TSO FACK loss marking in tcp_mark_head_lost
From: David Miller @ 2010-09-27 21:56 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: ycheng, netdev
In-Reply-To: <alpine.DEB.2.00.1009272155030.15680@melkinpaasi.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 27 Sep 2010 22:20:57 +0300 (EEST)
> I disagree now with myself btw, it's not just "a policy decision" as we
> do not retransmit some segments at all before RTO in some scenarios.
Ok, thanks for explaining all of this.
I've applied Yuchung's patch to net-2.6, thanks everyone!
^ permalink raw reply
* Re:
From: David Stevens @ 2010-09-27 22:01 UTC (permalink / raw)
To: Bob Arendt
Cc: Christoph Lameter, Jason Gunthorpe, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, netdev-owner@vger.kernel.org
In-Reply-To: <4CA1048C.8020508@rincon.com>
Bob Arendt <rda@rincon.com> wrote on 09/27/2010 01:54:36 PM:
> On 09/27/10 13:23, Christoph Lameter wrote:
> > On Mon, 27 Sep 2010, David Stevens wrote:
> >
> >> Because a querier can set the robustness value and
> >> query interval to anything you want. In the original report,
> >> he's not running a querier. The fact that it's a new group
> >> doesn't matter -- these are per-interface.
> >
> > The per interface settings are used to force an IGMP version
overriding
> > any information by the queriers. You would not want to enable that
because
> > it disables support for other IGMP versions. Without the override
> > different version of IGMP can be handled per MC group.
> >
> If a network vlan has IGMPv3 capability, then it should be able
> to support both v2 and v3 Joins (clients). But if the vlan is
> IGMPv2 only, then an initial Join from a Linux client might go out
> as v3 (if it hasn't seen a query yet) and be ignored. I believe
> this is the case that force_igmp_version really addresses.
Not really. It's for the case where there is no querier at all,
but a snooping switch that only supports IGMPv2. After any query has
put an interface in IGMPv2 mode (or IGMPv1), the initial report for
all joins will use the earlier protocol. It isn't per-group, it's
per interface, and you cannot mix versions of IGMP on the same network.
>
> And it turns out that force_igmp_version=2 doesn't fully work.
> If the host sees a IGMPv3 query, it still responds with a v3 Join
> despite the flag. Bug report and candidate patch here:
> https://bugzilla.kernel.org/show_bug.cgi?id=18212
This is a special case. The "correct" alternative is to drop
the query and not send any report at all. Sending an answer in the
originating protocol doesn't hurt anything here, because MC routers
are required to use the earlier version too; there should be no such
thing as an "IGMPv3-only querier" as in that report. IGMPv3 compliance
*requires* falling back to IGMPv2 if there is a v2 query by another
router.
By answering instead of dropping, it allows fuller filter
information from a manual query to be returned even if the network
is using v2 MC routers, but dropping and ignoring the query as
required by RFC does not fix the bug & patch submitter's problem.
Which is why I also NACKed that patch.
+-DLS
^ permalink raw reply
* Re: [PATCH] tproxy: check for transparent flag in ip_route_newports
From: David Miller @ 2010-09-27 22:03 UTC (permalink / raw)
To: uweber; +Cc: netdev
In-Reply-To: <20100927133100.GB8916@babylon>
From: Ulrich Weber <uweber@astaro.com>
Date: Mon, 27 Sep 2010 15:31:00 +0200
> as done in ip_route_connect()
>
> Signed-off-by: Ulrich Weber <uweber@astaro.com>
Applied, thanks for fixing this.
^ permalink raw reply
* Re: [GIT PULL net-2.6] vhost-net: last minute fix
From: David Miller @ 2010-09-27 22:04 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20100927133411.GA4033@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 27 Sep 2010 15:34:13 +0200
> The following tree includes a last minute bugfix for vhost-net.
> It is on top of net-2.6. Please merge it for 2.6.36.
Pulled, thanks Michael.
^ permalink raw reply
* Re: [PATCH] de2104x: fix ethtool
From: Jeff Garzik @ 2010-09-27 22:05 UTC (permalink / raw)
To: Ondrej Zary; +Cc: netdev, Kernel development list
In-Reply-To: <201009272341.50668.linux@rainbow-software.org>
On 09/27/2010 05:41 PM, Ondrej Zary wrote:
> When the interface is up, using ethtool breaks it because:
> a) link is put down but media_timer interval is not shortened to NO_LINK
> b) rxtx is stopped but not restarted
>
> Also manual 10baseT-HD (and probably FD too - untested) mode does not work -
> the link is forced up, packets are transmitted but nothing is received.
> Changing CSR14 value to match documentation (not disabling link check) fixes this.
>
> Signed-off-by: Ondrej Zary<linux@rainbow-software.org>
Acked-by: Jeff Garzik <jgarzik@redhat.com>
Good catch on the missing de_start_rxtx()
^ permalink raw reply
* Re: [stable 2.6.32] instant crash (jump to NULL) with virtio-net, tap, bridge and veth
From: Michael Tokarev @ 2010-09-27 22:18 UTC (permalink / raw)
To: Kernel Mailing List, netdev, kvm-devel
In-Reply-To: <4C753BC0.6010803@msgid.tls.msk.ru>
Replying to my own, quite old (more than a month old)
email, and top-posting as well.
I had a chance finally to try another theory with this
problem -- the suspect this time was stack overflow.
And indeed it looks like the case. I can disable
the bridge hooks in /proc/sys/net/bridge/, and the
system works just fine (in the backtraces we can
see ip_rcv_finish() and ip_rcv() calls, which are
in the NF_HOOK macro).
So, by disabling all nf hooks the problem goes away.
After enabling them again the kernel crashes again
as before.
Since this is our production host, I wont do more
tests in a near future, leaving the nf hooks disabled.
Thanks for listening!
/mjt
25.08.2010 19:50, Michael Tokarev wrote:
> Hello.
>
> I'm seeing instant host kernel crash triggered by _any_
> network activity to/from a kvm guest that's using virtio-net.
>
> My setup is maybe a bit unusual, but here we go.
>
> I've a host machine that has one bridge configured,
> and is running a few kvm virtual machines and a few
> linux containers (LXC). All the guests/containers
> are "connected" to that single bridge - guests using
> tap devices, lxc containers using veth devices. Host
> eth0 is connected to the same bridge as well.
>
> The problem happens with virtio-net drivers used in
> guest (this is windowsXP virtual machine with latest
> netkvm driver from alt.fedoraproject.org), when I
> connect to that guest from an LXC container. I.e,
> when packet goes lxc => veth => bridge => tun =>
> kvm => virtio in guest (or back).
>
> When I connect to the same guest from _host_, it all
> works as expected. When I change (virtual) NIC in
> guest to e1000 or older (from 2009) virtio-net driver,
> it works. When I connect from lxc container to a
> linux guest with latest virtio-net drivers, it all
> works as expected too. So only one combination so
> far that triggers the issue.
>
> This is all with 2.6.32 kernel. Initially it was
> 2.6.32.15, but 2.6.32.20 behaves the same way too.
> All 64bit.
>
> Also it does NOT happen with 2.6.35.3, the current
> latest released kernel.
>
> Here's one of captured OOPSes (i did it several
> times, but they were incomplete):
>
> console [netcon0] enabled
> netconsole: network logging started
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<(null)>] (null)
> PGD 177bf2067 PUD 177ae5067 PMD 0
> Oops: 0010 [#1] SMP
> last sysfs file: /sys/devices/virtual/block/md8/md/mismatch_cnt
> CPU 0
> Modules linked in: netconsole configfs squashfs kvm_amd kvm veth autofs4 bridge quota_v2 quota_tree ext4 jbd2 crc16 raid0 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx loop sr_mod cdrom tun powernow_k8 processor thermal_sys 8021q garp stp llc asus_atk0110 hwmon atl1 mii ext3 jbd mbcache raid1 md_mod pata_atiixp ehci_hcd ohci_hcd usbcore nls_base ahci libata sd_mod scsi_mod
> Pid: 2345, comm: kvm Not tainted 2.6.32-amd64 #2.6.32.20 System Product Name
> RIP: 0010:[<0000000000000000>] [<(null)>] (null)
> RSP: 0018:ffff880028203e70 EFLAGS: 00010293
> RAX: ffff880179480ec0 RBX: ffff8801a07770c0 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffff8801a07770c0 RDI: ffff8801a07770c0
> RBP: ffff880124b89030 R08: ffffffff8125fab0 R09: ffff880028203e40
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880028210888
> R13: ffff880028210880 R14: 000000010000e60f R15: 0000000000000040
> FS: 00007fe2da5e5700(0000) GS:ffff880028200000(0000) knlGS:00000000f74a59d0
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000177a8a000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process kvm64 (pid: 2345, threadinfo ffff880177be2000, task ffff880177a7c0c0)
> Stack:
> ffffffff8125fbd5 0000000000000040 ffffffff8126013c 0000000080000000
> <0> ffff8800282108b8 0000000000000002 ffff880028210888 ffff880028210880
> <0> ffffffff81236276 ffff880028203f48 ffff8800282108b8 0000000000000000
> Call Trace:
> <IRQ>
> [<ffffffff8125fbd5>] ? ip_rcv_finish+0x125/0x430
> [<ffffffff8126013c>] ? ip_rcv+0x25c/0x350
> [<ffffffff81236276>] ? process_backlog+0x76/0xd0
> [<ffffffff81236a18>] ? net_rx_action+0xf8/0x1f0
> [<ffffffff81059120>] ? __do_softirq+0xb0/0x1d0
> [<ffffffff8100c56c>] ? call_softirq+0x1c/0x30
> <EOI>
> [<ffffffff8100e595>] ? do_softirq+0x65/0xa0
> [<ffffffff81236b2e>] ? netif_rx_ni+0x1e/0x30
> [<ffffffffa014e97a>] ? tun_chr_aio_write+0x35a/0x510 [tun]
> [<ffffffffa014e620>] ? tun_chr_aio_write+0x0/0x510 [tun]
> [<ffffffff810ffea4>] ? do_sync_readv_writev+0xd4/0x110
> [<ffffffff8106e890>] ? autoremove_wake_function+0x0/0x30
> [<ffffffff81071709>] ? enqueue_hrtimer+0x79/0xc0
> [<ffffffff810ffd08>] ? rw_copy_check_uvector+0x88/0x110
> [<ffffffff811005bc>] ? do_readv_writev+0xdc/0x220
> [<ffffffff8106dafc>] ? sys_timer_settime+0x13c/0x2e0
> [<ffffffff8110084e>] ? sys_writev+0x4e/0x90
> [<ffffffff8100b482>] ? system_call_fastpath+0x16/0x1b
> Code: Bad RIP value.
> RIP [<(null)>] (null)
> RSP <ffff880028203e70>
> CR2: 0000000000000000
> ---[ end trace 1dcd3c52bde0fa25 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> Pid: 2345, comm: kvm Tainted: G D 2.6.32-amd64 #2.6.32.20
> Call Trace:
> <IRQ> [<ffffffff812c22de>] ? panic+0x7a/0x134
> [<ffffffff812c23d8>] ? printk+0x40/0x48
> [<ffffffff8100faa3>] ? oops_end+0xa3/0xb0
> [<ffffffff8103138a>] ? no_context+0xfa/0x260
> [<ffffffff812c52a5>] ? page_fault+0x25/0x30
> [<ffffffff8125fab0>] ? ip_rcv_finish+0x0/0x430
> [<ffffffff8125fbd5>] ? ip_rcv_finish+0x125/0x430
> [<ffffffff8126013c>] ? ip_rcv+0x25c/0x350
> [<ffffffff81236276>] ? process_backlog+0x76/0xd0
> [<ffffffff81236a18>] ? net_rx_action+0xf8/0x1f0
> [<ffffffff81059120>] ? __do_softirq+0xb0/0x1d0
> [<ffffffff8100c56c>] ? call_softirq+0x1c/0x30
> <EOI> [<ffffffff8100e595>] ? do_softirq+0x65/0xa0
> [<ffffffff81236b2e>] ? netif_rx_ni+0x1e/0x30
> [<ffffffffa014e97a>] ? tun_chr_aio_write+0x35a/0x510 [tun]
> [<ffffffffa014e620>] ? tun_chr_aio_write+0x0/0x510 [tun]
> [<ffffffff810ffea4>] ? do_sync_readv_writev+0xd4/0x110
> [<ffffffff8106e890>] ? autoremove_wake_function+0x0/0x30
> [<ffffffff81071709>] ? enqueue_hrtimer+0x79/0xc0
> [<ffffffff810ffd08>] ? rw_copy_check_uvector+0x88/0x110
> [<ffffffff811005bc>] ? do_readv_writev+0xdc/0x220
> [<ffffffff8106dafc>] ? sys_timer_settime+0x13c/0x2e0
> [<ffffffff8110084e>] ? sys_writev+0x4e/0x90
> [<ffffffff8100b482>] ? system_call_fastpath+0x16/0x1b
> Rebooting in 60 seconds..
>
>
> Another:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<(null)>] (null)
> PGD 10c804067 PUD 212d0e067 PMD 0
> Oops: 0010 [#1] SMP
> last sysfs file: /sys/devices/virtual/vc/vcsa2/dev
> CPU 0
> Modules linked in: netconsole configfs squashfs kvm_amd kvm veth autofs4 bridge quota_v2 quota_tree ext4 jbd2 crc16 raid0 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx loop sr_mod cdrom tun powernow_k8 processor thermal_sys 8021q garp stp llc asus_atk0110 hwmon atl1 mii ext3 jbd mbcache raid1 md_mod pata_atiixp ehci_hcd ohci_hcd usbcore nls_base [<ffffffff8100bff3>] ? apic_timer_interrupt+0x13/0x20
> [<ffffffff8100fced>] ? oops_end+0x9d/0xb0
> [<ffffffff810320b7>] ? no_context+0xf7/0x260
> [<ffffffff81032375>] ? __bad_area_nosemaphore+0x155/0x230
> [<ffffffffa0273ea0>] ? br_nf_pre_routing_finish+0x0/0x350 [bridge]
> [<ffffffffa0274759>] ? br_nf_pre_routing+0x569/0x880 [bridge]
> [<ffffffff812cc945>] ? page_fault+0x25/0x30
> [<ffffffff812650a0>] ? ip_rcv+0x0/0x350
> [<ffffffff81264c60>] ? ip_rcv_finish+0x0/0x440
> [<ffffffff81264e19>] ? ip_rcv_finish+0x1b9/0x440
> [<ffffffff81265354>] ? ip_rcv+0x2b4/0x350
> [<ffffffff8123ba85>] ? process_backlog+0x75/0xc0
> [<ffffffff8123c246>] ? net_rx_action+0x106/0x220
> [<ffffffff8105abcb>] ? __do_softirq+0xfb/0x1d0
> [<ffffffff8100c62c>] ? call_softirq+0x1c/0x30
> <EOI> [<ffffffff8100e765>] ? do_softirq+0x65/0xa0
> [<ffffffff8123c379>] ? netif_rx_ni+0x19/0x20
> [<ffffffffa0151b0b>] ? tun_chr_aio_write+0x3fb/0x550 [tun]
> [<ffffffffa0151710>] ? tun_chr_aio_write+0x0/0x550 [tun]
> [<ffffffff811031fb>] ? do_sync_readv_writev+0xcb/0x110
> [<ffffffff81065941>] ? __dequeue_signal+0xe1/0x210
> [<ffffffff810706b0>] ? autoremove_wake_function+0x0/0x30
> [<ffffffff81012bc2>] ? read_tsc+0x12/0x40
> [<ffffffff81024608>] ? lapic_next_event+0x18/0x20
> [<ffffffff8107d156>] ? tick_dev_program_event+0x36/0xb0
> [<ffffffff81103036>] ? rw_copy_check_uvector+0x86/0x130
> [<ffffffff81103912>] ? do_readv_writev+0xe2/0x230
> [<ffffffff8106f883>] ? sys_timer_settime+0x153/0x350
> [<ffffffff81103bb3>] ? sys_writev+0x53/0xa0
> [<ffffffff8100b542>] ? system_call_fastpath+0x16/0x1b
> Rebooting in 60 seconds..
>
> I looked at the changes in tun, virtio-net, bridge code and
> veth between 2.6.32 and 2.6.35, but I see nothing relevant
> in there (but I'm not an expert in that area anyway). The
> changes mentions a few crashes, but all were related to
> device registration/deregistration or module unload, not
> to normal send/receive path.
>
> It will be really nice to fix this for long-stable 2.6.32
> series... ;)
>
> Thanks!
>
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] de2104x: fix ethtool
From: David Miller @ 2010-09-27 22:40 UTC (permalink / raw)
To: jgarzik; +Cc: linux, netdev, linux-kernel
In-Reply-To: <4CA11546.8@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Mon, 27 Sep 2010 18:05:58 -0400
> On 09/27/2010 05:41 PM, Ondrej Zary wrote:
>> When the interface is up, using ethtool breaks it because:
>> a) link is put down but media_timer interval is not shortened to
>> NO_LINK
>> b) rxtx is stopped but not restarted
>>
>> Also manual 10baseT-HD (and probably FD too - untested) mode does not
>> work -
>> the link is forced up, packets are transmitted but nothing is
>> received.
>> Changing CSR14 value to match documentation (not disabling link check)
>> fixes this.
>>
>> Signed-off-by: Ondrej Zary<linux@rainbow-software.org>
>
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
>
> Good catch on the missing de_start_rxtx()
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net/9p: Mount only matching virtio channels
From: David Miller @ 2010-09-27 22:54 UTC (permalink / raw)
To: sven.eckelmann; +Cc: ericvh, netdev, linux-kernel
In-Reply-To: <1285514893-11233-1-git-send-email-sven.eckelmann@gmx.de>
From: Sven Eckelmann <sven.eckelmann@gmx.de>
Date: Sun, 26 Sep 2010 17:28:13 +0200
> p9_virtio_create will only compare the the channel's tag characters
> against the device name till the end of the channel's tag but not till
> the end of the device name. This means that if a user defines channels
> with the tags foo and foobar then he would mount foo when he requested
> foonot and may mount foo when he requested foobar.
>
> Thus it is necessary to check both string lengths against each other in
> case of a successful partial string match.
>
> Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
I'll apply this, but this code would be so much simpler and this bug
would have never happened if these tags were NULL terminated when they
were pulled in from virtio.
^ 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