* Hello!
From: prisca koroma @ 2013-02-26 2:21 UTC (permalink / raw)
Hello!
Hapy new year i come across your profile today and picked
interest in you, My name is Miss Prisca. I wish to be in good relationship with
you.
Please if you feel interested write me through the contact so i will send you
my pictures and for us to know each other more better,
I will be happy to seeing a good responds from you
Prisca
^ permalink raw reply
* Re: [RFC/RFT 00/27] Updates for the rtlwifi family of drivers
From: Larry Finger @ 2013-02-26 3:04 UTC (permalink / raw)
To: Joe Perches; +Cc: linville, linux-wireless, netdev, jcheung, machen, mmarek
In-Reply-To: <1361845357.2023.7.camel@joe-AO722>
On 02/25/2013 08:22 PM, Joe Perches wrote:
> On Mon, 2013-02-25 at 18:13 -0600, Larry Finger wrote:
>> This set of patches upgrades drivers rtlwifi, rtl8192c, rtl8192ce, rtl8192se,
>> and rtl8723ae to the state of the vendor driver issued on 2013.02.07. In
>> addition, a new driver for the RTL8188EE chip is added to the kernel.
>>
>> Note: These patches do not upgrade rtl8192de. Those changes will be sent
>> later.
>
> rtl8188e isn't very kernel stylish.
> Looking at it briefly, in fact it's kind of ugly.
>
> Could/should it go into staging?
It is uglier than I had hoped. I was not quite ready to push it yet, but I got
some pressure from outside, non-Realtek, sources that a kernel version was
needed. They will, in fact, start their integration from the RFC/RFT version.
The main problem with having it in staging is that we will either have to
include headers from drivers/net/wireless/rtlwifi/, or duplicate them in the
drivers/staging/rtl8188ee/ directory where keeping them compatible will be a
hassle. Neither solution sounds optimum to me.
Larry
^ permalink raw reply
* Re: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen network driver
From: ANNIE LI @ 2013-02-26 3:07 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, netdev, ian.campbell, konrad.wilk
In-Reply-To: <1360944010-15336-1-git-send-email-wei.liu2@citrix.com>
What the version are these patches based on?
I tried v3.8-rc7 and 3.8-rc6, patch 3/8, 4/8 ... can not be merged
successfully. Can you rebase it?
Thanks
Annie
On 2013-2-16 0:00, Wei Liu wrote:
> This patch series contains a small fix plus mechanical works for xen network
> driver.
>
> * bug fix: don't bind kthread to specific cpu core
> * allow host admin to unload netback
> * multi-page ring support
> * split event channels support
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [RFC/RFT 00/27] Updates for the rtlwifi family of drivers
From: Joe Perches @ 2013-02-26 3:26 UTC (permalink / raw)
To: Larry Finger
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, jcheung-IBi9RG/b67k,
machen-IBi9RG/b67k, mmarek-AlSwsSmVLrQ
In-Reply-To: <512C264A.3000104-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Mon, 2013-02-25 at 21:04 -0600, Larry Finger wrote:
> On 02/25/2013 08:22 PM, Joe Perches wrote:
> > On Mon, 2013-02-25 at 18:13 -0600, Larry Finger wrote:
> >> This set of patches upgrades drivers rtlwifi, rtl8192c, rtl8192ce, rtl8192se,
> >> and rtl8723ae to the state of the vendor driver issued on 2013.02.07. In
> >> addition, a new driver for the RTL8188EE chip is added to the kernel.
> >>
> >> Note: These patches do not upgrade rtl8192de. Those changes will be sent
> >> later.
> >
> > rtl8188e isn't very kernel stylish.
> > Looking at it briefly, in fact it's kind of ugly.
> >
> > Could/should it go into staging?
>
> It is uglier than I had hoped. I was not quite ready to push it yet, but I got
> some pressure from outside, non-Realtek, sources that a kernel version was
> needed. They will, in fact, start their integration from the RFC/RFT version.
>
> The main problem with having it in staging is that we will either have to
> include headers from drivers/net/wireless/rtlwifi/, or duplicate them in the
> drivers/staging/rtl8188ee/ directory where keeping them compatible will be a
> hassle. Neither solution sounds optimum to me.
Perhaps adding a CFLAGS -I include path to a staging Makefile
would work instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* (unknown)
From: FIRST KEYSTONE @ 2013-02-26 4:15 UTC (permalink / raw)
Do You Need a Loan? Reply us with Your Loan Requirements.
^ permalink raw reply
* Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle
From: Greg Kroah-Hartman @ 2013-02-26 4:23 UTC (permalink / raw)
To: Glen Turner
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1361852232.23197.4.camel-MFjF70HZCXOiAIzqYCf0vryL0Hf3YRqg06D/hhiQN/qHXe+LvDLADg@public.gmane.org>
On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
> This USB ethernet adapter was purchased in anodyne packaging
> marked "USB2.0 to LAN" from the computer store adjacent to
> linux.conf.au 2013 in Canberra (Australia). A web search
> shows other recent purchasers in Lancaster (UK) and Seattle
> (USA). Just like an emergent virus, our age of e-commerce and
> airmail allows underdocumented hardware to spread around the
> world instantly using the vector of ridiculously low prices.
>
> Paige Thompson, infected via eBay, discovered that the HG20F9
> is a copy of the Asix 88772B; many viruses copy the RNA of
> other viruses. See Paige's work at
> <https://github.com/paigeadele/HG20F9>.
> This patch uses her discovery to update the restructured Asix
> driver in the current kernel.
>
> The spread of viruses is often accompanied by rumours. It is
> rumoured that the HG20F9 has extensions to to provide gigabit
> ethernet. This patch does not chase that chimera.
>
> Just as some viruses inhabit seemingly-healthy cells, the
> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> For the present there is no clash of Product ID 0x20f9.
>
> Signed-off-by: Glen Turner <gdt-pRLresKaOUyHXe+LvDLADg@public.gmane.org>
That is the best "add a new device id" changelog entry I have _ever_
seen. Wonderful job:
Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle
From: David Miller @ 2013-02-26 4:45 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: gdt-pRLresKaOUyHXe+LvDLADg, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130226042343.GA27766-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Date: Mon, 25 Feb 2013 20:23:43 -0800
> On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
>> This USB ethernet adapter was purchased in anodyne packaging
>> marked "USB2.0 to LAN" from the computer store adjacent to
>> linux.conf.au 2013 in Canberra (Australia). A web search
>> shows other recent purchasers in Lancaster (UK) and Seattle
>> (USA). Just like an emergent virus, our age of e-commerce and
>> airmail allows underdocumented hardware to spread around the
>> world instantly using the vector of ridiculously low prices.
>>
>> Paige Thompson, infected via eBay, discovered that the HG20F9
>> is a copy of the Asix 88772B; many viruses copy the RNA of
>> other viruses. See Paige's work at
>> <https://github.com/paigeadele/HG20F9>.
>> This patch uses her discovery to update the restructured Asix
>> driver in the current kernel.
>>
>> The spread of viruses is often accompanied by rumours. It is
>> rumoured that the HG20F9 has extensions to to provide gigabit
>> ethernet. This patch does not chase that chimera.
>>
>> Just as some viruses inhabit seemingly-healthy cells, the
>> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
>> For the present there is no clash of Product ID 0x20f9.
>>
>> Signed-off-by: Glen Turner <gdt-pRLresKaOUyHXe+LvDLADg@public.gmane.org>
>
> That is the best "add a new device id" changelog entry I have _ever_
> seen. Wonderful job:
>
> Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Was this patch really submitted properly to netdev? I can't
find it in patchwork at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle
From: Greg KH @ 2013-02-26 5:03 UTC (permalink / raw)
To: David Miller
Cc: gdt-pRLresKaOUyHXe+LvDLADg, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130225.234529.1601978289377551611.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote:
> From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> Date: Mon, 25 Feb 2013 20:23:43 -0800
>
> > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
> >> This USB ethernet adapter was purchased in anodyne packaging
> >> marked "USB2.0 to LAN" from the computer store adjacent to
> >> linux.conf.au 2013 in Canberra (Australia). A web search
> >> shows other recent purchasers in Lancaster (UK) and Seattle
> >> (USA). Just like an emergent virus, our age of e-commerce and
> >> airmail allows underdocumented hardware to spread around the
> >> world instantly using the vector of ridiculously low prices.
> >>
> >> Paige Thompson, infected via eBay, discovered that the HG20F9
> >> is a copy of the Asix 88772B; many viruses copy the RNA of
> >> other viruses. See Paige's work at
> >> <https://github.com/paigeadele/HG20F9>.
> >> This patch uses her discovery to update the restructured Asix
> >> driver in the current kernel.
> >>
> >> The spread of viruses is often accompanied by rumours. It is
> >> rumoured that the HG20F9 has extensions to to provide gigabit
> >> ethernet. This patch does not chase that chimera.
> >>
> >> Just as some viruses inhabit seemingly-healthy cells, the
> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> >> For the present there is no clash of Product ID 0x20f9.
> >>
> >> Signed-off-by: Glen Turner <gdt-pRLresKaOUyHXe+LvDLADg@public.gmane.org>
> >
> > That is the best "add a new device id" changelog entry I have _ever_
> > seen. Wonderful job:
> >
> > Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>
> Was this patch really submitted properly to netdev? I can't
> find it in patchwork at all.
It was Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org with Message-ID:
<1361852232.23197.4.camel-MFjF70HZCXOiAIzqYCf0vryL0Hf3YRqg06D/hhiQN/qHXe+LvDLADg@public.gmane.org> so it
should have gone through there somehow.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle
From: David Miller @ 2013-02-26 5:10 UTC (permalink / raw)
To: gregkh; +Cc: gdt, linux-usb, netdev, linux-kernel
In-Reply-To: <20130226050311.GB21390@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Mon, 25 Feb 2013 21:03:11 -0800
> On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote:
>> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Date: Mon, 25 Feb 2013 20:23:43 -0800
>>
>> > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
>> >> This USB ethernet adapter was purchased in anodyne packaging
>> >> marked "USB2.0 to LAN" from the computer store adjacent to
>> >> linux.conf.au 2013 in Canberra (Australia). A web search
>> >> shows other recent purchasers in Lancaster (UK) and Seattle
>> >> (USA). Just like an emergent virus, our age of e-commerce and
>> >> airmail allows underdocumented hardware to spread around the
>> >> world instantly using the vector of ridiculously low prices.
>> >>
>> >> Paige Thompson, infected via eBay, discovered that the HG20F9
>> >> is a copy of the Asix 88772B; many viruses copy the RNA of
>> >> other viruses. See Paige's work at
>> >> <https://github.com/paigeadele/HG20F9>.
>> >> This patch uses her discovery to update the restructured Asix
>> >> driver in the current kernel.
>> >>
>> >> The spread of viruses is often accompanied by rumours. It is
>> >> rumoured that the HG20F9 has extensions to to provide gigabit
>> >> ethernet. This patch does not chase that chimera.
>> >>
>> >> Just as some viruses inhabit seemingly-healthy cells, the
>> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
>> >> For the present there is no clash of Product ID 0x20f9.
>> >>
>> >> Signed-off-by: Glen Turner <gdt@gdt.id.au>
>> >
>> > That is the best "add a new device id" changelog entry I have _ever_
>> > seen. Wonderful job:
>> >
>> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Was this patch really submitted properly to netdev? I can't
>> find it in patchwork at all.
>
> It was Cc: netdev@vger.kernel.org with Message-ID:
> <1361852232.23197.4.camel@andromache.adelaide.aarnet.edu.au> so it
> should have gone through there somehow.
Nope:
http://marc.info/?t=136185267100001&r=1&w=2
It didn't make it to any of the lists, that's why you are the
only person who saw the original patch.
^ permalink raw reply
* [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle
From: Glen Turner @ 2013-02-26 4:17 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb, netdev, linux-kernel
This USB ethernet adapter was purchased in anodyne packaging
marked "USB2.0 to LAN" from the computer store adjacent to
linux.conf.au 2013 in Canberra (Australia). A web search
shows other recent purchasers in Lancaster (UK) and Seattle
(USA). Just like an emergent virus, our age of e-commerce and
airmail allows underdocumented hardware to spread around the
world instantly using the vector of ridiculously low prices.
Paige Thompson, infected via eBay, discovered that the HG20F9
is a copy of the Asix 88772B; many viruses copy the RNA of
other viruses. See Paige's work at
<https://github.com/paigeadele/HG20F9>.
This patch uses her discovery to update the restructured Asix
driver in the current kernel.
The spread of viruses is often accompanied by rumours. It is
rumoured that the HG20F9 has extensions to to provide gigabit
ethernet. This patch does not chase that chimera.
Just as some viruses inhabit seemingly-healthy cells, the
HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
For the present there is no clash of Product ID 0x20f9.
Signed-off-by: Glen Turner <gdt@gdt.id.au>
---
drivers/net/usb/asix_devices.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 7a6e758..649025d 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -883,6 +883,24 @@ static const struct driver_info ax88178_info = {
.tx_fixup = asix_tx_fixup,
};
+// USBLINK 20F9 "USB 2.0 LAN" USB ethernet adapter, typically found in
+// no-name packaging.
+// USB device strings are:
+// 1: Manufacturer: USBLINK
+// 2: Product: HG20F9 USB2.0
+// 3: Serial: 000003
+// Appears to be compatible with Asix 88772B.
+static const struct driver_info hg20f9_info = {
+ .description = "HG20F9 USB 2.0 Ethernet",
+ .bind = ax88772_bind,
+ .status = asix_status,
+ .link_reset = ax88772_link_reset,
+ .reset = ax88772_reset,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_LINK_INTR | FLAG_MULTI_PACKET,
+ .rx_fixup = asix_rx_fixup,
+ .tx_fixup = asix_tx_fixup,
+};
+
extern const struct driver_info ax88172a_info;
static const struct usb_device_id products [] = {
@@ -1022,6 +1040,12 @@ static const struct usb_device_id products [] = {
/* ASIX 88172a demo board */
USB_DEVICE(0x0b95, 0x172a),
.driver_info = (unsigned long) &ax88172a_info,
+}, {
+ // USBLINK HG20F9 "USB 2.0 LAN"
+ // Appears to have gazumped Linksys's manufacturer ID but
+ // doesn't (yet) conflict with any known Linksys product.
+ USB_DEVICE(0x066b, 0x20f9),
+ .driver_info = (unsigned long) &hg20f9_info,
},
{ }, // END
};
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle
From: Greg KH @ 2013-02-26 5:20 UTC (permalink / raw)
To: David Miller; +Cc: gdt, linux-usb, netdev, linux-kernel
In-Reply-To: <20130226.001022.1341620780921182778.davem@davemloft.net>
On Tue, Feb 26, 2013 at 12:10:22AM -0500, David Miller wrote:
> From: Greg KH <gregkh@linuxfoundation.org>
> Date: Mon, 25 Feb 2013 21:03:11 -0800
>
> > On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote:
> >> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Date: Mon, 25 Feb 2013 20:23:43 -0800
> >>
> >> > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote:
> >> >> This USB ethernet adapter was purchased in anodyne packaging
> >> >> marked "USB2.0 to LAN" from the computer store adjacent to
> >> >> linux.conf.au 2013 in Canberra (Australia). A web search
> >> >> shows other recent purchasers in Lancaster (UK) and Seattle
> >> >> (USA). Just like an emergent virus, our age of e-commerce and
> >> >> airmail allows underdocumented hardware to spread around the
> >> >> world instantly using the vector of ridiculously low prices.
> >> >>
> >> >> Paige Thompson, infected via eBay, discovered that the HG20F9
> >> >> is a copy of the Asix 88772B; many viruses copy the RNA of
> >> >> other viruses. See Paige's work at
> >> >> <https://github.com/paigeadele/HG20F9>.
> >> >> This patch uses her discovery to update the restructured Asix
> >> >> driver in the current kernel.
> >> >>
> >> >> The spread of viruses is often accompanied by rumours. It is
> >> >> rumoured that the HG20F9 has extensions to to provide gigabit
> >> >> ethernet. This patch does not chase that chimera.
> >> >>
> >> >> Just as some viruses inhabit seemingly-healthy cells, the
> >> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> >> >> For the present there is no clash of Product ID 0x20f9.
> >> >>
> >> >> Signed-off-by: Glen Turner <gdt@gdt.id.au>
> >> >
> >> > That is the best "add a new device id" changelog entry I have _ever_
> >> > seen. Wonderful job:
> >> >
> >> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>
> >> Was this patch really submitted properly to netdev? I can't
> >> find it in patchwork at all.
> >
> > It was Cc: netdev@vger.kernel.org with Message-ID:
> > <1361852232.23197.4.camel@andromache.adelaide.aarnet.edu.au> so it
> > should have gone through there somehow.
>
> Nope:
>
> http://marc.info/?t=136185267100001&r=1&w=2
>
> It didn't make it to any of the lists, that's why you are the
> only person who saw the original patch.
Odd, I've now bounced it to the mailing lists, hopefully it gets there
that way. If not, I can resend it from me directly.
I'll wait till the morning to see if the messages make it through the
lists.
thanks,
greg k-h
^ permalink raw reply
* Re: batman-adv: gpf in batadv_slide_own_bcast_window
From: Marek Lindner @ 2013-02-26 5:52 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Simon Wunderlich, Dave Jones, Sasha Levin, David S. Miller
In-Reply-To: <5127BAD2.1040007-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Saturday, February 23, 2013 02:37:06 Sasha Levin wrote:
> I'm confused about how batadv_orig_hash_del_if removes an interface from
> the hashtable. I see the hashtable is using rcu to protect it, but when we
> delete an entry we free it straight away by calling
> batadv_orig_node_del_if() and not going through kfree_rcu().
>
> Is there a reason behind doing that, or might it be the cause of the
> problem we're seeing here?
Maybe I am overlooking something but it seems to me access to this memory is
protected by the same lock: orig_node->ogm_cnt_lock
Before batadv_orig_node_del_if() is called this lock is acquired and
batadv_slide_own_bcast_window() also attempts acquire the orig_node-
>ogm_cnt_lock spinlock before writing to this chunk of memory.
Do we know for certain that batadv_orig_hash_del_if() is involved or is that a
guess at this point ? If you ask me the next for-loop in
batadv_orig_hash_del_if() looks more suspicious than the first one. The
interfaces get renumbered without any protection. Could be a regression from
the orig_hash_lock removal (the comments refer to a now inexisting lock).
Cheers,
Marek
^ permalink raw reply
* Re: [PATCH 6/8] netfront: multi-page ring support
From: ANNIE LI @ 2013-02-26 6:52 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, netdev, ian.campbell, konrad.wilk
In-Reply-To: <1360944010-15336-7-git-send-email-wei.liu2@citrix.com>
On 2013-2-16 0:00, Wei Liu wrote:
> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> ---
> drivers/net/xen-netfront.c | 246 +++++++++++++++++++++++++++++++-------------
> 1 file changed, 174 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 8bd75a1..de73a71 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -67,9 +67,19 @@ struct netfront_cb {
>
> #define GRANT_INVALID_REF 0
>
> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> +#define XENNET_MAX_RING_PAGES (1U<< XENNET_MAX_RING_PAGE_ORDER)
> +
> +
> +#define NET_TX_RING_SIZE(_nr_pages) \
> + __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> +#define NET_RX_RING_SIZE(_nr_pages) \
> + __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> +
> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +
> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
Not using multi-page ring here?
In xennet_create_dev, gnttab_alloc_grant_references allocates
TX_MAX_TARGET number of grant reference for tx. In
xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
skb_entry_is_link helps to not release invalid grants, lots of null loop
seems unnecessary. I think TX_MAX_TARGET should be changed into some
variableconnected with np->tx_ring_pages. Or you intended to use one
page ring here?
>
> struct netfront_stats {
> u64 rx_packets;
> @@ -80,6 +90,11 @@ struct netfront_stats {
> };
>
> struct netfront_info {
> + /* Statistics */
> + struct netfront_stats __percpu *stats;
> +
> + unsigned long rx_gso_checksum_fixup;
> +
> struct list_head list;
> struct net_device *netdev;
>
> @@ -90,7 +105,9 @@ struct netfront_info {
>
> spinlock_t tx_lock;
> struct xen_netif_tx_front_ring tx;
> - int tx_ring_ref;
> + int tx_ring_ref[XENNET_MAX_RING_PAGES];
> + unsigned int tx_ring_page_order;
> + unsigned int tx_ring_pages;
>
> /*
> * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
> @@ -104,36 +121,33 @@ struct netfront_info {
> union skb_entry {
> struct sk_buff *skb;
> unsigned long link;
> - } tx_skbs[NET_TX_RING_SIZE];
> + } tx_skbs[XENNET_MAX_TX_RING_SIZE];
> grant_ref_t gref_tx_head;
> - grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> + grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
> unsigned tx_skb_freelist;
>
> spinlock_t rx_lock ____cacheline_aligned_in_smp;
> struct xen_netif_rx_front_ring rx;
> - int rx_ring_ref;
> + int rx_ring_ref[XENNET_MAX_RING_PAGES];
> + unsigned int rx_ring_page_order;
> + unsigned int rx_ring_pages;
>
> /* Receive-ring batched refills. */
> #define RX_MIN_TARGET 8
> #define RX_DFL_MIN_TARGET 64
> -#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> +#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE(1), 256)
Not using multi-page ring here?
(See comments of tx side above)
Thanks
Annie
> unsigned rx_min_target, rx_max_target, rx_target;
> struct sk_buff_head rx_batch;
>
> struct timer_list rx_refill_timer;
>
> - struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> + struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
> grant_ref_t gref_rx_head;
> - grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
> -
> - unsigned long rx_pfn_array[NET_RX_RING_SIZE];
> - struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
> - struct mmu_update rx_mmu[NET_RX_RING_SIZE];
> -
> - /* Statistics */
> - struct netfront_stats __percpu *stats;
> + grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
>
> - unsigned long rx_gso_checksum_fixup;
> + unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
> + struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
> + struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
> };
>
> struct netfront_rx_info {
> @@ -171,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
> return id;
> }
>
> -static int xennet_rxidx(RING_IDX idx)
> +static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
> {
> - return idx& (NET_RX_RING_SIZE - 1);
> + return idx& (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
> }
>
> static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
> RING_IDX ri)
> {
> - int i = xennet_rxidx(ri);
> + int i = xennet_rxidx(ri, np);
> struct sk_buff *skb = np->rx_skbs[i];
> np->rx_skbs[i] = NULL;
> return skb;
> @@ -188,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
> static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
> RING_IDX ri)
> {
> - int i = xennet_rxidx(ri);
> + int i = xennet_rxidx(ri, np);
> grant_ref_t ref = np->grant_rx_ref[i];
> np->grant_rx_ref[i] = GRANT_INVALID_REF;
> return ref;
> @@ -301,7 +315,7 @@ no_skb:
>
> skb->dev = dev;
>
> - id = xennet_rxidx(req_prod + i);
> + id = xennet_rxidx(req_prod + i, np);
>
> BUG_ON(np->rx_skbs[id]);
> np->rx_skbs[id] = skb;
> @@ -653,7 +667,7 @@ static int xennet_close(struct net_device *dev)
> static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
> grant_ref_t ref)
> {
> - int new = xennet_rxidx(np->rx.req_prod_pvt);
> + int new = xennet_rxidx(np->rx.req_prod_pvt, np);
>
> BUG_ON(np->rx_skbs[new]);
> np->rx_skbs[new] = skb;
> @@ -1109,7 +1123,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
> struct sk_buff *skb;
> int i;
>
> - for (i = 0; i< NET_TX_RING_SIZE; i++) {
> + for (i = 0; i< NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
> /* Skip over entries which are actually freelist references */
> if (skb_entry_is_link(&np->tx_skbs[i]))
> continue;
> @@ -1143,7 +1157,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
>
> spin_lock_bh(&np->rx_lock);
>
> - for (id = 0; id< NET_RX_RING_SIZE; id++) {
> + for (id = 0; id< NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
> ref = np->grant_rx_ref[id];
> if (ref == GRANT_INVALID_REF) {
> unused++;
> @@ -1324,13 +1338,13 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
>
> /* Initialise tx_skbs as a free chain containing every entry. */
> np->tx_skb_freelist = 0;
> - for (i = 0; i< NET_TX_RING_SIZE; i++) {
> + for (i = 0; i< XENNET_MAX_TX_RING_SIZE; i++) {
> skb_entry_set_link(&np->tx_skbs[i], i+1);
> np->grant_tx_ref[i] = GRANT_INVALID_REF;
> }
>
> /* Clear out rx_skbs */
> - for (i = 0; i< NET_RX_RING_SIZE; i++) {
> + for (i = 0; i< XENNET_MAX_RX_RING_SIZE; i++) {
> np->rx_skbs[i] = NULL;
> np->grant_rx_ref[i] = GRANT_INVALID_REF;
> }
> @@ -1428,13 +1442,6 @@ static int netfront_probe(struct xenbus_device *dev,
> return err;
> }
>
> -static void xennet_end_access(int ref, void *page)
> -{
> - /* This frees the page as a side-effect */
> - if (ref != GRANT_INVALID_REF)
> - gnttab_end_foreign_access(ref, 0, (unsigned long)page);
> -}
> -
> static void xennet_disconnect_backend(struct netfront_info *info)
> {
> /* Stop old i/f to prevent errors whilst we rebuild the state. */
> @@ -1448,12 +1455,12 @@ static void xennet_disconnect_backend(struct netfront_info *info)
> unbind_from_irqhandler(info->netdev->irq, info->netdev);
> info->evtchn = info->netdev->irq = 0;
>
> - /* End access and free the pages */
> - xennet_end_access(info->tx_ring_ref, info->tx.sring);
> - xennet_end_access(info->rx_ring_ref, info->rx.sring);
> + xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
> + free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
> +
> + xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
> + free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
>
> - info->tx_ring_ref = GRANT_INVALID_REF;
> - info->rx_ring_ref = GRANT_INVALID_REF;
> info->tx.sring = NULL;
> info->rx.sring = NULL;
> }
> @@ -1501,11 +1508,14 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> struct xen_netif_tx_sring *txs;
> struct xen_netif_rx_sring *rxs;
> int err;
> - int grefs[1];
> struct net_device *netdev = info->netdev;
> + unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> + int i;
>
> - info->tx_ring_ref = GRANT_INVALID_REF;
> - info->rx_ring_ref = GRANT_INVALID_REF;
> + for (i = 0; i< XENNET_MAX_RING_PAGES; i++) {
> + info->tx_ring_ref[i] = GRANT_INVALID_REF;
> + info->rx_ring_ref[i] = GRANT_INVALID_REF;
> + }
> info->rx.sring = NULL;
> info->tx.sring = NULL;
> netdev->irq = 0;
> @@ -1516,50 +1526,100 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> goto fail;
> }
>
> - txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> + err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> + "max-tx-ring-page-order", "%u",
> + &max_tx_ring_page_order);
> + if (err< 0) {
> + info->tx_ring_page_order = 0;
> + dev_info(&dev->dev, "single tx ring\n");
> + } else {
> + if (max_tx_ring_page_order> XENNET_MAX_RING_PAGE_ORDER) {
> + dev_info(&dev->dev,
> + "backend ring page order %d too large, clamp to %d\n",
> + max_tx_ring_page_order,
> + XENNET_MAX_RING_PAGE_ORDER);
> + max_tx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> + }
> + info->tx_ring_page_order = max_tx_ring_page_order;
> + dev_info(&dev->dev, "multi-page tx ring, order = %d\n",
> + info->tx_ring_page_order);
> + }
> + info->tx_ring_pages = (1U<< info->tx_ring_page_order);
> +
> + txs = (struct xen_netif_tx_sring *)
> + __get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
> + info->tx_ring_page_order);
> if (!txs) {
> err = -ENOMEM;
> xenbus_dev_fatal(dev, err, "allocating tx ring page");
> goto fail;
> }
> SHARED_RING_INIT(txs);
> - FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
> + FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
> +
> + err = xenbus_grant_ring(dev, txs, info->tx_ring_pages,
> + info->tx_ring_ref);
> + if (err< 0)
> + goto grant_tx_ring_fail;
>
> - err = xenbus_grant_ring(dev, txs, 1, grefs);
> + err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> + "max-rx-ring-page-order", "%u",
> + &max_rx_ring_page_order);
> if (err< 0) {
> - free_page((unsigned long)txs);
> - goto fail;
> + info->rx_ring_page_order = 0;
> + dev_info(&dev->dev, "single rx ring\n");
> + } else {
> + if (max_rx_ring_page_order> XENNET_MAX_RING_PAGE_ORDER) {
> + dev_info(&dev->dev,
> + "backend ring page order %d too large, clamp to %d\n",
> + max_rx_ring_page_order,
> + XENNET_MAX_RING_PAGE_ORDER);
> + max_rx_ring_page_order = XENNET_MAX_RING_PAGE_ORDER;
> + }
> + info->rx_ring_page_order = max_rx_ring_page_order;
> + dev_info(&dev->dev, "multi-page rx ring, order = %d\n",
> + info->rx_ring_page_order);
> }
> + info->rx_ring_pages = (1U<< info->rx_ring_page_order);
>
> - info->tx_ring_ref = grefs[0];
> - rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> + rxs = (struct xen_netif_rx_sring *)
> + __get_free_pages(__GFP_ZERO | GFP_NOIO | __GFP_HIGH,
> + info->rx_ring_page_order);
> if (!rxs) {
> err = -ENOMEM;
> xenbus_dev_fatal(dev, err, "allocating rx ring page");
> - goto fail;
> + goto alloc_rx_ring_fail;
> }
> SHARED_RING_INIT(rxs);
> - FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
> + FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
>
> - err = xenbus_grant_ring(dev, rxs, 1, grefs);
> - if (err< 0) {
> - free_page((unsigned long)rxs);
> - goto fail;
> - }
> - info->rx_ring_ref = grefs[0];
> + err = xenbus_grant_ring(dev, rxs, info->rx_ring_pages,
> + info->rx_ring_ref);
> + if (err< 0)
> + goto grant_rx_ring_fail;
>
> err = xenbus_alloc_evtchn(dev,&info->evtchn);
> if (err)
> - goto fail;
> + goto alloc_evtchn_fail;
>
> err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
> 0, netdev->name, netdev);
> if (err< 0)
> - goto fail;
> + goto bind_fail;
> netdev->irq = err;
> return 0;
>
> - fail:
> +bind_fail:
> + xenbus_free_evtchn(dev, info->evtchn);
> +alloc_evtchn_fail:
> + xenbus_unmap_ring_vfree(info->xbdev, (void *)info->rx.sring);
> +grant_rx_ring_fail:
> + free_pages((unsigned long)info->rx.sring, info->rx_ring_page_order);
> +alloc_rx_ring_fail:
> + xenbus_unmap_ring_vfree(info->xbdev, (void *)info->tx.sring);
> +grant_tx_ring_fail:
> + free_pages((unsigned long)info->tx.sring, info->tx_ring_page_order);
> +fail:
> return err;
> }
>
> @@ -1570,6 +1630,7 @@ static int talk_to_netback(struct xenbus_device *dev,
> const char *message;
> struct xenbus_transaction xbt;
> int err;
> + int i;
>
> /* Create shared ring, alloc event channel. */
> err = setup_netfront(dev, info);
> @@ -1583,18 +1644,58 @@ again:
> goto destroy_ring;
> }
>
> - err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> - info->tx_ring_ref);
> - if (err) {
> - message = "writing tx ring-ref";
> - goto abort_transaction;
> + if (info->tx_ring_page_order == 0) {
> + err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> + info->tx_ring_ref[0]);
> + if (err) {
> + message = "writing tx ring-ref";
> + goto abort_transaction;
> + }
> + } else {
> + err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
> + info->tx_ring_page_order);
> + if (err) {
> + message = "writing tx-ring-order";
> + goto abort_transaction;
> + }
> + for (i = 0; i< info->tx_ring_pages; i++) {
> + char name[sizeof("tx-ring-ref")+3];
> + snprintf(name, sizeof(name), "tx-ring-ref%u", i);
> + err = xenbus_printf(xbt, dev->nodename, name, "%u",
> + info->tx_ring_ref[i]);
> + if (err) {
> + message = "writing tx ring-ref";
> + goto abort_transaction;
> + }
> + }
> }
> - err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> - info->rx_ring_ref);
> - if (err) {
> - message = "writing rx ring-ref";
> - goto abort_transaction;
> +
> + if (info->rx_ring_page_order == 0) {
> + err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> + info->rx_ring_ref[0]);
> + if (err) {
> + message = "writing rx ring-ref";
> + goto abort_transaction;
> + }
> + } else {
> + err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
> + info->rx_ring_page_order);
> + if (err) {
> + message = "writing rx-ring-order";
> + goto abort_transaction;
> + }
> + for (i = 0; i< info->rx_ring_pages; i++) {
> + char name[sizeof("rx-ring-ref")+3];
> + snprintf(name, sizeof(name), "rx-ring-ref%u", i);
> + err = xenbus_printf(xbt, dev->nodename, name, "%u",
> + info->rx_ring_ref[i]);
> + if (err) {
> + message = "writing rx ring-ref";
> + goto abort_transaction;
> + }
> + }
> }
> +
> err = xenbus_printf(xbt, dev->nodename,
> "event-channel", "%u", info->evtchn);
> if (err) {
> @@ -1681,7 +1782,8 @@ static int xennet_connect(struct net_device *dev)
> xennet_release_tx_bufs(np);
>
> /* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
> - for (requeue_idx = 0, i = 0; i< NET_RX_RING_SIZE; i++) {
> + for (requeue_idx = 0, i = 0; i< NET_RX_RING_SIZE(np->rx_ring_pages);
> + i++) {
> skb_frag_t *frag;
> const struct page *page;
> if (!np->rx_skbs[i])
^ permalink raw reply
* Re: linux-next: manual merge of the infiniband tree with Linus' tree
From: Or Gerlitz @ 2013-02-26 7:27 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Roland Dreier, linux-rdma, linux-next, linux-kernel,
Hadar Hen Zion, David Miller, netdev, Shani Michaeli, Haggai Eran,
Amir Vadai
In-Reply-To: <20130226114508.0f8d1101156f9f4a309579f6@canb.auug.org.au>
On 26/02/2013 02:45, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the infiniband tree got a conflict in
> drivers/net/ethernet/mellanox/mlx4/mlx4.h between commit 23537b732f5d
> ("net/mlx4_core: Use firmware driven flow steering hash mode") from
> Linus' tree and commit e448834e3545 ("mlx4_core: Enable memory windows in
> {INIT, QUERY}_HCA") from the infiniband tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
thanks,
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
^ permalink raw reply
* [PATCH] proc connector: reject unprivileged listener bumps
From: Kees Cook @ 2013-02-26 7:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Evgeniy Polyakov, netdev, Matt Helsley
While PROC_CN_MCAST_LISTEN/IGNORE is entirely advisory, it was possible
for an unprivileged user to turn off notifications for all listeners by
sending PROC_CN_MCAST_IGNORE. Instead, require the same privileges as
required for a multicast bind.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: stable@vger.kernel.org
---
drivers/connector/cn_proc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index fce2000..1110478 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -313,6 +313,12 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg,
(task_active_pid_ns(current) != &init_pid_ns))
return;
+ /* Can only change if privileged. */
+ if (!capable(CAP_NET_ADMIN)) {
+ err = EPERM;
+ goto out;
+ }
+
mc_op = (enum proc_cn_mcast_op *)msg->data;
switch (*mc_op) {
case PROC_CN_MCAST_LISTEN:
@@ -325,6 +331,8 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg,
err = EINVAL;
break;
}
+
+out:
cn_proc_ack(err, msg->seq, msg->ack);
}
--
1.7.9.5
--
Kees Cook
Chrome OS Security
^ permalink raw reply related
* Re: 3.9 merge window kernels
From: Antti Palosaari @ 2013-02-26 7:51 UTC (permalink / raw)
To: poma
Cc: Josh Boyer, Mauro Carvalho Chehab, kernel, netdev,
David S. Miller, Stephen Hemminger, Stephen Hemminger,
Stephen Hemminger
In-Reply-To: <512C1B5C.20604@gmail.com>
On 02/26/2013 04:18 AM, poma wrote:
> On 02/26/13 02:12, Josh Boyer wrote:
>> On Tue, Feb 26, 2013 at 01:05:05AM +0100, poma wrote:
>>> On 02/25/13 01:22, Antti Palosaari wrote:
>>> […]
>>>>>> Poma, you should probably just start filing bugs for things you hit.
>>>>>> In this case, the skge backtrace is just a warning but it can be fixed
>>>>>> up relatively easily.
>>>>>>
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=914994
>>>>> Josh, Mauro thanks for the overview. :)
>>>>> Antti, cheers. ;)
>>>>>
>>>>> poma
>>>>
>>>> I cannot see these warnings at all. What is Kernel option to enable
>>>> those debug(?) warnings? From which menu it could be located when make
>>>> menuconfig ?
>>>>
>>>
>>> http://kojipkgs.fedoraproject.org/packages/kernel/3.9.0/0.rc0.git7.1.fc19/data/logs/x86_64/build.log
>>> Even after reapplying Stephen's "skge: check for PCI dma mapping
>>> errors"[1] from David's 'net-next' tree, no luck.
>>> …
>>> WARNING: at lib/dma-debug.c:933 check_unmap+0x47b/0x960()
>>> skge 0000:01:09.0: DMA-API: device driver failed to check map
>>> error[device address=0x000000010287094a] [size=90 bytes] [mapped as single]
>>> …
>>
>> I'm confused. You pointed to the build I did this morning, which
>> definitely doesn't include the commit you mentioned. Are you saying you
>> took this morning's build and applied the patch yourself? If so, did it
>> really get applied? Do you have logs? Do you have more than just that
>> tiny snippet of error message?
>>
>
> build.log is for Antti's eyes only. :)
> Logs are virtually the same, with or without that *old* commit, which is
> actually replaced by this one[1].
> So of course it isn't in 3.9.0-0.rc0.git7.1.fc19.x86_64. ;)
> Building particular module groups(skge & Co.) rather than build an
> entire kernel tree isn't big deal, likewise.
> You know that better than me. ;)
> The real question is whether someone will help squeeze this bug.
I want just know if I could reproduce that AF9015 error message or was
it just warning. Is it something I have to fix for Kernel 3.10 or
earlier. I am running Fedora 17 AMD64 and could surely compile any
Kernel needed.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply
* [patch net] bond: check if slave count is 0 in case when deciding to take slave's mac
From: Jiri Pirko @ 2013-02-26 8:26 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, andy, gregory.v.rose
in bond_enslave(), check slave_cnt before actually using slave address.
introduced by:
commit 409cc1f8a41 (bond: have random dev address by default instead of zeroes)
Reported-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 11d01d6..7bd068a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1629,7 +1629,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
/* If this is the first slave, then we need to set the master's hardware
* address to be the same as the slave's. */
- if (bond->dev_addr_from_first)
+ if (bond->slave_cnt == 0 && bond->dev_addr_from_first)
bond_set_dev_addr(bond->dev, slave_dev);
new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] proc connector: reject unprivileged listener bumps
From: Evgeniy Polyakov @ 2013-02-26 8:46 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-kernel, netdev, Matt Helsley
In-Reply-To: <20130226073225.GA15489@www.outflux.net>
Hi
On Mon, Feb 25, 2013 at 11:32:25PM -0800, Kees Cook (keescook@chromium.org) wrote:
> While PROC_CN_MCAST_LISTEN/IGNORE is entirely advisory, it was possible
> for an unprivileged user to turn off notifications for all listeners by
> sending PROC_CN_MCAST_IGNORE. Instead, require the same privileges as
> required for a multicast bind.
Sounds resonable.
Not sure whether this is a candidate for stable release, but otherwise
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
--
Evgeniy Polyakov
^ permalink raw reply
* [PATCH] isdn: hisax: add missing usb_free_urb
From: Marina Makienko @ 2013-02-26 8:26 UTC (permalink / raw)
To: Karsten Keil; +Cc: Marina Makienko, netdev, ldv-project
Add missing usb_free_urb() on failure path in st5481_setup_usb().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Marina Makienko <makienko@ispras.ru>
---
drivers/isdn/hisax/st5481_usb.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/hisax/st5481_usb.c b/drivers/isdn/hisax/st5481_usb.c
index 017c67e..ead0a4f 100644
--- a/drivers/isdn/hisax/st5481_usb.c
+++ b/drivers/isdn/hisax/st5481_usb.c
@@ -294,13 +294,13 @@ int st5481_setup_usb(struct st5481_adapter *adapter)
// Allocate URBs and buffers for interrupt endpoint
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
- return -ENOMEM;
+ goto err1;
}
intr->urb = urb;
buf = kmalloc(INT_PKT_SIZE, GFP_KERNEL);
if (!buf) {
- return -ENOMEM;
+ goto err2;
}
endpoint = &altsetting->endpoint[EP_INT-1];
@@ -313,6 +313,14 @@ int st5481_setup_usb(struct st5481_adapter *adapter)
endpoint->desc.bInterval);
return 0;
+err2:
+ usb_free_urb(intr->urb);
+ intr->urb = NULL;
+err1:
+ usb_free_urb(ctrl->urb);
+ ctrl->urb = NULL;
+
+ return -ENOMEM;
}
/*
--
1.7.7
^ permalink raw reply related
* Re: 3.9 merge window kernels
From: Antti Palosaari @ 2013-02-26 8:54 UTC (permalink / raw)
To: poma
Cc: Josh Boyer, Mauro Carvalho Chehab, kernel, netdev,
David S. Miller, Stephen Hemminger, Stephen Hemminger,
Stephen Hemminger
In-Reply-To: <512C698E.7070306@iki.fi>
On 02/26/2013 09:51 AM, Antti Palosaari wrote:
> On 02/26/2013 04:18 AM, poma wrote:
>> On 02/26/13 02:12, Josh Boyer wrote:
>>> On Tue, Feb 26, 2013 at 01:05:05AM +0100, poma wrote:
>>>> On 02/25/13 01:22, Antti Palosaari wrote:
>>>> […]
>>>>>>> Poma, you should probably just start filing bugs for things you hit.
>>>>>>> In this case, the skge backtrace is just a warning but it can be
>>>>>>> fixed
>>>>>>> up relatively easily.
>>>>>>>
>>>>>>
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=914994
>>>>>> Josh, Mauro thanks for the overview. :)
>>>>>> Antti, cheers. ;)
>>>>>>
>>>>>> poma
>>>>>
>>>>> I cannot see these warnings at all. What is Kernel option to enable
>>>>> those debug(?) warnings? From which menu it could be located when make
>>>>> menuconfig ?
>>>>>
>>>>
>>>> http://kojipkgs.fedoraproject.org/packages/kernel/3.9.0/0.rc0.git7.1.fc19/data/logs/x86_64/build.log
>>>>
>>>> Even after reapplying Stephen's "skge: check for PCI dma mapping
>>>> errors"[1] from David's 'net-next' tree, no luck.
>>>> …
>>>> WARNING: at lib/dma-debug.c:933 check_unmap+0x47b/0x960()
>>>> skge 0000:01:09.0: DMA-API: device driver failed to check map
>>>> error[device address=0x000000010287094a] [size=90 bytes] [mapped as
>>>> single]
>>>> …
>>>
>>> I'm confused. You pointed to the build I did this morning, which
>>> definitely doesn't include the commit you mentioned. Are you saying you
>>> took this morning's build and applied the patch yourself? If so, did it
>>> really get applied? Do you have logs? Do you have more than just that
>>> tiny snippet of error message?
>>>
>>
>> build.log is for Antti's eyes only. :)
>> Logs are virtually the same, with or without that *old* commit, which is
>> actually replaced by this one[1].
>> So of course it isn't in 3.9.0-0.rc0.git7.1.fc19.x86_64. ;)
>> Building particular module groups(skge & Co.) rather than build an
>> entire kernel tree isn't big deal, likewise.
>> You know that better than me. ;)
>> The real question is whether someone will help squeeze this bug.
>
> I want just know if I could reproduce that AF9015 error message or was
> it just warning. Is it something I have to fix for Kernel 3.10 or
> earlier. I am running Fedora 17 AMD64 and could surely compile any
> Kernel needed.
OK, found it finally.
Kernel hacking ---> Enable debugging of DMA-API usage
There was rather many DVB USB drivers using USB bulk buffers from the
stack. I will fix at least some of those, lets say for 3.10.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Srivatsa S. Bhat @ 2013-02-26 9:02 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Michel Lespinasse, linux-doc, peterz, fweisbec, linux-kernel,
namhyung, mingo, linux-arch, linux, xiaoguangrong, wangyun,
paulmck, nikunj, linux-pm, rusty, rostedt, rjw, vincent.guittot,
tglx, linux-arm-kernel, netdev, oleg, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <CACvQF51jCxk5jUqmhD=QBBtUsBkQWZzakacrKO4Gsk=w61rNwQ@mail.gmail.com>
On 02/26/2013 05:47 AM, Lai Jiangshan wrote:
> On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> Hi Lai,
>>
>> On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
>>> Hi, Srivatsa,
>>>
>>> The target of the whole patchset is nice for me.
>>
>> Cool! Thanks :-)
>>
[...]
>>> I wrote an untested draft here.
>>>
>>> Thanks,
>>> Lai
>>>
>>> PS: Some HA tools(I'm writing one) which takes checkpoints of
>>> virtual-machines frequently, I guess this patchset can speedup the
>>> tools.
>>>
>>> From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
>>> From: Lai Jiangshan <laijs@cn.fujitsu.com>
>>> Date: Mon, 25 Feb 2013 23:14:27 +0800
>>> Subject: [PATCH] lglock: add read-preference local-global rwlock
>>>
>>> locality via lglock(trylock)
>>> read-preference read-write-lock via fallback rwlock_t
>>>
>>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>>> ---
>>> include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
>>> kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 76 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/lglock.h b/include/linux/lglock.h
>>> index 0d24e93..30fe887 100644
>>> --- a/include/linux/lglock.h
>>> +++ b/include/linux/lglock.h
>>> @@ -67,4 +67,35 @@ void lg_local_unlock_cpu(struct lglock *lg, int cpu);
>>> void lg_global_lock(struct lglock *lg);
>>> void lg_global_unlock(struct lglock *lg);
>>>
>>> +struct lgrwlock {
>>> + unsigned long __percpu *fallback_reader_refcnt;
>>> + struct lglock lglock;
>>> + rwlock_t fallback_rwlock;
>>> +};
>>> +
>>> +#define DEFINE_LGRWLOCK(name) \
>>> + static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
>>> + = __ARCH_SPIN_LOCK_UNLOCKED; \
>>> + static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
>>> + struct lgrwlock name = { \
>>> + .fallback_reader_refcnt = &name ## _refcnt, \
>>> + .lglock = { .lock = &name ## _lock } }
>>> +
>>> +#define DEFINE_STATIC_LGRWLOCK(name) \
>>> + static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
>>> + = __ARCH_SPIN_LOCK_UNLOCKED; \
>>> + static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
>>> + static struct lgrwlock name = { \
>>> + .fallback_reader_refcnt = &name ## _refcnt, \
>>> + .lglock = { .lock = &name ## _lock } }
>>> +
>>> +static inline void lg_rwlock_init(struct lgrwlock *lgrw, char *name)
>>> +{
>>> + lg_lock_init(&lgrw->lglock, name);
>>> +}
>>> +
>>> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw);
>>> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw);
>>> +void lg_rwlock_global_write_lock(struct lgrwlock *lgrw);
>>> +void lg_rwlock_global_write_unlock(struct lgrwlock *lgrw);
>>> #endif
>>> diff --git a/kernel/lglock.c b/kernel/lglock.c
>>> index 6535a66..463543a 100644
>>> --- a/kernel/lglock.c
>>> +++ b/kernel/lglock.c
>>> @@ -87,3 +87,48 @@ void lg_global_unlock(struct lglock *lg)
>>> preempt_enable();
>>> }
>>> EXPORT_SYMBOL(lg_global_unlock);
>>> +
>>> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
>>> +{
>>> + struct lglock *lg = &lgrw->lglock;
>>> +
>>> + preempt_disable();
>>> + if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
>>> + if (likely(arch_spin_trylock(this_cpu_ptr(lg->lock)))) {
>>> + rwlock_acquire_read(&lg->lock_dep_map, 0, 0, _RET_IP_);
>>> + return;
>>> + }
>>> + read_lock(&lgrw->fallback_rwlock);
>>> + }
>>> +
>>> + __this_cpu_inc(*lgrw->fallback_reader_refcnt);
>>> +}
>>> +EXPORT_SYMBOL(lg_rwlock_local_read_lock);
>>> +
>>> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw)
>>> +{
>>> + if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
>>> + lg_local_unlock(&lgrw->lglock);
>>> + return;
>>> + }
>>> +
>>> + if (!__this_cpu_dec_return(*lgrw->fallback_reader_refcnt))
>>> + read_unlock(&lgrw->fallback_rwlock);
>>> +
>>> + preempt_enable();
>>> +}
>>> +EXPORT_SYMBOL(lg_rwlock_local_read_unlock);
>>> +
>>
>> If I read the code above correctly, all you are doing is implementing a
>> recursive reader-side primitive (ie., allowing the reader to call these
>> functions recursively, without resulting in a self-deadlock).
>>
>> But the thing is, making the reader-side recursive is the least of our
>> problems! Our main challenge is to make the locking extremely flexible
>> and also safe-guard it against circular-locking-dependencies and deadlocks.
>> Please take a look at the changelog of patch 1 - it explains the situation
>> with an example.
>
>
> My lock fixes your requirements(I read patch 1-6 before I sent). In
> readsite, lglock 's lock is token via trylock, the lglock doesn't
> contribute to deadlocks, we can consider it doesn't exist when we find
> deadlock from it. And global fallback rwlock doesn't result to
> deadlocks because it is read-preference(you need to inc the
> fallback_reader_refcnt inside the cpu-hotplug write-side, I don't do
> it in generic lgrwlock)
>
Ah, since you hadn't mentioned the increment at the writer-side in your
previous email, I had missed the bigger picture of what you were trying
to achieve.
>
> If lg_rwlock_local_read_lock() spins, which means
> lg_rwlock_local_read_lock() spins on fallback_rwlock, and which means
> lg_rwlock_global_write_lock() took the lgrwlock successfully and
> return, and which means lg_rwlock_local_read_lock() will stop spinning
> when the write side finished.
>
Unfortunately, I see quite a few issues with the code above. IIUC, the
writer and the reader both increment the same counters. So how will the
unlock() code in the reader path know when to unlock which of the locks?
(The counter-dropping-to-zero logic is not safe, since it can be updated
due to different reasons). And now that I look at it again, in the absence
of the writer, the reader is allowed to be recursive at the heavy cost of
taking the global rwlock for read, every 2nd time you nest (because the
spinlock is non-recursive). Also, this lg_rwlock implementation uses 3
different data-structures - a per-cpu spinlock, a global rwlock and
a per-cpu refcnt, and its not immediately apparent why you need those many
or even those many varieties. Also I see that this doesn't handle the
case of interrupt-handlers also being readers.
IMHO, the per-cpu rwlock scheme that I have implemented in this patchset
has a clean, understandable design and just enough data-structures/locks
to achieve its goal and has several optimizations (like reducing the
interrupts-disabled time etc) included - all in a very straight-forward
manner. Since this is non-trivial, IMHO, starting from a clean slate is
actually better than trying to retrofit the logic into some locking scheme
which we actively want to avoid (and hence effectively we aren't even
borrowing anything from!).
To summarize, if you are just pointing out that we can implement the same
logic by altering lglocks, then sure, I acknowledge the possibility.
However, I don't think doing that actually makes it better; it either
convolutes the logic unnecessarily, or ends up looking _very_ similar to
the implementation in this patchset, from what I can see.
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: [E1000-devel] [PATCH RESEND 3/3] e1000e: fix accessing to suspended device
From: Konstantin Khlebnikov @ 2013-02-26 10:03 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: linux-kernel, netdev, e1000-devel, Rafael J. Wysocki, Bruce Allan
In-Reply-To: <512C0B59.4020209@intel.com>
Waskiewicz Jr, Peter P wrote:
> On 2/24/2013 9:19 PM, Konstantin Khlebnikov wrote:
>> This patch fixes some annoying messages like 'Error reading PHY register' and
>> 'Hardware Erorr' and saves several seconds on reboot.
>
> Any networking-related patches should also include netdev@vger.kernel.org.
Yeah, I forgot about this, since I came here from PCI-bus side, not from the network =)
>
> I'm also a bit confused how the changes below match the patch description.
> Elaborating a bit more how the changes suppress the messages might be a good thing.
Patch eliminates reason of these errors -- now driver will wake up
the device before accessing to its registers.
>
>>
>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Cc: e1000-devel@lists.sourceforge.net
>> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Cc: Bruce Allan <bruce.w.allan@intel.com>
>> ---
>> drivers/net/ethernet/intel/e1000e/ethtool.c | 13 +++++++++++++
>> drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
>> index 2c18137..f91a8f3 100644
>> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
>> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
>> @@ -36,6 +36,7 @@
>> #include <linux/delay.h>
>> #include <linux/vmalloc.h>
>> #include <linux/mdio.h>
>> +#include <linux/pm_runtime.h>
>>
>> #include "e1000.h"
>>
>> @@ -2229,7 +2230,19 @@ static int e1000e_get_ts_info(struct net_device *netdev,
>> return 0;
>> }
>>
>> +static int e1000e_ethtool_begin(struct net_device *netdev)
>> +{
>> + return pm_runtime_get_sync(netdev->dev.parent);
>> +}
>> +
>> +static void e1000e_ethtool_complete(struct net_device *netdev)
>> +{
>> + pm_runtime_put_sync(netdev->dev.parent);
>> +}
>> +
>> static const struct ethtool_ops e1000_ethtool_ops = {
>> + .begin = e1000e_ethtool_begin,
>> + .complete = e1000e_ethtool_complete,
>> .get_settings = e1000_get_settings,
>> .set_settings = e1000_set_settings,
>> .get_drvinfo = e1000_get_drvinfo,
>
> What do the ethtool additions have to do with this patch? The patch description really doesn't seem to cover why these are here.
>
>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
>> index 2954cc7..948b86ff 100644
>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>> @@ -4663,6 +4663,7 @@ static void e1000_phy_read_status(struct e1000_adapter *adapter)
>> (adapter->hw.phy.media_type == e1000_media_type_copper)) {
>> int ret_val;
>>
>> + pm_runtime_get_sync(&adapter->pdev->dev);
>> ret_val = e1e_rphy(hw, MII_BMCR, &phy->bmcr);
>> ret_val |= e1e_rphy(hw, MII_BMSR, &phy->bmsr);
>> ret_val |= e1e_rphy(hw, MII_ADVERTISE, &phy->advertise);
>> @@ -4673,6 +4674,7 @@ static void e1000_phy_read_status(struct e1000_adapter *adapter)
>> ret_val |= e1e_rphy(hw, MII_ESTATUS, &phy->estatus);
>> if (ret_val)
>> e_warn("Error reading PHY register\n");
>> + pm_runtime_put_sync(&adapter->pdev->dev);
>> } else {
>> /* Do not read PHY registers if link is not up
>> * Set values to typical power-on defaults
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> E1000-devel mailing list
>> E1000-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/e1000-devel
>> To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
>>
>
> --
> 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: [Xen-devel] [PATCH 0/8] Bugfix and mechanical works for Xen network driver
From: Wei Liu @ 2013-02-26 11:33 UTC (permalink / raw)
To: ANNIE LI
Cc: wei.liu2, xen-devel@lists.xen.org, netdev@vger.kernel.org,
Ian Campbell, konrad.wilk@oracle.com
In-Reply-To: <512C26F5.8020100@oracle.com>
On Tue, 2013-02-26 at 03:07 +0000, ANNIE LI wrote:
> What the version are these patches based on?
> I tried v3.8-rc7 and 3.8-rc6, patch 3/8, 4/8 ... can not be merged
> successfully. Can you rebase it?
>
IIRC we had some XSA patches after this series. Or I just developed it
on top of a old branch. I will rebase it soon.
Wei.
^ permalink raw reply
* Re: [PATCH 6/8] netfront: multi-page ring support
From: Wei Liu @ 2013-02-26 12:35 UTC (permalink / raw)
To: ANNIE LI
Cc: wei.liu2, xen-devel@lists.xen.org, netdev@vger.kernel.org,
Ian Campbell, konrad.wilk@oracle.com
In-Reply-To: <512C5B96.10204@oracle.com>
On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
>
> On 2013-2-16 0:00, Wei Liu wrote:
> > Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> > ---
> > drivers/net/xen-netfront.c | 246 +++++++++++++++++++++++++++++++-------------
> > 1 file changed, 174 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 8bd75a1..de73a71 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -67,9 +67,19 @@ struct netfront_cb {
> >
> > #define GRANT_INVALID_REF 0
> >
> > -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> > -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> > -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> > +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> > +#define XENNET_MAX_RING_PAGES (1U<< XENNET_MAX_RING_PAGE_ORDER)
> > +
> > +
> > +#define NET_TX_RING_SIZE(_nr_pages) \
> > + __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> > +#define NET_RX_RING_SIZE(_nr_pages) \
> > + __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> > +
> > +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +
> > +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
>
> Not using multi-page ring here?
> In xennet_create_dev, gnttab_alloc_grant_references allocates
> TX_MAX_TARGET number of grant reference for tx. In
> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> skb_entry_is_link helps to not release invalid grants, lots of null loop
> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> variableconnected with np->tx_ring_pages. Or you intended to use one
> page ring here?
>
Looking back my history, this limitation was introduced because if we
have a multi-page backend and single page frontend, the backend skb
processing could overlap.
I agree with you that this limit should be variable, but as we still use
M:N model, the safe option is to cap this limit to 1 page.
Another option is to check validity of skbs before processing them. I
will look into that as well.
The same reason applies to the RX ring as well.
Wei.
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Lai Jiangshan @ 2013-02-26 12:59 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: Michel Lespinasse, linux-doc, peterz, fweisbec, linux-kernel,
namhyung, mingo, linux-arch, linux, xiaoguangrong, wangyun,
paulmck, nikunj, linux-pm, rusty, rostedt, rjw, vincent.guittot,
tglx, linux-arm-kernel, netdev, oleg, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <512C7A38.8060906@linux.vnet.ibm.com>
On Tue, Feb 26, 2013 at 5:02 PM, Srivatsa S. Bhat
<srivatsa.bhat@linux.vnet.ibm.com> wrote:
> On 02/26/2013 05:47 AM, Lai Jiangshan wrote:
>> On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
>> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>>> Hi Lai,
>>>
>>> On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
>>>> Hi, Srivatsa,
>>>>
>>>> The target of the whole patchset is nice for me.
>>>
>>> Cool! Thanks :-)
>>>
> [...]
>>>> I wrote an untested draft here.
>>>>
>>>> Thanks,
>>>> Lai
>>>>
>>>> PS: Some HA tools(I'm writing one) which takes checkpoints of
>>>> virtual-machines frequently, I guess this patchset can speedup the
>>>> tools.
>>>>
>>>> From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
>>>> From: Lai Jiangshan <laijs@cn.fujitsu.com>
>>>> Date: Mon, 25 Feb 2013 23:14:27 +0800
>>>> Subject: [PATCH] lglock: add read-preference local-global rwlock
>>>>
>>>> locality via lglock(trylock)
>>>> read-preference read-write-lock via fallback rwlock_t
>>>>
>>>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>>>> ---
>>>> include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
>>>> kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 76 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/include/linux/lglock.h b/include/linux/lglock.h
>>>> index 0d24e93..30fe887 100644
>>>> --- a/include/linux/lglock.h
>>>> +++ b/include/linux/lglock.h
>>>> @@ -67,4 +67,35 @@ void lg_local_unlock_cpu(struct lglock *lg, int cpu);
>>>> void lg_global_lock(struct lglock *lg);
>>>> void lg_global_unlock(struct lglock *lg);
>>>>
>>>> +struct lgrwlock {
>>>> + unsigned long __percpu *fallback_reader_refcnt;
>>>> + struct lglock lglock;
>>>> + rwlock_t fallback_rwlock;
>>>> +};
>>>> +
>>>> +#define DEFINE_LGRWLOCK(name) \
>>>> + static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
>>>> + = __ARCH_SPIN_LOCK_UNLOCKED; \
>>>> + static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
>>>> + struct lgrwlock name = { \
>>>> + .fallback_reader_refcnt = &name ## _refcnt, \
>>>> + .lglock = { .lock = &name ## _lock } }
>>>> +
>>>> +#define DEFINE_STATIC_LGRWLOCK(name) \
>>>> + static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
>>>> + = __ARCH_SPIN_LOCK_UNLOCKED; \
>>>> + static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
>>>> + static struct lgrwlock name = { \
>>>> + .fallback_reader_refcnt = &name ## _refcnt, \
>>>> + .lglock = { .lock = &name ## _lock } }
>>>> +
>>>> +static inline void lg_rwlock_init(struct lgrwlock *lgrw, char *name)
>>>> +{
>>>> + lg_lock_init(&lgrw->lglock, name);
>>>> +}
>>>> +
>>>> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw);
>>>> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw);
>>>> +void lg_rwlock_global_write_lock(struct lgrwlock *lgrw);
>>>> +void lg_rwlock_global_write_unlock(struct lgrwlock *lgrw);
>>>> #endif
>>>> diff --git a/kernel/lglock.c b/kernel/lglock.c
>>>> index 6535a66..463543a 100644
>>>> --- a/kernel/lglock.c
>>>> +++ b/kernel/lglock.c
>>>> @@ -87,3 +87,48 @@ void lg_global_unlock(struct lglock *lg)
>>>> preempt_enable();
>>>> }
>>>> EXPORT_SYMBOL(lg_global_unlock);
>>>> +
>>>> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
>>>> +{
>>>> + struct lglock *lg = &lgrw->lglock;
>>>> +
>>>> + preempt_disable();
>>>> + if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
>>>> + if (likely(arch_spin_trylock(this_cpu_ptr(lg->lock)))) {
>>>> + rwlock_acquire_read(&lg->lock_dep_map, 0, 0, _RET_IP_);
>>>> + return;
>>>> + }
>>>> + read_lock(&lgrw->fallback_rwlock);
>>>> + }
>>>> +
>>>> + __this_cpu_inc(*lgrw->fallback_reader_refcnt);
>>>> +}
>>>> +EXPORT_SYMBOL(lg_rwlock_local_read_lock);
>>>> +
>>>> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw)
>>>> +{
>>>> + if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
>>>> + lg_local_unlock(&lgrw->lglock);
>>>> + return;
>>>> + }
>>>> +
>>>> + if (!__this_cpu_dec_return(*lgrw->fallback_reader_refcnt))
>>>> + read_unlock(&lgrw->fallback_rwlock);
>>>> +
>>>> + preempt_enable();
>>>> +}
>>>> +EXPORT_SYMBOL(lg_rwlock_local_read_unlock);
>>>> +
>>>
>>> If I read the code above correctly, all you are doing is implementing a
>>> recursive reader-side primitive (ie., allowing the reader to call these
>>> functions recursively, without resulting in a self-deadlock).
>>>
>>> But the thing is, making the reader-side recursive is the least of our
>>> problems! Our main challenge is to make the locking extremely flexible
>>> and also safe-guard it against circular-locking-dependencies and deadlocks.
>>> Please take a look at the changelog of patch 1 - it explains the situation
>>> with an example.
>>
>>
>> My lock fixes your requirements(I read patch 1-6 before I sent). In
>> readsite, lglock 's lock is token via trylock, the lglock doesn't
>> contribute to deadlocks, we can consider it doesn't exist when we find
>> deadlock from it. And global fallback rwlock doesn't result to
>> deadlocks because it is read-preference(you need to inc the
>> fallback_reader_refcnt inside the cpu-hotplug write-side, I don't do
>> it in generic lgrwlock)
>>
>
> Ah, since you hadn't mentioned the increment at the writer-side in your
> previous email, I had missed the bigger picture of what you were trying
> to achieve.
>
>>
>> If lg_rwlock_local_read_lock() spins, which means
>> lg_rwlock_local_read_lock() spins on fallback_rwlock, and which means
>> lg_rwlock_global_write_lock() took the lgrwlock successfully and
>> return, and which means lg_rwlock_local_read_lock() will stop spinning
>> when the write side finished.
>>
>
> Unfortunately, I see quite a few issues with the code above. IIUC, the
> writer and the reader both increment the same counters. So how will the
> unlock() code in the reader path know when to unlock which of the locks?
The same as your code, the reader(which nested in write C.S.) just dec
the counters.
> (The counter-dropping-to-zero logic is not safe, since it can be updated
> due to different reasons). And now that I look at it again, in the absence
> of the writer, the reader is allowed to be recursive at the heavy cost of
> taking the global rwlock for read, every 2nd time you nest (because the
> spinlock is non-recursive).
(I did not understand your comments of this part)
nested reader is considered seldom. But if N(>=2) nested readers happen,
the overhead is:
1 spin_try_lock() + 1 read_lock() + (N-1) __this_cpu_inc()
> Also, this lg_rwlock implementation uses 3
> different data-structures - a per-cpu spinlock, a global rwlock and
> a per-cpu refcnt, and its not immediately apparent why you need those many
> or even those many varieties.
data-structures is the same as yours.
fallback_reader_refcnt <--> reader_refcnt
per-cpu spinlock <--> write_signal
fallback_rwlock <---> global_rwlock
> Also I see that this doesn't handle the
> case of interrupt-handlers also being readers.
handled. nested reader will see the ref or take the fallback_rwlock
>
> IMHO, the per-cpu rwlock scheme that I have implemented in this patchset
> has a clean, understandable design and just enough data-structures/locks
> to achieve its goal and has several optimizations (like reducing the
> interrupts-disabled time etc) included - all in a very straight-forward
> manner. Since this is non-trivial, IMHO, starting from a clean slate is
> actually better than trying to retrofit the logic into some locking scheme
> which we actively want to avoid (and hence effectively we aren't even
> borrowing anything from!).
>
> To summarize, if you are just pointing out that we can implement the same
> logic by altering lglocks, then sure, I acknowledge the possibility.
> However, I don't think doing that actually makes it better; it either
> convolutes the logic unnecessarily, or ends up looking _very_ similar to
> the implementation in this patchset, from what I can see.
>
> Regards,
> Srivatsa S. Bhat
>
^ 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