* Re: SOCK_STREAM TCP: send() returns success even when other side responded with RST packet
From: Stephen Hemminger @ 2013-02-19 15:26 UTC (permalink / raw)
To: Tomas Hozza; +Cc: Eric Dumazet, netdev
In-Reply-To: <2084007858.1889873.1361286562542.JavaMail.root@redhat.com>
> stack did not yet delivered the data.
>
> I'm using TCP because it should guarantee that my data were delivered or
> let me know there was some problem. If this is not a bug, then it is at least
> confusing for TCP.
>
> > To make sure data is delivered, you need additional logic.
>
> To be honest I didn't find any way how to get notified there was a RST packet
> sent as a reply to my previously sent data.
TCP makes no end-to-end (application to application) guarantees.
Applications that need assurance need to do a request-reply at end of
transaction. You should get a good textbook like Stevens for more detail
^ permalink raw reply
* Re: SOCK_STREAM TCP: send() returns success even when other side responded with RST packet
From: Eric Dumazet @ 2013-02-19 15:27 UTC (permalink / raw)
To: Tomas Hozza; +Cc: netdev
In-Reply-To: <2084007858.1889873.1361286562542.JavaMail.root@redhat.com>
On Tue, 2013-02-19 at 10:09 -0500, Tomas Hozza wrote:
> I'm using TCP because it should guarantee that my data were delivered or
> let me know there was some problem. If this is not a bug, then it is at least
> confusing for TCP.
Note that a write() on a regular file descriptor has same semantic :
By default, there is no guarantee data is written on stable storage.
>
> > To make sure data is delivered, you need additional logic.
>
> To be honest I didn't find any way how to get notified there was a RST packet
> sent as a reply to my previously sent data.
Well, I suggest you read the man pages and some books, as this is well
explained, you are not the first guy wanting to exchange data using TCP.
man 7 socket
SO_LINGER
Sets or gets the SO_LINGER option. The argument is a linger structure.
struct linger {
int l_onoff; /* linger active */
int l_linger; /* how many seconds to linger for */
};
When enabled, a close(2) or shutdown(2) will not return until all queued messages
for the socket have been successfully sent or the linger timeout has been
reached. Otherwise, the call returns immediately and the closing is done in the
background. When the socket is closed as part of exit(2), it always lingers in
the background.
man 2 shutdown
...
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Arnd Bergmann @ 2013-02-19 15:28 UTC (permalink / raw)
To: balbi
Cc: kishon, rob, tony, linux, eballetbo, javier, gregkh, akpm,
mchehab, cesarb, davem, santosh.shilimkar, broonie, swarren,
linux-doc, linux-kernel, linux-arm-kernel, linux-omap, linux-usb,
netdev
In-Reply-To: <20130219150500.GG4390@arwen.pp.htv.fi>
On Tuesday 19 February 2013, Felipe Balbi wrote:
> On Tue, Feb 19, 2013 at 02:34:40PM +0000, Arnd Bergmann wrote:
> > On Tuesday 19 February 2013, Felipe Balbi wrote:
> > > On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:
> > It's a fine line, but I think a phy is something that resembles a device
> > more than an LED does. When I read patch 1, I also noticed and commented
> > on the fact that it does use a 'class'. Now, according to Greg, we should
> > use 'bus_type' instead of 'class' in new code. I originally disagreed with
> > that concept, but he's the boss here and it's good if he has a vision
> > how things should be lined out.
> >
> > In practice, there is little difference between a 'bus_type' and a 'class',
> > so just replace any instance of the former with the latter in your head
> > when reading the code ;-)
>
> it's not so simple :-) if we must use bus_type we need to introduce all
> the device/driver matching mechanism which isn't necessary with a class.
I think the idea is to use a bus_type that has devices but no drivers
associated with it, but I might be misremembering things.
> > I understand that there is not a real common bus here, and the bus_type
> > infrastructure would basically be used as a way to represent each PHY
> > in sysfs and provide a way to enumerate and look them up inside of the
> > kernel.
>
> right, but maybe we need another mechanism. If, in the long run we must
> use bus_type, then eventually pwm, led, regulators, etc will all be
> converted to bus_type. It will look quite weird IMHO.
Yes, it would be a bit unusual, I agree.
> Greg, can you pitch your suggestion here ? It would be great to hear
> your rationale behind dropping class infrastructure, couldn't find
> anything through Google and since feature-removal-schedule.txt has been
> removed (without adding it to feature-removal-schedule.txt, I must add
> :-) I don't know what's the idea behind removing classes.
I believe for now, the idea is to not add any new classes, but keep
the existing ones for compatibility. 'struct class_device' however
was already removed and got turned into 'struct device'.
Arnd
^ permalink raw reply
* RE: Fw: [Bug 54021] New: No internet with kernel 3.7 or 3.8 with LAN
From: Huang, Xiong @ 2013-02-19 15:46 UTC (permalink / raw)
To: J. K. Cliburn, Stephen Hemminger
Cc: Chris Snook, netdev@vger.kernel.org, nic-devel
In-Reply-To: <51237A66.8030008@gmail.com>
I'm following this bug. Thanks
-Xiong
^ permalink raw reply
* Re: SOCK_STREAM TCP: send() returns success even when other side responded with RST packet
From: Tomas Hozza @ 2013-02-19 15:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1361287646.19353.131.camel@edumazet-glaptop>
----- Original Message -----
> On Tue, 2013-02-19 at 10:09 -0500, Tomas Hozza wrote:
>
> > I'm using TCP because it should guarantee that my data were
> > delivered or
> > let me know there was some problem. If this is not a bug, then it
> > is at least
> > confusing for TCP.
>
> Note that a write() on a regular file descriptor has same semantic :
> By default, there is no guarantee data is written on stable storage.
>
> >
> > > To make sure data is delivered, you need additional logic.
> >
> > To be honest I didn't find any way how to get notified there was a
> > RST packet
> > sent as a reply to my previously sent data.
>
> Well, I suggest you read the man pages and some books, as this is
> well
> explained, you are not the first guy wanting to exchange data using
> TCP.
>
> man 7 socket
>
> SO_LINGER
> Sets or gets the SO_LINGER option. The argument is a
> linger structure.
>
> struct linger {
> int l_onoff; /* linger active */
> int l_linger; /* how many seconds to linger
> for */
> };
>
> When enabled, a close(2) or shutdown(2) will not return
> until all queued messages
> for the socket have been successfully sent or
> the linger timeout has been
> reached. Otherwise, the call returns immediately and
> the closing is done in the
> background. When the socket is closed as part of
> exit(2), it always lingers in
> the background.
>
> man 2 shutdown
I don't think you understood what I was asking for and this is not the right
place to discuss how to do things. I have read Unix Network Programming from
Richard Stevens but did not find answer for this either. Thanks anyway.
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Felipe Balbi @ 2013-02-19 15:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: balbi, kishon, rob, tony, linux, eballetbo, javier, gregkh, akpm,
mchehab, cesarb, davem, santosh.shilimkar, broonie, swarren,
linux-doc, linux-kernel, linux-arm-kernel, linux-omap, linux-usb,
netdev
In-Reply-To: <201302191528.17698.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]
On Tue, Feb 19, 2013 at 03:28:17PM +0000, Arnd Bergmann wrote:
> On Tuesday 19 February 2013, Felipe Balbi wrote:
> > On Tue, Feb 19, 2013 at 02:34:40PM +0000, Arnd Bergmann wrote:
> > > On Tuesday 19 February 2013, Felipe Balbi wrote:
> > > > On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:
> > > It's a fine line, but I think a phy is something that resembles a device
> > > more than an LED does. When I read patch 1, I also noticed and commented
> > > on the fact that it does use a 'class'. Now, according to Greg, we should
> > > use 'bus_type' instead of 'class' in new code. I originally disagreed with
> > > that concept, but he's the boss here and it's good if he has a vision
> > > how things should be lined out.
> > >
> > > In practice, there is little difference between a 'bus_type' and a 'class',
> > > so just replace any instance of the former with the latter in your head
> > > when reading the code ;-)
> >
> > it's not so simple :-) if we must use bus_type we need to introduce all
> > the device/driver matching mechanism which isn't necessary with a class.
>
> I think the idea is to use a bus_type that has devices but no drivers
> associated with it, but I might be misremembering things.
but then drivers wouldn't probe ever, although devices would get
created, so maybe it'll work...
> > Greg, can you pitch your suggestion here ? It would be great to hear
> > your rationale behind dropping class infrastructure, couldn't find
> > anything through Google and since feature-removal-schedule.txt has been
> > removed (without adding it to feature-removal-schedule.txt, I must add
> > :-) I don't know what's the idea behind removing classes.
>
> I believe for now, the idea is to not add any new classes, but keep
> the existing ones for compatibility. 'struct class_device' however
> was already removed and got turned into 'struct device'.
was there ever a "struct class_device".
What about struct class ?
<linux/device.h> ::
334 struct class {
335 const char *name;
336 struct module *owner;
337
338 struct class_attribute *class_attrs;
339 struct device_attribute *dev_attrs;
340 struct bin_attribute *dev_bin_attrs;
341 struct kobject *dev_kobj;
342
343 int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);
344 char *(*devnode)(struct device *dev, umode_t *mode);
345
346 void (*class_release)(struct class *class);
347 void (*dev_release)(struct device *dev);
348
349 int (*suspend)(struct device *dev, pm_message_t state);
350 int (*resume)(struct device *dev);
351
352 const struct kobj_ns_type_operations *ns_type;
353 const void *(*namespace)(struct device *dev);
354
355 const struct dev_pm_ops *pm;
356
357 struct subsys_private *p;
358 };
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Marc Kleine-Budde @ 2013-02-19 16:07 UTC (permalink / raw)
To: balbi
Cc: Arnd Bergmann, linux-usb, linux, mchehab, davem, tony, gregkh,
broonie, linux-doc, linux-kernel, kishon, eballetbo,
santosh.shilimkar, linux-arm-kernel, rob, netdev, swarren, javier,
linux-omap, akpm, cesarb
In-Reply-To: <20130219150500.GG4390@arwen.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 2875 bytes --]
On 02/19/2013 04:05 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Feb 19, 2013 at 02:34:40PM +0000, Arnd Bergmann wrote:
>> On Tuesday 19 February 2013, Felipe Balbi wrote:
>>> On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:
>>>>> Currently drivers/phy and drivers/net/phy are independent and are not
>>>>> related to each other. There are some fundamental differences on how
>>>>> these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to
>>>>> match a PHY device with a PHY driver and the Ethernet device uses the
>>>>> bus layer to get the PHY.
>>>>> The Generic PHY Framework however doesn't have any bus layer. The PHY
>>>>> should be like any other Platform Devices and Drivers and the framework
>>>>> will provide some APIs to register with the framework. And there are
>>>>> other APIs which any controller can use to get the PHY (for e.g., in the
>>>>> case of dt boot, it can use phandle to get a reference to the PHY).
>>>>
>>>> Hmm, I think the use of a bus_type for a PHY actually sounds quite
>>>> appropriate. The actual PHY device would then be a child of the
>>>
>>> really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI,
>>> UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a
>>> bit overkill IMO.
>>>
>>> Imagine an I2C-controlled PHY driver like isp1301, that driver will have
>>> to register i2c_driver and phy_driver, which looks weird to me. If the
>>> only substitute for class is a bus, we can't drop classes just yet, I'm
>>> afraid.
>>>
>>> Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make
>>> sense IMHO.
>>
>> It's a fine line, but I think a phy is something that resembles a device
>> more than an LED does. When I read patch 1, I also noticed and commented
>> on the fact that it does use a 'class'. Now, according to Greg, we should
>> use 'bus_type' instead of 'class' in new code. I originally disagreed with
>> that concept, but he's the boss here and it's good if he has a vision
>> how things should be lined out.
>>
>> In practice, there is little difference between a 'bus_type' and a 'class',
>> so just replace any instance of the former with the latter in your head
>> when reading the code ;-)
>
> it's not so simple :-) if we must use bus_type we need to introduce all
> the device/driver matching mechanism which isn't necessary with a class.
You have the code for phy <-> device matching in your framework anyway.
Using the bus infrastructure brings changes the open coded matching into
bus callbacks.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [patch net-next v5 10/11] tbf: take into account gso skbs
From: Eric Dumazet @ 2013-02-19 16:15 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <20130218095837.GA1566@minipsycho.orion>
On Mon, 2013-02-18 at 10:58 +0100, Jiri Pirko wrote:
> Sun, Feb 17, 2013 at 06:54:23PM CET, eric.dumazet@gmail.com wrote:
> >On Sun, 2013-02-17 at 17:18 +0100, Jiri Pirko wrote:
> >
> >> I'm going through this issue back and front and on the second thought,
> >> I think this patch might not be so wrong after all.
> >>
> >> "Accumulating" time in ptoks would effectively cause the skb to be sent
> >> only in case time for whole skb is available (accumulated).
> >>
> >> The re-segmenting will only cause the skb fragments sent in each time frame.
> >>
> >> I can't see how the bigger bursts you are reffering to can happen.
> >>
> >> Or am I missing something?
> >
> >Token Bucket Filter doesnt allow to accumulate tokens above a given
> >threshold. Thats the whole point of the algo.
> >
> >After a one hour idle time, you don't want to allow your device sending
> >a burst exceeding the constraint.
>
> You are right, therefore I said "not so wrong". Let me illustrate my
> thoughts. Here is a patch:
>
> Subject: [patch net-next RFC] tbf: take into account gso skbs
>
> Ignore max_size check for gso skbs. This check made bigger packets
> incorrectly dropped. Remove this limitation for gso skbs.
>
> Also for peaks, accumulate time for big gso skbs.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
I am sorry, we can not do this accumulation.
If we are allowed to send 1k per second, we are not allowed to send 10k
after 10 seconds of idle.
Either we are able to split the GSO packet, and respect the TBF
constraints, either we must drop it.
^ permalink raw reply
* Re: [PATCH v2 0/5] Generic PHY Framework
From: Felipe Balbi @ 2013-02-19 16:17 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: balbi, Arnd Bergmann, linux-usb, linux, mchehab, davem, tony,
gregkh, broonie, linux-doc, linux-kernel, kishon, eballetbo,
santosh.shilimkar, linux-arm-kernel, rob, netdev, swarren, javier,
linux-omap, akpm, cesarb
In-Reply-To: <5123A32D.4030005@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3049 bytes --]
Hi,
On Tue, Feb 19, 2013 at 05:07:09PM +0100, Marc Kleine-Budde wrote:
> On 02/19/2013 04:05 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Feb 19, 2013 at 02:34:40PM +0000, Arnd Bergmann wrote:
> >> On Tuesday 19 February 2013, Felipe Balbi wrote:
> >>> On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:
> >>>>> Currently drivers/phy and drivers/net/phy are independent and are not
> >>>>> related to each other. There are some fundamental differences on how
> >>>>> these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to
> >>>>> match a PHY device with a PHY driver and the Ethernet device uses the
> >>>>> bus layer to get the PHY.
> >>>>> The Generic PHY Framework however doesn't have any bus layer. The PHY
> >>>>> should be like any other Platform Devices and Drivers and the framework
> >>>>> will provide some APIs to register with the framework. And there are
> >>>>> other APIs which any controller can use to get the PHY (for e.g., in the
> >>>>> case of dt boot, it can use phandle to get a reference to the PHY).
> >>>>
> >>>> Hmm, I think the use of a bus_type for a PHY actually sounds quite
> >>>> appropriate. The actual PHY device would then be a child of the
> >>>
> >>> really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI,
> >>> UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a
> >>> bit overkill IMO.
> >>>
> >>> Imagine an I2C-controlled PHY driver like isp1301, that driver will have
> >>> to register i2c_driver and phy_driver, which looks weird to me. If the
> >>> only substitute for class is a bus, we can't drop classes just yet, I'm
> >>> afraid.
> >>>
> >>> Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make
> >>> sense IMHO.
> >>
> >> It's a fine line, but I think a phy is something that resembles a device
> >> more than an LED does. When I read patch 1, I also noticed and commented
> >> on the fact that it does use a 'class'. Now, according to Greg, we should
> >> use 'bus_type' instead of 'class' in new code. I originally disagreed with
> >> that concept, but he's the boss here and it's good if he has a vision
> >> how things should be lined out.
> >>
> >> In practice, there is little difference between a 'bus_type' and a 'class',
> >> so just replace any instance of the former with the latter in your head
> >> when reading the code ;-)
> >
> > it's not so simple :-) if we must use bus_type we need to introduce all
> > the device/driver matching mechanism which isn't necessary with a class.
>
> You have the code for phy <-> device matching in your framework anyway.
> Using the bus infrastructure brings changes the open coded matching into
> bus callbacks.
it's not the same thing. Current matching is just to figure out which
phy belongs to which user. The bus matching rules are to bind a device
with its driver, but that part has been taken care of by the underlying
control bus used by the phy, be it i2c, spi, or whatever else.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Marc MERLIN @ 2013-02-19 16:18 UTC (permalink / raw)
To: Johannes Berg
Cc: Eric Dumazet, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361268221.8553.1.camel@jlt4.sipsolutions.net>
On Tue, Feb 19, 2013 at 11:03:41AM +0100, Johannes Berg wrote:
> On Mon, 2013-02-18 at 21:17 -0800, Eric Dumazet wrote:
>
> > > chrome: page allocation failure: order:1, mode:0x4020
> > > Pid: 8730, comm: chrome Tainted: G O 3.7.8-amd64-preempt-20121226-fixwd #1
> > > Call Trace:
> > > <IRQ> [<ffffffff810d5f38>] warn_alloc_failed+0x117/0x12c
>
> > You could try to load iwlwifi with amsdu_size_8K set to 0 (disable)
> >
> > It should hopefully use order-0 pages
>
> It will, do that then, unfortunately it can't switch at runtime because
> it advertised this support to the access point or clients.
Forgive the newbie question: would the inability to get pages cause
interrupts to be disabled or at least something that would stop the mouse
cursor and the keyboard from working?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Eric Dumazet @ 2013-02-19 16:21 UTC (permalink / raw)
To: Johannes Berg
Cc: Marc MERLIN, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <1361268221.8553.1.camel@jlt4.sipsolutions.net>
On Tue, 2013-02-19 at 11:03 +0100, Johannes Berg wrote:
> On Mon, 2013-02-18 at 21:17 -0800, Eric Dumazet wrote:
>
> > > chrome: page allocation failure: order:1, mode:0x4020
> > > Pid: 8730, comm: chrome Tainted: G O 3.7.8-amd64-preempt-20121226-fixwd #1
> > > Call Trace:
> > > <IRQ> [<ffffffff810d5f38>] warn_alloc_failed+0x117/0x12c
>
> > You could try to load iwlwifi with amsdu_size_8K set to 0 (disable)
> >
> > It should hopefully use order-0 pages
>
> It will, do that then, unfortunately it can't switch at runtime because
> it advertised this support to the access point or clients.
What are the drawbacks of setting amsdu_size_8K to 0 by default ?
Alternative would be :
- As long as we cant allocate order-1 pages (to refill the RX ring),
copy incoming frames into order-0 pages, so that order-1 pages are still
available for the NIC.
^ permalink raw reply
* Re: 3.7.8/amd64 full interrupt hangs due to iwlwifi under big nfs copies out
From: Eric Dumazet @ 2013-02-19 16:36 UTC (permalink / raw)
To: Marc MERLIN
Cc: Johannes Berg, David Miller, Larry.Finger, bhutchings,
linux-wireless, netdev
In-Reply-To: <20130219161830.GD21764@merlins.org>
On Tue, 2013-02-19 at 08:18 -0800, Marc MERLIN wrote:
>
> Forgive the newbie question: would the inability to get pages cause
> interrupts to be disabled or at least something that would stop the mouse
> cursor and the keyboard from working?
>
Maybe these things also need order-1 pages to work ;)
Any kmem_cache using order-1 or order-2 pages can not allocate new slabs
For example, TCP sockets can not be allocated anymore, and fork() might
not work anymore (kernel stacks need order-1 pages)
I dont remember your case, but do you use CONFIG_COMPACTION=y ?
^ permalink raw reply
* Re: [patch net-next v5 10/11] tbf: take into account gso skbs
From: Jiri Pirko @ 2013-02-19 16:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <1361290502.19353.136.camel@edumazet-glaptop>
Tue, Feb 19, 2013 at 05:15:02PM CET, eric.dumazet@gmail.com wrote:
>On Mon, 2013-02-18 at 10:58 +0100, Jiri Pirko wrote:
>> Sun, Feb 17, 2013 at 06:54:23PM CET, eric.dumazet@gmail.com wrote:
>> >On Sun, 2013-02-17 at 17:18 +0100, Jiri Pirko wrote:
>> >
>> >> I'm going through this issue back and front and on the second thought,
>> >> I think this patch might not be so wrong after all.
>> >>
>> >> "Accumulating" time in ptoks would effectively cause the skb to be sent
>> >> only in case time for whole skb is available (accumulated).
>> >>
>> >> The re-segmenting will only cause the skb fragments sent in each time frame.
>> >>
>> >> I can't see how the bigger bursts you are reffering to can happen.
>> >>
>> >> Or am I missing something?
>> >
>> >Token Bucket Filter doesnt allow to accumulate tokens above a given
>> >threshold. Thats the whole point of the algo.
>> >
>> >After a one hour idle time, you don't want to allow your device sending
>> >a burst exceeding the constraint.
>>
>> You are right, therefore I said "not so wrong". Let me illustrate my
>> thoughts. Here is a patch:
>>
>> Subject: [patch net-next RFC] tbf: take into account gso skbs
>>
>> Ignore max_size check for gso skbs. This check made bigger packets
>> incorrectly dropped. Remove this limitation for gso skbs.
>>
>> Also for peaks, accumulate time for big gso skbs.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>
>I am sorry, we can not do this accumulation.
>
>If we are allowed to send 1k per second, we are not allowed to send 10k
>after 10 seconds of idle.
>
>Either we are able to split the GSO packet, and respect the TBF
>constraints, either we must drop it.
That's a shame. Would be easy this way, also applicable to act_police :/
About the gso_segment, do you see any cons doing that on enqueue path
rather than dequeue?
Thanks.
^ permalink raw reply
* Re: [patch net-next v5 10/11] tbf: take into account gso skbs
From: Eric Dumazet @ 2013-02-19 17:01 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <20130219164626.GC1506@minipsycho.orion>
On Tue, 2013-02-19 at 17:46 +0100, Jiri Pirko wrote:
> About the gso_segment, do you see any cons doing that on enqueue path
> rather than dequeue?
>
It would be fine, and could be done in core stack instead of qdisc.
netif_skb_features() for example has the following (incomplete) check
if (skb_shinfo(skb)->gso_segs > skb->dev->gso_max_segs)
features &= ~NETIF_F_GSO_MASK;
We do have a dev->gso_max_size, but its currently used in TCP stack to
size the skbs built in tcp_sendmsg().
In a forwarding workload, it seems we dont use/check gso_max_size.
^ permalink raw reply
* [PATCH] atl1c: restore buffer state
From: xiong @ 2013-02-19 17:23 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, qca-linux-team, nic-devel, jwboyer, xiong
in the previous commit : f1f220ea1dda078, the BUSY state of buffer is wrongly
deleted. this patch just restore it.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 8f33315..1f07fc6 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -2072,7 +2072,7 @@ static int atl1c_tx_map(struct atl1c_adapter *adapter,
if (unlikely(pci_dma_mapping_error(adapter->pdev,
buffer_info->dma)))
goto err_dma;
-
+ ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE,
ATL1C_PCIMAP_TODEVICE);
mapped_len += map_len;
--
1.7.11.7
^ permalink raw reply related
* [PATCH] iproute2: clearer error messages for fifo and tbf qdiscs
From: Kees van Reeuwijk @ 2013-02-19 17:46 UTC (permalink / raw)
To: netdev
From: Kees van Reeuwijk <reeuwijk@few.vu.nl>
Clearer error messages for fifo and tbf qdiscs:
- Say who is complaining
- Don't just say a parameter is bad, show the offending parameter
- Be clearer about duplicate parameters vs illegal pairs of parameters
- Try to give multiple error messages rather than let the user discover the errors one by one
- When there are parameter aliases, try to use the variant that was used, or at least mention them all
Note that in the old version an empty parameter list to tbf would just cause an explain() message
without a specific error message. By simply removing the relevant error check, the code now
handles this error more gracefully by printing an error message for all mandatory parameters.
It still prints the explain() message.
Signed-off-by: Kees van Reeuwijk <reeuwijk@few.vu.nl>
---
q_fifo.c | 4 +-
q_tbf.c | 90 ++++++++++++++++++++++++++++++++++++++------------------------
2 files changed, 57 insertions(+), 37 deletions(-)
diff --git a/tc/q_fifo.c b/tc/q_fifo.c
index 6242a98..c9ab123 100644
--- a/tc/q_fifo.c
+++ b/tc/q_fifo.c
@@ -38,7 +38,7 @@ static int fifo_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct n
if (strcmp(*argv, "limit") == 0) {
NEXT_ARG();
if (get_size(&opt.limit, *argv)) {
- fprintf(stderr, "Illegal \"limit\"\n");
+ fprintf(stderr, "%s: Illegal value for \"limit\": \"%s\"\n", qu->id, *argv);
return -1;
}
ok++;
@@ -46,7 +46,7 @@ static int fifo_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct n
explain();
return -1;
} else {
- fprintf(stderr, "What is \"%s\"?\n", *argv);
+ fprintf(stderr, "%s: unknown parameter \"%s\"\n", qu->id, *argv);
explain();
return -1;
}
diff --git a/tc/q_tbf.c b/tc/q_tbf.c
index dc556fe..034dcf3 100644
--- a/tc/q_tbf.c
+++ b/tc/q_tbf.c
@@ -30,9 +30,9 @@ static void explain(void)
fprintf(stderr, "[ overhead BYTES ] [ linklayer TYPE ]\n");
}
-static void explain1(char *arg)
+static void explain1(const char *arg, const char *val)
{
- fprintf(stderr, "Illegal \"%s\"\n", arg);
+ fprintf(stderr, "tbf: illegal value for \"%s\": \"%s\"\n", arg, val);
}
@@ -53,129 +53,149 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
while (argc > 0) {
if (matches(*argv, "limit") == 0) {
NEXT_ARG();
- if (opt.limit || latency) {
- fprintf(stderr, "Double \"limit/latency\" spec\n");
+ if (opt.limit) {
+ fprintf(stderr, "tbf: duplicate \"limit\" specification\n");
+ return -1;
+ }
+ if (latency) {
+ fprintf(stderr, "tbf: specifying both \"latency\" and \"limit\" is not allowed\n");
return -1;
}
if (get_size(&opt.limit, *argv)) {
- explain1("limit");
+ explain1("limit", *argv);
return -1;
}
ok++;
} else if (matches(*argv, "latency") == 0) {
NEXT_ARG();
- if (opt.limit || latency) {
- fprintf(stderr, "Double \"limit/latency\" spec\n");
+ if (latency) {
+ fprintf(stderr, "tbf: duplicate \"latency\" specification\n");
+ return -1;
+ }
+ if (opt.limit) {
+ fprintf(stderr, "tbf: specifying both \"limit\" and \"/latency\" is not allowed\n");
return -1;
}
if (get_time(&latency, *argv)) {
- explain1("latency");
+ explain1("latency", *argv);
return -1;
}
ok++;
} else if (matches(*argv, "burst") == 0 ||
strcmp(*argv, "buffer") == 0 ||
strcmp(*argv, "maxburst") == 0) {
+ const char *parm_name = *argv;
NEXT_ARG();
if (buffer) {
- fprintf(stderr, "Double \"buffer/burst\" spec\n");
+ fprintf(stderr, "tbf: duplicate \"buffer/burst/maxburst\" specification\n");
return -1;
}
if (get_size_and_cell(&buffer, &Rcell_log, *argv) < 0) {
- explain1("buffer");
+ explain1(parm_name, *argv);
return -1;
}
ok++;
} else if (strcmp(*argv, "mtu") == 0 ||
strcmp(*argv, "minburst") == 0) {
+ const char *parm_name = *argv;
NEXT_ARG();
if (mtu) {
- fprintf(stderr, "Double \"mtu/minburst\" spec\n");
+ fprintf(stderr, "tbf: duplicate \"mtu/minburst\" specification\n");
return -1;
}
if (get_size_and_cell(&mtu, &Pcell_log, *argv) < 0) {
- explain1("mtu");
+ explain1(parm_name, *argv);
return -1;
}
ok++;
} else if (strcmp(*argv, "mpu") == 0) {
NEXT_ARG();
if (mpu) {
- fprintf(stderr, "Double \"mpu\" spec\n");
+ fprintf(stderr, "tbf: duplicate \"mpu\" specification\n");
return -1;
}
if (get_size(&mpu, *argv)) {
- explain1("mpu");
+ explain1("mpu", *argv);
return -1;
}
ok++;
} else if (strcmp(*argv, "rate") == 0) {
NEXT_ARG();
if (opt.rate.rate) {
- fprintf(stderr, "Double \"rate\" spec\n");
+ fprintf(stderr, "tbf: duplicate \"rate\" specification\n");
return -1;
}
if (get_rate(&opt.rate.rate, *argv)) {
- explain1("rate");
+ explain1("rate", *argv);
return -1;
}
ok++;
} else if (matches(*argv, "peakrate") == 0) {
NEXT_ARG();
if (opt.peakrate.rate) {
- fprintf(stderr, "Double \"peakrate\" spec\n");
+ fprintf(stderr, "tbf: duplicate \"peakrate\" specification\n");
return -1;
}
if (get_rate(&opt.peakrate.rate, *argv)) {
- explain1("peakrate");
+ explain1("peakrate", *argv);
return -1;
}
ok++;
} else if (matches(*argv, "overhead") == 0) {
NEXT_ARG();
if (overhead) {
- fprintf(stderr, "Double \"overhead\" spec\n");
+ fprintf(stderr, "tbf: duplicate \"overhead\" specification\n");
return -1;
}
if (get_u16(&overhead, *argv, 10)) {
- explain1("overhead"); return -1;
+ explain1("overhead", *argv); return -1;
}
} else if (matches(*argv, "linklayer") == 0) {
NEXT_ARG();
if (get_linklayer(&linklayer, *argv)) {
- explain1("linklayer"); return -1;
+ explain1("linklayer", *argv); return -1;
}
} else if (strcmp(*argv, "help") == 0) {
explain();
return -1;
} else {
- fprintf(stderr, "What is \"%s\"?\n", *argv);
+ fprintf(stderr, "tbf: unknown parameter \"%s\"\n", *argv);
explain();
return -1;
}
argc--; argv++;
}
- if (!ok) {
- explain();
- return -1;
- }
+ int verdict = 0;
- if (opt.rate.rate == 0 || !buffer) {
- fprintf(stderr, "Both \"rate\" and \"burst\" are required.\n");
- return -1;
+ /* Be nice to the user: try to emit all error messages in
+ * one go rather than reveal one more problem when a
+ * previous one has been fixed.
+ */
+ if (opt.rate.rate == 0) {
+ fprintf(stderr, "tbf: the \"rate\" parameter is mandatory.\n");
+ verdict = -1;
+ }
+ if (!buffer) {
+ fprintf(stderr, "tbf: the \"burst\" parameter is mandatory.\n");
+ verdict = -1;
}
if (opt.peakrate.rate) {
if (!mtu) {
- fprintf(stderr, "\"mtu\" is required, if \"peakrate\" is requested.\n");
- return -1;
+ fprintf(stderr, "tbf: when \"peakrate\" is specified, \"mtu\" must also be specified.\n");
+ verdict = -1;
}
}
if (opt.limit == 0 && latency == 0) {
- fprintf(stderr, "Either \"limit\" or \"latency\" are required.\n");
- return -1;
+ fprintf(stderr, "tbf: either \"limit\" or \"latency\" is required.\n");
+ verdict = -1;
}
+
+ if (verdict != 0) {
+ explain();
+ return verdict;
+ }
if (opt.limit == 0) {
double lim = opt.rate.rate*(double)latency/TIME_UNITS_PER_SEC + buffer;
@@ -190,7 +210,7 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
opt.rate.mpu = mpu;
opt.rate.overhead = overhead;
if (tc_calc_rtable(&opt.rate, rtab, Rcell_log, mtu, linklayer) < 0) {
- fprintf(stderr, "TBF: failed to calculate rate table.\n");
+ fprintf(stderr, "tbf: failed to calculate rate table.\n");
return -1;
}
opt.buffer = tc_calc_xmittime(opt.rate.rate, buffer);
@@ -199,7 +219,7 @@ static int tbf_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
opt.peakrate.mpu = mpu;
opt.peakrate.overhead = overhead;
if (tc_calc_rtable(&opt.peakrate, ptab, Pcell_log, mtu, linklayer) < 0) {
- fprintf(stderr, "TBF: failed to calculate peak rate table.\n");
+ fprintf(stderr, "tbf: failed to calculate peak rate table.\n");
return -1;
}
opt.mtu = tc_calc_xmittime(opt.peakrate.rate, mtu);
^ permalink raw reply related
* Re: [PATCH net-next 2/3] tipc: byte-based overload control on socket receive queue
From: Jon Maloy @ 2013-02-19 17:54 UTC (permalink / raw)
To: Neil Horman; +Cc: Paul Gortmaker, David Miller, netdev, Ying Xue
In-Reply-To: <20130219142629.GA31871@hmsreliant.think-freely.org>
On 02/19/2013 03:26 PM, Neil Horman wrote:
> On Tue, Feb 19, 2013 at 09:07:54AM +0100, Jon Maloy wrote:
>> On 02/18/2013 09:47 AM, Neil Horman wrote:
>>> On Fri, Feb 15, 2013 at 05:57:46PM -0500, Paul Gortmaker wrote:
>>>> From: Ying Xue <ying.xue@windriver.com>
>>>>
>>>> Change overload control to be purely byte-based, using
>>>> sk->sk_rmem_alloc as byte counter, and compare it to a calculated
>>>> upper limit for the socket receive queue.
>>
>> [...]
>>
>>>> + *
>>>> + * For all connectionless messages, by default new queue limits are
>>>> + * as belows:
>>>> + *
>>>> + * TIPC_LOW_IMPORTANCE (5MB)
>>>> + * TIPC_MEDIUM_IMPORTANCE (10MB)
>>>> + * TIPC_HIGH_IMPORTANCE (20MB)
>>>> + * TIPC_CRITICAL_IMPORTANCE (40MB)
>>>> + *
>>>> + * Returns overload limit according to corresponding message importance
>>>> + */
>>>> +static unsigned int rcvbuf_limit(struct sock *sk, struct sk_buff *buf)
>>>> +{
>>>> + struct tipc_msg *msg = buf_msg(buf);
>>>> + unsigned int limit;
>>>> +
>>>> + if (msg_connected(msg))
>>>> + limit = CONN_OVERLOAD_LIMIT;
>>> This still strikes me as a bit wierd. If you really can't tolerate the default
>>> rmem settings in proc, have you considered separating the rmem and wmem values
>>> out into their own sysctls?
>>
>> Initially we tried to set this value as default for sk_rcvbuf, and then use
>> fractions of it as limits, as you suggest below. The problem we found was that
>> if we want to change this via setsockopt(SOL_SOCKET, SO_RCVBUF) the value range
>> we can use is very limited, and doesn't fit our purposes.
>>
> Can you elaborate on this please? The above doesn't really explain why you
> can't do what I suggested. Not asserting that what you say is untrue, mind you,
> I'm just trying to understand what it is about TIPC that requires such a
> specific reception buffer envelope,
There are two reasons for this.
The first one due to the message oriented nature of the flow control for
connections. Max message size is 65k, and max number of unacked messages
(at socket level, that is) before the sending process will take a break
is 1024.
So, simple maths gives that we must allow for 64MB + sk_overhead to guarantee
that a connection never is broken because of receiver overload. Contrary to TCP,
we don't have the luxury to just drop packets and expect them to be retransmitted,
because in TIPC they have already passed through the retransmission and
defragmentation layers, and are committed for delivery when they reach the
receiving socket.
You may question the wisdom of having a message oriented flow control algorithm,
but this the way it is now. We do actually have a working prototype where we
introduce purely byte-based flow control, but it is not ready for delivery yet,
and compatibility constraints will require that we still keep this high limit
in some cases.
The second reason is that TIPC provides SOCK_RDM instead of SOCK_DGRAM as its
basic datagram service. (It is the only transport service doing this afaik.)
So, the risk of having datagram messages rejected (not dropped), for any reason,
must be extremely low. ("Rejected" here means that we notify the sender when a
message cannot be delivered, we don't just silently drop it.)
Given that we also often have seen designs with many clients sending towards
one server we have empirical experience that we must have a high threshold here.
One can discuss whether 2MB or 5MB is the adequate limit for the lowest level,
we don't really now since this a new design, but we have every reason to believe
that the upper limit permitted by setsockopt(SOL_SOCK) (425,984 bytes according
to a quick test I made) is not enough for us.
> and how enforcing queue limits here is so
> important when packets could just as easily be dropped at the ip layer (with
> ostensibly no fatal failure).
There is no IP layer. TIPC and its retransmission layer sits directly on top of
L2/Ethernet. Nothing can be dropped below that layer, for obvious reasons,
and to drop anything above that layer *has* fatal consequences, because TIPC
guarantees delivery both for connection oriented and connectionless (as far as
ever possible) services.
Anyway, only the receiving socket contains the info making it possible to
select which messages to reject, in the rare cases where that becomes
unavoidable.
>
>> We did consider to introduce a separate setsockopt at TIPC level for this,
>> but thought it had a value in itself to use the mechanism that is already there.
>> Hence the "re-interpretation" of sk_rcvbuf as we do below.
>> Considering the weird doubling of this parameter that is done elsewhere in the
>> code we thought that having our own interpretation might be acceptable.
> Thats quite different IMHO. The comments in sock_setsockopt make it pretty
> clear that the doubling of the rcvbuf value is done to account for the sk_buff
> overhead of packet reception, and thats documented in the socket(7) man page.
> What you have here is the ability to set sk_rcvbuf, and then have that setting
> be ignored, but only to within several different limits, depending on various
> conditions, all of which are not visible to user space.
>
>> We did of course see the potential issue with this, that is why we cc-ed
>> you for comments.
> I appreciate that.
>
>> Now I see that David already pulled the series, so I am a little uncertain
>> about how to proceed.
> I saw that too, and asked him about this. A follow-on patch (if we wind up
> deciding one is warranted) is the way to go here.
Good. The best solution I see now, if you think the times-32 scaling is
unacceptable, would be to introduce a setsockopt() at SOL_TIPC level, and allow
for much wider limits than SOL_SOCK permits now. That we need these wider limits
is beyond doubt, as I see it.
Regards
///jon
>
> Regards
> Neil
>
^ permalink raw reply
* Re: [PATCH] b43: Increase number of RX DMA slots
From: Larry Finger @ 2013-02-19 17:57 UTC (permalink / raw)
To: David Laight
Cc: David Miller, linville, linux-wireless, netdev, bittorf, stable
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7152@saturn3.aculab.com>
On 02/19/2013 03:42 AM, David Laight wrote:
> Surely the driver should work even if all the RX buffers get filled?
> Increasing the number of buffers is just hiding the issue.
> A burst of 300 back to back small packets probably fills the 256 slots.
>
> I realise that dropping frames isn't ideal, and that small numbers
> of buffers can make it impossible to receive long fragmented IP
> messages. but increasing the number of buffers doesn't seem to
> be the best fix for a 'silent freeze'.
>
> It might be that the driver would be more robust if it only ever
> put rx buffers into all but one of the ring slots.
The real problem is that some (perhaps all) versions of the firmware, which
manages the 'in' pointer of the FIFO ring, appears to fail to detect the ring
full condition. That is the real cause of the freeze; however, we do not have
access to the firmware source. We don't even have the right to redistribute it,
which is why we have the b43-fwcutter work around.
I just reviewed about 8 months of logs on my laptop and discovered that my 2.0
GHz dual CPU system once used 59 of 64 slots. On an netbook with an Atom running
at 1.6 GHz, 109 slots were used. Clearly, the much slower CPU in a Linksys
WRT54G needs more than 64, but testing to determine how many is in progress.
Current thinking is that we will change the number of slots to 128, and add code
to the driver to detect the overflow and reset the device when it occurs. The
increased memory usage should be manageable, most systems will never hit the
condition, and the packet loss will be minimal for those that do.
Larry
^ permalink raw reply
* Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
From: David Miller @ 2013-02-19 18:06 UTC (permalink / raw)
To: Ian.Campbell; +Cc: JBeulich, drjones, xen-devel, linux-kernel, netdev
In-Reply-To: <1361264324.1051.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 19 Feb 2013 08:58:44 +0000
> On Tue, 2013-02-19 at 08:03 +0000, Jan Beulich wrote:
>> >>> On 19.02.13 at 06:53, David Miller <davem@davemloft.net> wrote:
>> > From: Andrew Jones <drjones@redhat.com>
>> > Date: Mon, 18 Feb 2013 21:29:20 +0100
>> >
>> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
>> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only
>> >> have one reference to the vif at this time, then the xenvif_put
>> >> in netbk_fatal_tx_err is one too many.
>> >>
>> >> Signed-off-by: Andrew Jones <drjones@redhat.com>
>> >
>> > Applied.
>>
>> But this is wrong from all we can tell,
>
> Yes, please can this be reverted.
Done and I've annotated the revert commit message with as much
information as possible.
^ permalink raw reply
* RE: [net-next 00/15][pull request] Intel Wired LAN Driver Updates 2013.02.16
From: Tantilov, Emil S @ 2013-02-19 18:06 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Michal Miroslaw
In-Reply-To: <20130218.123700.1507921010708117768.davem@davemloft.net>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of David Miller
>Sent: Monday, February 18, 2013 9:37 AM
>To: Kirsher, Jeffrey T
>Cc: netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
>Subject: Re: [net-next 00/15][pull request] Intel Wired LAN Driver Updates
>2013.02.16
>
>From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>Date: Sat, 16 Feb 2013 00:33:21 -0800
>
>> This series contains updates to e1000, e1000e, igb, igbvf and ixgbe.
>> The e1000, e1000e, igb and igbvf are single patch changes and the
>> remaining 11 patches are all against ixgbe.
> ...
>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>
>Pulled.
>
>I trust that Emil will work out the I2C mutex locking issues being
>discussed with Michał Mirosław wrt. patch #13.
>
>Thanks.
Thanks Dave, I will work on improving the I2C locking for sure.
Emil
^ permalink raw reply
* Re: [PATCH v5 29/45] x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Konrad Rzeszutek Wilk @ 2013-02-19 18:10 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: tglx, peterz, tj, oleg, paulmck, rusty, mingo, akpm, namhyung,
rostedt, wangyun, xiaoguangrong, rjw, sbw, fweisbec, linux,
nikunj, linux-pm, linux-arch, linux-arm-kernel, linuxppc-dev,
netdev, linux-doc, linux-kernel
In-Reply-To: <20130122074046.13822.61950.stgit@srivatsabhat.in.ibm.com>
On Tue, Jan 22, 2013 at 01:10:51PM +0530, Srivatsa S. Bhat wrote:
> Once stop_machine() is gone from the CPU offline path, we won't be able to
> depend on preempt_disable() or local_irq_disable() to prevent CPUs from
> going offline from under us.
>
> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
> while invoking from atomic context.
>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Weird. I see this in the patch but I don't see it in the header? Did you
explicitly suppress the CC part?
Anyhow, the patch looks sane enough, thought I need to to run it through
a test framework just to be on a sure side.
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
> arch/x86/xen/mmu.c | 11 +++++++++--
> arch/x86/xen/smp.c | 9 +++++++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 01de35c..6a95a15 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -39,6 +39,7 @@
> * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
> */
> #include <linux/sched.h>
> +#include <linux/cpu.h>
> #include <linux/highmem.h>
> #include <linux/debugfs.h>
> #include <linux/bug.h>
> @@ -1163,9 +1164,13 @@ static void xen_drop_mm_ref(struct mm_struct *mm)
> */
> static void xen_exit_mmap(struct mm_struct *mm)
> {
> - get_cpu(); /* make sure we don't move around */
> + /*
> + * Make sure we don't move around, and prevent CPUs from going
> + * offline.
> + */
> + get_online_cpus_atomic();
> xen_drop_mm_ref(mm);
> - put_cpu();
> + put_online_cpus_atomic();
>
> spin_lock(&mm->page_table_lock);
>
> @@ -1371,6 +1376,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
> args->op.arg2.vcpumask = to_cpumask(args->mask);
>
> /* Remove us, and any offline CPUS. */
> + get_online_cpus_atomic();
> cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
> cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));
>
> @@ -1383,6 +1389,7 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
> MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);
>
> xen_mc_issue(PARAVIRT_LAZY_MMU);
> + put_online_cpus_atomic();
> }
>
> static unsigned long xen_read_cr3(void)
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 4f7d259..7d753ae 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -16,6 +16,7 @@
> #include <linux/err.h>
> #include <linux/slab.h>
> #include <linux/smp.h>
> +#include <linux/cpu.h>
> #include <linux/irq_work.h>
>
> #include <asm/paravirt.h>
> @@ -487,8 +488,10 @@ static void __xen_send_IPI_mask(const struct cpumask *mask,
> {
> unsigned cpu;
>
> + get_online_cpus_atomic();
> for_each_cpu_and(cpu, mask, cpu_online_mask)
> xen_send_IPI_one(cpu, vector);
> + put_online_cpus_atomic();
> }
>
> static void xen_smp_send_call_function_ipi(const struct cpumask *mask)
> @@ -551,8 +554,10 @@ void xen_send_IPI_all(int vector)
> {
> int xen_vector = xen_map_vector(vector);
>
> + get_online_cpus_atomic();
> if (xen_vector >= 0)
> __xen_send_IPI_mask(cpu_online_mask, xen_vector);
> + put_online_cpus_atomic();
> }
>
> void xen_send_IPI_self(int vector)
> @@ -572,20 +577,24 @@ void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
> if (!(num_online_cpus() > 1))
> return;
>
> + get_online_cpus_atomic();
> for_each_cpu_and(cpu, mask, cpu_online_mask) {
> if (this_cpu == cpu)
> continue;
>
> xen_smp_send_call_function_single_ipi(cpu);
> }
> + put_online_cpus_atomic();
> }
>
> void xen_send_IPI_allbutself(int vector)
> {
> int xen_vector = xen_map_vector(vector);
>
> + get_online_cpus_atomic();
> if (xen_vector >= 0)
> xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vector);
> + put_online_cpus_atomic();
> }
>
> static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
>
> --
> 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] b43: Increase number of RX DMA slots
From: David Miller @ 2013-02-19 18:15 UTC (permalink / raw)
To: Larry.Finger
Cc: David.Laight, linville, linux-wireless, netdev, bittorf, stable
In-Reply-To: <5123BCFF.5090408@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Tue, 19 Feb 2013 11:57:19 -0600
> The real problem is that some (perhaps all) versions of the firmware,
> which manages the 'in' pointer of the FIFO ring, appears to fail to
> detect the ring full condition. That is the real cause of the freeze;
> however, we do not have access to the firmware source. We don't even
> have the right to redistribute it, which is why we have the
> b43-fwcutter work around.
I understand your constraints, but this is a trivially remotely
DoS'able condition even on slow CPU atom laptops.
Send an "expansive" full sized frame followed by 300 or so 64-byte UDP
packets --> instant hang.
^ permalink raw reply
* Re: [PATCH] NET/PHY: Eliminate the forced speed reduction algorithm.
From: David Miller @ 2013-02-19 18:19 UTC (permalink / raw)
To: kapranoff; +Cc: netdev, linux-kernel, romieu
In-Reply-To: <1361267628.4919.6.camel@kkk.nita.ru>
From: Kirill Kapranov <kapranoff@inbox.ru>
Date: Tue, 19 Feb 2013 13:53:48 +0400
> Tested at 2.6.38.7, applicable up to for 3.0.4.
> Signed-off-by: Kirill Kapranov <kkk@nita.ru>,<kapranoff@inbox.ru>
> --- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.000000000 +0400
> +++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.000000000 +0400
Your patches are continually poorly formatted, and corrupted by
your email client, which means that the patches cannot be applied
properly and all of our automated tools for patch tracking do not
recognize your submissions as a patch.
^ permalink raw reply
* Re: [PATCH 1/3] net: proc: fix build failed when procfs is not configured
From: David Miller @ 2013-02-19 18:19 UTC (permalink / raw)
To: gaofeng; +Cc: netdev
In-Reply-To: <1361270592-19492-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Tue, 19 Feb 2013 18:43:10 +0800
> commit d4beaa66add8aebf83ab16d2fde4e4de8dac36df
> "net: proc: change proc_net_fops_create to proc_create"
> uses proc_create to replace proc_net_fops_create, when
> CONFIG_PROC isn't configured, some build error will
> occurs.
>
> net/packet/af_packet.c: In function 'packet_net_init':
> net/packet/af_packet.c:3831:48: error: 'packet_seq_fops' undeclared (first use in this function)
> net/packet/af_packet.c:3831:48: note: each undeclared identifier is reported only once for each function it appears in
>
> There may be other build fails like above,this patch
> change proc_create from function to macros when CONFIG_PROC
> is not configured,just like what proc_net_fops_create did
> before this commit.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] net: ipv4: fix waring -Wunused-variable
From: David Miller @ 2013-02-19 18:19 UTC (permalink / raw)
To: gaofeng; +Cc: netdev
In-Reply-To: <1361270592-19492-3-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Tue, 19 Feb 2013 18:43:12 +0800
> the vars ip_rt_gc_timeout is used only when
> CONFIG_SYSCTL is selected.
>
> move these vars into CONFIG_SYSCTL.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied.
^ 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