* [patch] arcnet: fix signed bug in probe function
From: Dan Carpenter @ 2010-07-17 17:21 UTC (permalink / raw)
To: netdev; +Cc: kernel-janitors
probe_irq_off() returns the first irq found or if two irqs are found
then it returns the negative of the first irq found. We can cast
dev->irq to an int so that the test for negative values works.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/arcnet/com20020-isa.c b/drivers/net/arcnet/com20020-isa.c
index 0402da3..3727282 100644
--- a/drivers/net/arcnet/com20020-isa.c
+++ b/drivers/net/arcnet/com20020-isa.c
@@ -90,14 +90,14 @@ static int __init com20020isa_probe(struct net_device *dev)
outb(0, _INTMASK);
dev->irq = probe_irq_off(airqmask);
- if (dev->irq <= 0) {
+ if ((int)dev->irq <= 0) {
BUGMSG(D_INIT_REASONS, "Autoprobe IRQ failed first time\n");
airqmask = probe_irq_on();
outb(NORXflag, _INTMASK);
udelay(5);
outb(0, _INTMASK);
dev->irq = probe_irq_off(airqmask);
- if (dev->irq <= 0) {
+ if ((int)dev->irq <= 0) {
BUGMSG(D_NORMAL, "Autoprobe IRQ failed.\n");
err = -ENODEV;
goto out;
diff --git a/drivers/net/arcnet/com90io.c b/drivers/net/arcnet/com90io.c
index 4cb4018..eb27976 100644
--- a/drivers/net/arcnet/com90io.c
+++ b/drivers/net/arcnet/com90io.c
@@ -213,7 +213,7 @@ static int __init com90io_probe(struct net_device *dev)
outb(0, _INTMASK);
dev->irq = probe_irq_off(airqmask);
- if (dev->irq <= 0) {
+ if ((int)dev->irq <= 0) {
BUGMSG(D_INIT_REASONS, "Autoprobe IRQ failed\n");
goto err_out;
}
^ permalink raw reply related
* [PATCH 5/5] net: dccp: fix sign bug
From: Kulikov Vasiliy @ 2010-07-17 15:21 UTC (permalink / raw)
To: kernel-janitors
Cc: Arnaldo Carvalho de Melo, David S. Miller, Gerrit Renker, dccp,
netdev
'gap' is unsigned, so this code is wrong:
gap = -new_head;
...
if (gap > 0) { ... }
Make 'gap' signed.
The semantic patch that finds this problem (many false-positive results):
(http://coccinelle.lip6.fr/)
// <smpl>
@ r1 @
identifier f;
@@
int f(...) { ... }
@@
identifier r1.f;
type T;
unsigned T x;
@@
*x = f(...)
...
*x > 0
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
net/dccp/ackvec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/dccp/ackvec.c b/net/dccp/ackvec.c
index 2abddee..92a6fcb 100644
--- a/net/dccp/ackvec.c
+++ b/net/dccp/ackvec.c
@@ -201,7 +201,7 @@ static inline int dccp_ackvec_set_buf_head_state(struct dccp_ackvec *av,
const unsigned int packets,
const unsigned char state)
{
- unsigned int gap;
+ long gap;
long new_head;
if (av->av_vec_len + packets > DCCP_MAX_ACKVEC_LEN)
--
1.7.0.4
^ permalink raw reply related
* RE: [REGRESSION] e1000e stopped working [MANUALLY BISECTED]
From: Maxim Levitsky @ 2010-07-17 13:54 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, Allan, Bruce W,
Pieper, Jeffrey E
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FFE1B19CD@rrsmsx501.amr.corp.intel.com>
On Fri, 2010-07-16 at 17:23 -0600, Tantilov, Emil S wrote:
> Maxim Levitsky wrote:
> > On Thu, 2010-07-15 at 22:09 +0300, Maxim Levitsky wrote:
> >> On Thu, 2010-07-15 at 13:02 -0600, Tantilov, Emil S wrote:
> >>> Maxim Levitsky wrote:
> >>>> On Thu, 2010-07-15 at 02:33 +0300, Maxim Levitsky wrote:
> >>>>> On Wed, 2010-07-14 at 16:56 -0600, Tantilov, Emil S wrote:
> >>>>>> Maxim Levitsky wrote:
> >>>>>>> On Mon, 2010-07-12 at 15:23 -0600, Tantilov, Emil S wrote:
> >>>>>>>> Maxim Levitsky wrote:
> >>>>>>>>> On Mon, 2010-07-05 at 12:58 +0300, Maxim Levitsky wrote:
> >>>>>>>>>> On Mon, 2010-07-05 at 01:13 -0700, Jeff Kirsher wrote:
> >>>>>>>>>>> On Sun, Jul 4, 2010 at 15:48, Maxim Levitsky
> >>>>>>>>>>> <maximlevitsky@gmail.com> wrote:
> >>>>>>>>>>>> Did few guesses, and now I see that reverting the below
> >>>>>>>>>>>> commit fixes the problem.
> >>>>>>>>>>>>
> >>>>>>>>>>>> "e1000e: Fix/cleanup PHY reset code for ICHx/PCHx"
> >>>>>>>>>>>> e98cac447cc1cc418dff1d610a5c79c4f2bdec7f.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best regards,
> >>>>>>>>>>>> Maxim Levitsky
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>
> >>>>>>>>>>> Can you give us till Tuesday to respond? I know that there
> >>>>>>>>>>> are some additional e1000e patches in my queue, which may
> >>>>>>>>>>> resolve the issue, but this weekend the power is down to do
> >>>>>>>>>>> some infrastructure upgrades which prevents us from doing
> >>>>>>>>>>> any investigation.debugging until Tuesday.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Sure.
> >>>>>>>>>>
> >>>>>>>>>> Best regards,
> >>>>>>>>>> Maxim Levitsky
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Updates?
> >>>>>>>>
> >>>>>>>> We are working on reproducing the issue. So far we have not
> >>>>>>>> seen the problem when testing with net-next.
> >>>>>>>>
> >>>>>>>> I asked in previous email about some additional info from
> >>>>>>>> ethtool (-d, -e, -S) and kernel config. That would help us to
> >>>>>>>> narrow it down.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Emil
> >>>>>>> I did send -e and -d output.
> >>>>>>
> >>>>>> Sorry, looks like I lost the email with the attachements.
> >>>>>>
> >>>>>> Could you provide the output of dmesg after the failure occurs?
> >>>>>>
> >>>>>>> Since you probably want -S output during failure, I need to
> >>>>>>> recompile kernel for that. I will do that soon.
> >>>>>>>
> >>>>>>>
> >>>>>>> One question, in two weeks I hope 2.6.35 won't be released?
> >>>>>>> If so, I will have enough free time then to narrow down this
> >>>>>>> issue.
> >>>>>>>
> >>>>>>> Other solution, is to revert this commit.
> >>>>>>> (I have never seen this problem with it reverted).
> >>>>>>
> >>>>>> We have been running reboot tests on 2 separate systems with
> >>>>>> recent net-next kernels using your config and so far no luck in
> >>>>>> reproducing this issue.
> >>>>>>
> >>>>>> What is the make model of your system (or MB)?
> >>>>>
> >>>>> the motherboard is Intel DG965RY.
> >>>>>
> >>>>> However, I am using vanilla kernel.
> >>>>> net-next might contain further fixes.
> >>>>>
> >>>>> I see if net-next works here.
> >>>>
> >>>> Yep, net-next works here.
> >>>>
> >>>>
> >>>> I have the problem on vanilla kernel.
> >>>> Last revision of it, I tested is 2.6.35-rc4 exactly
> >>>> (815c4163b6c8ebf8152f42b0a5fd015cfdcedc78)
> >>>>
> >>>>
> >>>> Maybe vanilla git master works, I test it too soon.
> >>>
> >>> Thanks for the information! Good to know that this issue does not
> >>> exist in the latest branch.
> >>>
> >>> Have you by any chance tested a stable branch (2.6.34.x)?
> >>
> >> I only did test plain 2.6.34 (v2.6.34)
> > And forgot to add, that it did work.
> >
> >>
> >> Also I repeat that revert of e98cac447cc1cc418dff1d610a5c79c4f2bdec7f
> >> (e1000e: Fix/cleanup PHY reset code for ICHx/PCHx) fixes the bug on
> >> vanilla kernel.
> >>
> >> Also I just pulled latest vanilla git, and I according to diffstat I
> >> see no changes in e1000e, so its likely that bug remains there.
> >> I will test that soon.
> > Tested, broken as expected.
>
> That makes sense. Unfortunately we are still not able to reproduce even on recent pull from Linus tree.
>
> If you want - you can look at the patches for e1000e in net-next and start applying those to your tree until the issue is resolved.
>
That exactly what I will do soon.
Also I can narrow down the problem by reverting the commit partially.
After one week, I will have enough free time to do all the thing like
above. Now I have none.
> I will keep trying it here, but none of the systems we have exhibit the issue you described, so the bug could be exposed by something in your system/config.
I also think so. Otherwise, we would see more bug-reports.
You probably don't need to try anymore and reproduce that issue, because
of that.
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] Remove MAX_SOCK_ADDR constant
From: Tetsuo Handa @ 2010-07-17 12:38 UTC (permalink / raw)
To: yoshfuji, davem; +Cc: netdev
>From b976a4d6c4d2a76e3926193eba366781adcb533c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Sat, 17 Jul 2010 21:29:53 +0900
Subject: [PATCH] Remove MAX_SOCK_ADDR constant
MAX_SOCK_ADDR is no longer used because commit 230b1839 "net: Use standard
structures for generic socket address structures." replaced
"char address[MAX_SOCK_ADDR];" with "struct sockaddr_storage address;".
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
net/socket.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 367d547..2336ac5 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -170,15 +170,6 @@ static DEFINE_PER_CPU(int, sockets_in_use) = 0;
* divide and look after the messy bits.
*/
-#define MAX_SOCK_ADDR 128 /* 108 for Unix domain -
- 16 for IP, 16 for IPX,
- 24 for IPv6,
- about 80 for AX.25
- must be at least one bigger than
- the AF_UNIX size (see net/unix/af_unix.c
- :unix_mkname()).
- */
-
/**
* move_addr_to_kernel - copy a socket address into kernel space
* @uaddr: Address in user space
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()
From: Ivo Van Doorn @ 2010-07-17 10:08 UTC (permalink / raw)
To: Stephen Boyd
Cc: users, John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1279299010-4723-1-git-send-email-bebarino@gmail.com>
On Fri, Jul 16, 2010 at 6:50 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> The rt2x00dev->intf_work workqueue is never initialized when a driver is
> probed for a non-existent device (in this case rt2500usb). On such a
> path we call rt2x00lib_remove_dev() to free any resources initialized
> during the probe before we use INIT_WORK to initialize the workqueue.
> This causes lockdep to get confused since the lock used in the workqueue
> hasn't been initialized yet but is now being acquired during
> cancel_work_sync() called by rt2x00lib_remove_dev().
>
> Fix this by initializing the workqueue first before we attempt to probe
> the device. This should make lockdep happy and avoid breaking any
> assumptions about how the library cleans up after a probe fails.
>
> phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
> Call Trace:
> [<ffffffff8105fe59>] register_lock_class+0x152/0x31f
> [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111
> [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4
> [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf
> [<ffffffff81492aef>] ? _raw_spin_unlock_irqrestore+0x33/0x41
> [<ffffffff810628d5>] lock_acquire+0xd1/0xf7
> [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
> [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e
> [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
> [<ffffffff8104f136>] cancel_work_sync+0xb/0xd
> [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
> [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
> [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52
> [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb]
> [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
> [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e
> [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136
> [<ffffffff812ea167>] __driver_attach+0x4a/0x66
> [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66
> [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89
> [<ffffffff812e9efd>] driver_attach+0x19/0x1b
> [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204
> [<ffffffff812ea41b>] driver_register+0x98/0x109
> [<ffffffff813465dd>] usb_register_driver+0xb2/0x173
> [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb]
> [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb]
> [<ffffffff81000203>] do_one_initcall+0x6d/0x17a
> [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0
> [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* [PATCH NEXT 1/1] qlcnic: fix pci resource leak
From: amit.salecha @ 2010-07-17 7:39 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
pci_get_domain_bus_and_slot: caller must decrement the
reference count by calling pci_dev_put().
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 8d2d62f..f1f7acf 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -2695,9 +2695,14 @@ static int qlcnic_is_first_func(struct pci_dev *pdev)
oth_pdev = pci_get_domain_bus_and_slot(pci_domain_nr
(pdev->bus), pdev->bus->number,
PCI_DEVFN(PCI_SLOT(pdev->devfn), val));
+ if (!oth_pdev)
+ continue;
- if (oth_pdev && (oth_pdev->current_state != PCI_D3cold))
+ if (oth_pdev->current_state != PCI_D3cold) {
+ pci_dev_put(oth_pdev);
return 0;
+ }
+ pci_dev_put(oth_pdev);
}
return 1;
}
--
1.6.0.2
^ permalink raw reply related
* netfilter/iptables stopped logging 2.6.35-rc
From: auto401300 @ 2010-07-17 7:20 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Hi!
Has something broken with netfilter/iptables logging in 2.6.35-rc,
or is there something new I should set in .config since .34?
I just verified that if I boot .34 and ping the pc it does logging:
Jul 17 09:42:49 xxxxx kernel: Linux version 2.6.34-ab (root@xxxxx)
(gcc version 4.4.4 (Debian 4.4.4-1) ) #1 SMP PREEMPT Mon May 17
09:15
:15 EEST 2010
....
Jul 17 09:44:52 xxxxx kernel: DENY in: IN=eth0 OUT= MAC=xxxxx
SRC=xxxxx DST=xxxxx LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=38945
PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=256
but if I boot .35-rc4 and ping:
Jul 17 09:48:08 xxxxx kernel: Linux version 2.6.35-rc4-aa
(root@xxxxx) (gcc version 4.4.4 (Debian 4.4.4-6) ) #1 SMP PREEMPT
Mon Jul 5 15:22:02 EEST 2010
....
nothing from iptables in log
userspace is same, only booted different kernel versions
thanks.
^ permalink raw reply
* £1,000,000.00
From: Tobacco Promo @ 2010-07-17 7:11 UTC (permalink / raw)
Your Mail Id As Been Awarded £1,000,000.00 In The British Tobacco
On-line Promo:For Instant Claims Send Your Detials:
Name..
Sex..
Occupation..
location..
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: H.K. Jerry Chu @ 2010-07-17 1:23 UTC (permalink / raw)
To: Ed W; +Cc: Patrick McManus, David Miller, davidsen, linux-kernel, netdev
In-Reply-To: <4C4099D6.6020305@wildgooses.com>
On Fri, Jul 16, 2010 at 10:41 AM, Ed W <lists@wildgooses.com> wrote:
>
>> and while I'm asking for info, can you expand on the conclusion
>> regarding poor cache hit rates for reusing learned cwnds? (ok, I admit I
>> only read the slides.. maybe the paper has more info?)
>>
>
> My guess is that this result is specific to google and their servers?
>
> I guess we can probably stereotype the world into two pools of devices:
>
> 1) Devices in a pool of fast networking, but connected to the rest of the
> world through a relatively slow router
> 2) Devices connected via a high speed network and largely the bottleneck
> device is many hops down the line and well away from us
>
> I'm thinking here 1) client users behind broadband routers, wireless, 3G,
> dialup, etc and 2) public servers that have obviously been deliberately
> placed in locations with high levels of interconnectivity.
>
> I think history information could be more useful for clients in category 1)
> because there is a much higher probability that their most restrictive
> device is one hop away and hence affects all connections and relatively
> occasionally the bottleneck is multiple hops away. For devices in category
> 2) it's much harder because the restriction will usually be lots of hops
> away and effectively you are trying to figure out and cache the speed of
> every ADSL router out there... For sure you can probably figure out how to
> cluster this stuff and say that pool there is 56K dialup, that pool there is
> "broadband", that pool is cell phone, etc, but probably it's hard to do
> better than that?
>
> So my guess is this is why google have had poor results investigating cwnd
> caching?
Actually we have investigated two type of caches, a short-history limited size
internal cache that is subject to some LRU replacement policy hence
much limiting
the cache hit rate, and a long-history external cache, which provides much more
accurate cwnd history per subnet but with high complexity and
deployment headache.
Also we have set out for a much more ambitious goal, to not just speed
up our own
services, but also provide a solution that could benefit the whole web
(see http://code.google.com/speed/index.html). The latter pretty much
precludes a complex
external cache scheme mentioned above.
Jerry
>
> However, I would suggest that whilst it's of little value for the server
> side, it still remains a very interesting idea for the client side and the
> cache hit ratio would seem to be dramatically higher here?
>
>
> I haven't studied the code, but given there is a userspace ability to change
> init cwnd through the IP utility, it would seem likely that relatively
> little coding would now be required to implement some kind of limited cwnd
> caching and experiment with whether this is a valuable addition? I would
> have thought if you are only fiddling with devices behind a broadband router
> then there is little chance of you "crashing the internet" with these kind
> of experiments?
>
> Good luck
>
> Ed W
>
^ permalink raw reply
* [PATCH] LSM: Add post recvmsg() hook.
From: Tetsuo Handa @ 2010-07-17 1:17 UTC (permalink / raw)
To: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, paul.moore
Cc: netdev, linux-security-module
In-Reply-To: <20100716.123558.71592004.davem@davemloft.net>
David Miller wrote:
> From: Tetsuo Handa
> Date: Sat, 17 Jul 2010 01:14:38 +0900
>
> > Below is a patch for post recvmsg() operation. I modified the patch to call
> > skb_recv_datagram() again (for udp_recvmsg(), raw_recvmsg(), udpv6_recvmsg())
> > if LSM dicided to drop the message. (Regarding rawv6_recvmsg(), I didn't do so
> > in accordance with the comment at "csum_copy_err:".)
> > What do you think about this verion?
>
> This looks fine, but regardless of that comment I think the IPV6 raw recvmsg()
> should loop just as the IPV4 one does in your patch.
>
Thank you, David.
I updated to call skb_recv_datagram() for rawv6_recvmsg() case too.
NETWORKING [IPv4/IPv6] maintainers and Paul, is below patch fine for you?
Regards.
----------------------------------------
>From b43154a90bc7494ec1ee301e692d2bbf29c8f2f8 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Sat, 17 Jul 2010 09:52:38 +0900
Subject: [PATCH] LSM: Add post recvmsg() hook.
Current pre recvmsg hook (i.e. security_socket_recvmsg()) has two problems.
One is that it will cause eating 100% of CPU time if the caller does not
close() the socket when recvmsg() failed due to security_socket_recvmsg(), for
subsequent select() notifies the caller of readiness for recvmsg() since the
datagram which would have been already picked up if security_socket_recvmsg()
did not return error is remaining in the queue.
The other is that it is racy if LSM module wants to do filtering based on
"which process can pick up datagrams from which source" because the process
which picks up the datagram is not known until skb_recv_datagram() and lock
is not held between security_socket_recvmsg() and skb_recv_datagram().
This patch introduces post recvmsg hook (i.e. security_socket_post_recvmsg())
in order to solve above problems at the cost of ability to pick up the datagram
which would have been picked up if preceding security_socket_post_recvmsg() did
not return error.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
include/linux/security.h | 14 ++++++++++++++
net/ipv4/raw.c | 12 +++++++++---
net/ipv4/udp.c | 9 ++++++++-
net/ipv6/raw.c | 12 +++++++++---
net/ipv6/udp.c | 9 ++++++++-
security/capability.c | 6 ++++++
security/security.c | 6 ++++++
7 files changed, 60 insertions(+), 8 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 723a93d..409c44d 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -879,6 +879,12 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
* @size contains the size of message structure.
* @flags contains the operational flags.
* Return 0 if permission is granted.
+ * @socket_post_recvmsg:
+ * Check permission after receiving a message from a socket.
+ * The message is discarded if permission is not granted.
+ * @sk contains the sock structure.
+ * @skb contains the sk_buff structure.
+ * Return 0 if permission is granted.
* @socket_getsockname:
* Check permission before the local address (name) of the socket object
* @sock is retrieved.
@@ -1575,6 +1581,7 @@ struct security_operations {
struct msghdr *msg, int size);
int (*socket_recvmsg) (struct socket *sock,
struct msghdr *msg, int size, int flags);
+ int (*socket_post_recvmsg) (struct sock *sk, struct sk_buff *skb);
int (*socket_getsockname) (struct socket *sock);
int (*socket_getpeername) (struct socket *sock);
int (*socket_getsockopt) (struct socket *sock, int level, int optname);
@@ -2526,6 +2533,7 @@ int security_socket_accept(struct socket *sock, struct socket *newsock);
int security_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size);
int security_socket_recvmsg(struct socket *sock, struct msghdr *msg,
int size, int flags);
+int security_socket_post_recvmsg(struct sock *sk, struct sk_buff *skb);
int security_socket_getsockname(struct socket *sock);
int security_socket_getpeername(struct socket *sock);
int security_socket_getsockopt(struct socket *sock, int level, int optname);
@@ -2617,6 +2625,12 @@ static inline int security_socket_recvmsg(struct socket *sock,
return 0;
}
+static inline int security_socket_post_recvmsg(struct sock *sk,
+ struct sk_buff *skb)
+{
+ return 0;
+}
+
static inline int security_socket_getsockname(struct socket *sock)
{
return 0;
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 2c7a163..69652d4 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -676,9 +676,15 @@ static int raw_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto out;
}
- skb = skb_recv_datagram(sk, flags, noblock, &err);
- if (!skb)
- goto out;
+ for (;;) {
+ skb = skb_recv_datagram(sk, flags, noblock, &err);
+ if (!skb)
+ goto out;
+ err = security_socket_post_recvmsg(sk, skb);
+ if (likely(!err))
+ break;
+ skb_kill_datagram(sk, skb, flags);
+ }
copied = skb->len;
if (len < copied) {
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 5858574..9145685 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1125,6 +1125,7 @@ int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
int err;
int is_udplite = IS_UDPLITE(sk);
bool slow;
+ bool update_stat;
/*
* Check any passed addresses
@@ -1140,6 +1141,12 @@ try_again:
&peeked, &err);
if (!skb)
goto out;
+ err = security_socket_post_recvmsg(sk, skb);
+ if (err) {
+ update_stat = false;
+ goto csum_copy_err;
+ }
+ update_stat = true;
ulen = skb->len - sizeof(struct udphdr);
if (len > ulen)
@@ -1200,7 +1207,7 @@ out:
csum_copy_err:
slow = lock_sock_fast(sk);
- if (!skb_kill_datagram(sk, skb, flags))
+ if (!skb_kill_datagram(sk, skb, flags) && update_stat)
UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
unlock_sock_fast(sk, slow);
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 4a4dcbe..6915b01 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -464,9 +464,15 @@ static int rawv6_recvmsg(struct kiocb *iocb, struct sock *sk,
if (np->rxpmtu && np->rxopt.bits.rxpmtu)
return ipv6_recv_rxpmtu(sk, msg, len);
- skb = skb_recv_datagram(sk, flags, noblock, &err);
- if (!skb)
- goto out;
+ for (;;) {
+ skb = skb_recv_datagram(sk, flags, noblock, &err);
+ if (!skb)
+ goto out;
+ err = security_socket_post_recvmsg(sk, skb);
+ if (likely(!err))
+ break;
+ skb_kill_datagram(sk, skb, flags);
+ }
copied = skb->len;
if (copied > len) {
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 87be586..6cae276 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -329,6 +329,7 @@ int udpv6_recvmsg(struct kiocb *iocb, struct sock *sk,
int is_udplite = IS_UDPLITE(sk);
int is_udp4;
bool slow;
+ bool update_stat;
if (addr_len)
*addr_len=sizeof(struct sockaddr_in6);
@@ -344,6 +345,12 @@ try_again:
&peeked, &err);
if (!skb)
goto out;
+ err = security_socket_post_recvmsg(sk, skb);
+ if (err) {
+ update_stat = false;
+ goto csum_copy_err;
+ }
+ update_stat = true;
ulen = skb->len - sizeof(struct udphdr);
if (len > ulen)
@@ -426,7 +433,7 @@ out:
csum_copy_err:
slow = lock_sock_fast(sk);
- if (!skb_kill_datagram(sk, skb, flags)) {
+ if (!skb_kill_datagram(sk, skb, flags) && update_stat) {
if (is_udp4)
UDP_INC_STATS_USER(sock_net(sk),
UDP_MIB_INERRORS, is_udplite);
diff --git a/security/capability.c b/security/capability.c
index 4aeb699..709aea3 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -597,6 +597,11 @@ static int cap_socket_recvmsg(struct socket *sock, struct msghdr *msg,
return 0;
}
+static int cap_socket_post_recvmsg(struct sock *sk, struct sk_buff *skb)
+{
+ return 0;
+}
+
static int cap_socket_getsockname(struct socket *sock)
{
return 0;
@@ -1001,6 +1006,7 @@ void __init security_fixup_ops(struct security_operations *ops)
set_to_cap_if_null(ops, socket_accept);
set_to_cap_if_null(ops, socket_sendmsg);
set_to_cap_if_null(ops, socket_recvmsg);
+ set_to_cap_if_null(ops, socket_post_recvmsg);
set_to_cap_if_null(ops, socket_getsockname);
set_to_cap_if_null(ops, socket_getpeername);
set_to_cap_if_null(ops, socket_setsockopt);
diff --git a/security/security.c b/security/security.c
index e8c87b8..4291bd7 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1037,6 +1037,12 @@ int security_socket_recvmsg(struct socket *sock, struct msghdr *msg,
return security_ops->socket_recvmsg(sock, msg, size, flags);
}
+int security_socket_post_recvmsg(struct sock *sk, struct sk_buff *skb)
+{
+ return security_ops->socket_post_recvmsg(sk, skb);
+}
+EXPORT_SYMBOL(security_socket_post_recvmsg);
+
int security_socket_getsockname(struct socket *sock)
{
return security_ops->socket_getsockname(sock);
--
1.6.1
^ permalink raw reply related
* Re: Raise initial congestion window size / speedup slow start?
From: H.K. Jerry Chu @ 2010-07-17 0:36 UTC (permalink / raw)
To: Patrick McManus; +Cc: David Miller, davidsen, lists, linux-kernel, netdev
In-Reply-To: <1279299709.2156.5814.camel@tng>
On Fri, Jul 16, 2010 at 10:01 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
> On Wed, 2010-07-14 at 21:51 -0700, H.K. Jerry Chu wrote:
>> except there are indeed bugs in the code today in that the
>> code in various places assumes initcwnd as per RFC3390. So when
>> initcwnd is raised, that actual value may be limited unnecessarily by
>> the initial wmem/sk_sndbuf.
>
> Thanks for the discussion!
>
> can you tell us more about the impl concerns of initcwnd stored on the
> route?
We have found two issues when altering initcwnd through the ip route cmd:
1. initcwnd is actually capped by sndbuf (i.e., tcp_wmem[1], which is
defaulted to a small value of 16KB). This problem has been made obscured
by the TSO code, which fudges the flow control limit (and could be a bug by
itself).
2. the congestion backoff code is supposed to take inflight, rather than cwnd,
but initcwnd presents a special case. I don't fully understand the code yet to
propose a fix.
>
> and while I'm asking for info, can you expand on the conclusion
> regarding poor cache hit rates for reusing learned cwnds? (ok, I admit I
> only read the slides.. maybe the paper has more info?)
This is partly due to our load balancer policy resulting in poor cache hit,
partly due to the sheer volumes of remote clients. Some of colleagues
tried to change the host cache to a /24 subnet cache but the result wasn't
that good either (sorry I don't remember all the details.)
>
> article and slides much appreciated and very interetsing. I've long been
> of the opinion that the downsides of being too aggressive once in a
> while aren't all that serious anymore.. as someone else said in a
> non-reservation world you are always trying to predict the future anyhow
> and therefore overflowing a queue is always possible no matter how
> conservative.
Please voice your support to TCPM then :)
Jerry
>
>
>
>
>
^ permalink raw reply
* RE: [REGRESSION] e1000e stopped working [MANUALLY BISECTED]
From: Tantilov, Emil S @ 2010-07-16 23:23 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, Allan, Bruce W,
Pieper, Jeffrey E
In-Reply-To: <1279308358.3979.0.camel@localhost.localdomain>
Maxim Levitsky wrote:
> On Thu, 2010-07-15 at 22:09 +0300, Maxim Levitsky wrote:
>> On Thu, 2010-07-15 at 13:02 -0600, Tantilov, Emil S wrote:
>>> Maxim Levitsky wrote:
>>>> On Thu, 2010-07-15 at 02:33 +0300, Maxim Levitsky wrote:
>>>>> On Wed, 2010-07-14 at 16:56 -0600, Tantilov, Emil S wrote:
>>>>>> Maxim Levitsky wrote:
>>>>>>> On Mon, 2010-07-12 at 15:23 -0600, Tantilov, Emil S wrote:
>>>>>>>> Maxim Levitsky wrote:
>>>>>>>>> On Mon, 2010-07-05 at 12:58 +0300, Maxim Levitsky wrote:
>>>>>>>>>> On Mon, 2010-07-05 at 01:13 -0700, Jeff Kirsher wrote:
>>>>>>>>>>> On Sun, Jul 4, 2010 at 15:48, Maxim Levitsky
>>>>>>>>>>> <maximlevitsky@gmail.com> wrote:
>>>>>>>>>>>> Did few guesses, and now I see that reverting the below
>>>>>>>>>>>> commit fixes the problem.
>>>>>>>>>>>>
>>>>>>>>>>>> "e1000e: Fix/cleanup PHY reset code for ICHx/PCHx"
>>>>>>>>>>>> e98cac447cc1cc418dff1d610a5c79c4f2bdec7f.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Maxim Levitsky
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Can you give us till Tuesday to respond? I know that there
>>>>>>>>>>> are some additional e1000e patches in my queue, which may
>>>>>>>>>>> resolve the issue, but this weekend the power is down to do
>>>>>>>>>>> some infrastructure upgrades which prevents us from doing
>>>>>>>>>>> any investigation.debugging until Tuesday.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Maxim Levitsky
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Updates?
>>>>>>>>
>>>>>>>> We are working on reproducing the issue. So far we have not
>>>>>>>> seen the problem when testing with net-next.
>>>>>>>>
>>>>>>>> I asked in previous email about some additional info from
>>>>>>>> ethtool (-d, -e, -S) and kernel config. That would help us to
>>>>>>>> narrow it down.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Emil
>>>>>>> I did send -e and -d output.
>>>>>>
>>>>>> Sorry, looks like I lost the email with the attachements.
>>>>>>
>>>>>> Could you provide the output of dmesg after the failure occurs?
>>>>>>
>>>>>>> Since you probably want -S output during failure, I need to
>>>>>>> recompile kernel for that. I will do that soon.
>>>>>>>
>>>>>>>
>>>>>>> One question, in two weeks I hope 2.6.35 won't be released?
>>>>>>> If so, I will have enough free time then to narrow down this
>>>>>>> issue.
>>>>>>>
>>>>>>> Other solution, is to revert this commit.
>>>>>>> (I have never seen this problem with it reverted).
>>>>>>
>>>>>> We have been running reboot tests on 2 separate systems with
>>>>>> recent net-next kernels using your config and so far no luck in
>>>>>> reproducing this issue.
>>>>>>
>>>>>> What is the make model of your system (or MB)?
>>>>>
>>>>> the motherboard is Intel DG965RY.
>>>>>
>>>>> However, I am using vanilla kernel.
>>>>> net-next might contain further fixes.
>>>>>
>>>>> I see if net-next works here.
>>>>
>>>> Yep, net-next works here.
>>>>
>>>>
>>>> I have the problem on vanilla kernel.
>>>> Last revision of it, I tested is 2.6.35-rc4 exactly
>>>> (815c4163b6c8ebf8152f42b0a5fd015cfdcedc78)
>>>>
>>>>
>>>> Maybe vanilla git master works, I test it too soon.
>>>
>>> Thanks for the information! Good to know that this issue does not
>>> exist in the latest branch.
>>>
>>> Have you by any chance tested a stable branch (2.6.34.x)?
>>
>> I only did test plain 2.6.34 (v2.6.34)
> And forgot to add, that it did work.
>
>>
>> Also I repeat that revert of e98cac447cc1cc418dff1d610a5c79c4f2bdec7f
>> (e1000e: Fix/cleanup PHY reset code for ICHx/PCHx) fixes the bug on
>> vanilla kernel.
>>
>> Also I just pulled latest vanilla git, and I according to diffstat I
>> see no changes in e1000e, so its likely that bug remains there.
>> I will test that soon.
> Tested, broken as expected.
That makes sense. Unfortunately we are still not able to reproduce even on recent pull from Linus tree.
If you want - you can look at the patches for e1000e in net-next and start applying those to your tree until the issue is resolved.
I will keep trying it here, but none of the systems we have exhibit the issue you described, so the bug could be exposed by something in your system/config.
Thanks,
Emil
^ permalink raw reply
* RE: 2.6.34.1: kernel warning at igb_main.c:2080
From: Wyborny, Carolyn @ 2010-07-16 22:45 UTC (permalink / raw)
To: Ben Greear, NetDev
In-Reply-To: <4C3FA03E.9090802@candelatech.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org
>[mailto:netdev-owner@vger.kernel.org] On Behalf Of Ben Greear
>Sent: Thursday, July 15, 2010 4:57 PM
>To: NetDev
>Subject: igb: 2.6.34.1: kernel warning at igb_main.c:2080
>
>We just saw this kernel warning on 2.6.34.1 + a few patches
>from the pending stable queue,
>plus our own hacks (though none to igb).
>
>We were running a modified version of pktgen traffic and at
>the same time
>bounced the port.
>
>This warning didn't seem to cause any real problems.
>
>Please let us know if you would like any additional information.
>
>]# lspci|grep Ethern
>01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>Network Connection
>02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>Network Connection
>05:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>05:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>06:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>06:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>
>
>Jul 15 16:36:01 localhost kernel: ------------[ cut here ]------------
>Jul 15 16:36:01 localhost kernel: WARNING: at
>/home/greearb/git/linux-2.6.dev.34.y/drivers/net/igb/igb_main.c
>:2080 igb_close+0x28/0x9f [igb]()
>Jul 15 16:36:01 localhost kernel: Hardware name: X8STi
>Jul 15 16:36:01 localhost kernel: Modules linked in: bridge
>arc4 michael_mic wanlink(P) 8021q garp xt_CT iptable_raw
>ipt_addrtype xt_DSCP xt_dscp xt_string
>xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange
>xt_hashlimit xt_CONNMARK xt_connmark stp llc veth fuse macvlan
>bpctl_mod pktgen iscsi_tcp libiscsi_tcp
>libiscsi scsi_transport_iscsi nfs lockd fscache nfs_acl
>auth_rpcgss sunrpc ipv6 dm_multipath uinput i2c_i801 iTCO_wdt
>i2c_core ioatdma e1000e igb pcspkr
>iTCO_vendor_support dca ata_generic pata_acpi [last unloaded: nf_nat]
>Jul 15 16:36:01 localhost kernel: Pid: 17516, comm: ip
>Tainted: P 2.6.34.1 #2
>Jul 15 16:36:01 localhost kernel: Call Trace:
>Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>] ?
>igb_close+0x28/0x9f [igb]
>Jul 15 16:36:01 localhost kernel: [<ffffffff81041bb6>]
>warn_slowpath_common+0x77/0x8f
>Jul 15 16:36:01 localhost kernel: [<ffffffff81041bdd>]
>warn_slowpath_null+0xf/0x11
>Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>]
>igb_close+0x28/0x9f [igb]
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133c626>]
>__dev_close+0x73/0x86
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133a719>]
>__dev_change_flags+0xa8/0x12b
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133c2aa>]
>dev_change_flags+0x1c/0x51
>Jul 15 16:36:01 localhost kernel: [<ffffffff813466bc>]
>do_setlink+0x273/0x482
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ab1bb>] ?
>zone_statistics+0x5e/0x63
>Jul 15 16:36:01 localhost kernel: [<ffffffff8134755e>]
>rtnl_newlink+0x26c/0x422
>Jul 15 16:36:01 localhost kernel: [<ffffffff81345a06>] ?
>nla_nest_start+0x1d/0x31
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ca997>] ?
>virt_to_head_page+0x9/0x2a
>Jul 15 16:36:01 localhost kernel: [<ffffffff813dd1f5>] ?
>__mutex_lock_common+0x38e/0x3ac
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346ffb>]
>rtnetlink_rcv_msg+0x1d9/0x1f7
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346e22>] ?
>rtnetlink_rcv_msg+0x0/0x1f7
>Jul 15 16:36:01 localhost kernel: [<ffffffff81356939>]
>netlink_rcv_skb+0x3e/0x8e
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346cc9>]
>rtnetlink_rcv+0x20/0x29
>Jul 15 16:36:01 localhost kernel: [<ffffffff813567b2>]
>netlink_unicast+0xea/0x151
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133545c>] ?
>memcpy_fromiovec+0x42/0x73
>Jul 15 16:36:01 localhost kernel: [<ffffffff81357bc8>]
>netlink_sendmsg+0x242/0x255
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132a771>] ?
>__sock_recvmsg_nosec+0x29/0x2b
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132bd02>]
>__sock_sendmsg+0x56/0x5f
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132c127>]
>sock_sendmsg+0xa3/0xbc
>Jul 15 16:36:01 localhost kernel: [<ffffffff813351e5>] ?
>copy_from_user+0x28/0x30
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133555e>] ?
>verify_iovec+0x52/0x95
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132c368>]
>sys_sendmsg+0x1c6/0x22a
>Jul 15 16:36:01 localhost kernel: [<ffffffff810a277f>] ?
>lru_cache_add_lru+0x38/0x3d
>Jul 15 16:36:01 localhost kernel: [<ffffffff813de23e>] ?
>_raw_spin_unlock+0x2d/0x38
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ad802>] ?
>spin_unlock+0x9/0xb
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b0138>] ?
>handle_mm_fault+0x6d3/0x6f3
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b3a0a>] ?
>__vma_link_rb+0x2b/0x2d
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b45f7>] ?
>vma_link+0xcd/0xcf
>Jul 15 16:36:01 localhost kernel: [<ffffffff810d9369>] ?
>fget_light+0x39/0x87
>Jul 15 16:36:01 localhost kernel: [<ffffffff81083b91>] ?
>audit_syscall_entry+0xfe/0x12a
>Jul 15 16:36:01 localhost kernel: [<ffffffff81009ac2>]
>system_call_fastpath+0x16/0x1b
>Jul 15 16:36:01 localhost kernel: ---[ end trace 75242fae6dbfdf6d ]---
>
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks, I'll take a look at it.
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH] Drivers: net: 8139cp: Improved conformance to the Linux coding style guidelines.
From: Jeff Garzik @ 2010-07-16 21:40 UTC (permalink / raw)
To: Joseph Kogut; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1279286391-31464-1-git-send-email-joseph.kogut@gmail.com>
On 07/16/2010 09:19 AM, Joseph Kogut wrote:
> Fixed several issues that made the 8139C+ driver nonconformant to the Linux coding style guidelines.
>
> Signed-off-by: Joseph Kogut<joseph.kogut@gmail.com>
> ---
> drivers/net/8139cp.c | 304 +++++++++++++++++++++++++-------------------------
> 1 files changed, 153 insertions(+), 151 deletions(-)
This patch is still failing in places to recognize obvious intent of the
code writer.
> /*
> Copyright 2001-2004 Jeff Garzik<jgarzik@pobox.com>
>
> - Copyright (C) 2001, 2002 David S. Miller (davem@redhat.com) [tg3.c]
> - Copyright (C) 2000, 2001 David S. Miller (davem@redhat.com) [sungem.c]
> - Copyright 2001 Manfred Spraul [natsemi.c]
> - Copyright 1999-2001 by Donald Becker. [natsemi.c]
> - Written 1997-2001 by Donald Becker. [8139too.c]
> - Copyright 1998-2001 by Jes Sorensen,<jes@trained-monkey.org>. [acenic.c]
> + Copyright (C) 2001, 2002 David S. Miller (davem@redhat.com) [tg3.c]
> + Copyright (C) 2000, 2001 David S. Miller (davem@redhat.com) [sungem.c]
> + Copyright 2001 Manfred Spraul [natsemi.c]
> + Copyright 1999-2001 by Donald Becker. [natsemi.c]
> + Written 1997-2001 by Donald Becker. [8139too.c]
> + Copyright 1998-2001 by Jes Sorensen,<jes@trained-monkey.org>. [acenic.c]
what is the point of this? I would leave copyright messages as-is.
> @@ -1295,32 +1295,32 @@ static void mdio_write(struct net_device *dev, int phy_id, int location,
> }
>
> /* Set the ethtool Wake-on-LAN settings */
> -static int netdev_set_wol (struct cp_private *cp,
> +static int netdev_set_wol(struct cp_private *cp,
> const struct ethtool_wolinfo *wol)
> {
> u8 options;
>
> - options = cpr8 (Config3)& ~(LinkUp | MagicPacket);
> + options = cpr8(Config3)& ~(LinkUp | MagicPacket);
> /* If WOL is being disabled, no need for complexity */
> if (wol->wolopts) {
> - if (wol->wolopts& WAKE_PHY) options |= LinkUp;
> - if (wol->wolopts& WAKE_MAGIC) options |= MagicPacket;
> + if (wol->wolopts& WAKE_PHY) options |= LinkUp;
> + if (wol->wolopts& WAKE_MAGIC) options |= MagicPacket;
> }
>
> - cpw8 (Cfg9346, Cfg9346_Unlock);
> - cpw8 (Config3, options);
> - cpw8 (Cfg9346, Cfg9346_Lock);
> + cpw8(Cfg9346, Cfg9346_Unlock);
> + cpw8(Config3, options);
> + cpw8(Cfg9346, Cfg9346_Lock);
>
> options = 0; /* Paranoia setting */
> - options = cpr8 (Config5)& ~(UWF | MWF | BWF);
> + options = cpr8(Config5)& ~(UWF | MWF | BWF);
> /* If WOL is being disabled, no need for complexity */
> if (wol->wolopts) {
> - if (wol->wolopts& WAKE_UCAST) options |= UWF;
> - if (wol->wolopts& WAKE_BCAST) options |= BWF;
> - if (wol->wolopts& WAKE_MCAST) options |= MWF;
> + if (wol->wolopts& WAKE_UCAST) options |= UWF;
> + if (wol->wolopts& WAKE_BCAST) options |= BWF;
> + if (wol->wolopts& WAKE_MCAST) options |= MWF;
> }
you just un-aligned things that were nicely tab-aligned
> @@ -1328,35 +1328,36 @@ static int netdev_set_wol (struct cp_private *cp,
> }
>
> /* Get the ethtool Wake-on-LAN settings */
> -static void netdev_get_wol (struct cp_private *cp,
> - struct ethtool_wolinfo *wol)
> +static void netdev_get_wol(struct cp_private *cp,
> + struct ethtool_wolinfo *wol)
> {
> u8 options;
>
> wol->wolopts = 0; /* Start from scratch */
> - wol->supported = WAKE_PHY | WAKE_BCAST | WAKE_MAGIC |
> - WAKE_MCAST | WAKE_UCAST;
> + wol->supported = WAKE_PHY | WAKE_BCAST | WAKE_MAGIC | WAKE_MCAST | WAKE_UCAST;
> +
> /* We don't need to go on if WOL is disabled */
> - if (!cp->wol_enabled) return;
> + if (!cp->wol_enabled)
> + return;
>
> - options = cpr8 (Config3);
> - if (options & LinkUp) wol->wolopts |= WAKE_PHY;
> - if (options & MagicPacket) wol->wolopts |= WAKE_MAGIC;
> + options = cpr8(Config3);
> + if (options & LinkUp) wol->wolopts |= WAKE_PHY;
> + if (options & MagicPacket) wol->wolopts |= WAKE_MAGIC;
>
> options = 0; /* Paranoia setting */
> - options = cpr8 (Config5);
> - if (options & UWF) wol->wolopts |= WAKE_UCAST;
> - if (options & BWF) wol->wolopts |= WAKE_BCAST;
> - if (options & MWF) wol->wolopts |= WAKE_MCAST;
> + options = cpr8(Config5);
> + if (options & UWF) wol->wolopts |= WAKE_UCAST;
> + if (options & BWF) wol->wolopts |= WAKE_BCAST;
> + if (options & MWF) wol->wolopts |= WAKE_MCAST;
> }
>
> -static void cp_get_drvinfo (struct net_device *dev, struct ethtool_drvinfo *info)
ditto
Also, it's disappointing to see so much diff noise created by
s/func ()/func()/
but I don't suppose I'll win that battle.
Jeff
^ permalink raw reply
* Re: [PATCH 2/2] bnx2: use device model DMA API
From: Michael Chan @ 2010-07-16 21:29 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100715142544.12504.283.send-patch@dhcp-lab-109.englab.brq.redhat.com>
On Thu, 2010-07-15 at 07:25 -0700, Stanislaw Gruszka wrote:
> Use DMA API as PCI equivalents will be deprecated. This change also allow
> to allocate with GFP_KERNEL in some places.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/bnx2.c | 111 +++++++++++++++++++++++++++-------------------------
> 1 files changed, 58 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index 6de4cb7..98aed05 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -692,9 +692,9 @@ bnx2_free_tx_mem(struct bnx2 *bp)
> struct bnx2_tx_ring_info *txr = &bnapi->tx_ring;
>
> if (txr->tx_desc_ring) {
> - pci_free_consistent(bp->pdev, TXBD_RING_SIZE,
> - txr->tx_desc_ring,
> - txr->tx_desc_mapping);
> + dma_free_coherent(&bp->pdev->dev, TXBD_RING_SIZE,
> + txr->tx_desc_ring,
> + txr->tx_desc_mapping);
> txr->tx_desc_ring = NULL;
> }
> kfree(txr->tx_buf_ring);
> @@ -714,9 +714,9 @@ bnx2_free_rx_mem(struct bnx2 *bp)
>
> for (j = 0; j < bp->rx_max_ring; j++) {
> if (rxr->rx_desc_ring[j])
> - pci_free_consistent(bp->pdev, RXBD_RING_SIZE,
> - rxr->rx_desc_ring[j],
> - rxr->rx_desc_mapping[j]);
> + dma_free_coherent(&bp->pdev->dev, RXBD_RING_SIZE,
> + rxr->rx_desc_ring[j],
> + rxr->rx_desc_mapping[j]);
> rxr->rx_desc_ring[j] = NULL;
> }
> vfree(rxr->rx_buf_ring);
> @@ -724,9 +724,9 @@ bnx2_free_rx_mem(struct bnx2 *bp)
>
> for (j = 0; j < bp->rx_max_pg_ring; j++) {
> if (rxr->rx_pg_desc_ring[j])
> - pci_free_consistent(bp->pdev, RXBD_RING_SIZE,
> - rxr->rx_pg_desc_ring[j],
> - rxr->rx_pg_desc_mapping[j]);
> + dma_free_coherent(&bp->pdev->dev, RXBD_RING_SIZE,
> + rxr->rx_pg_desc_ring[j],
> + rxr->rx_pg_desc_mapping[j]);
> rxr->rx_pg_desc_ring[j] = NULL;
> }
> vfree(rxr->rx_pg_ring);
> @@ -748,8 +748,8 @@ bnx2_alloc_tx_mem(struct bnx2 *bp)
> return -ENOMEM;
>
> txr->tx_desc_ring =
> - pci_alloc_consistent(bp->pdev, TXBD_RING_SIZE,
> - &txr->tx_desc_mapping);
> + dma_alloc_coherent(&bp->pdev->dev, TXBD_RING_SIZE,
> + &txr->tx_desc_mapping, GFP_KERNEL);
> if (txr->tx_desc_ring == NULL)
> return -ENOMEM;
> }
> @@ -776,8 +776,10 @@ bnx2_alloc_rx_mem(struct bnx2 *bp)
>
> for (j = 0; j < bp->rx_max_ring; j++) {
> rxr->rx_desc_ring[j] =
> - pci_alloc_consistent(bp->pdev, RXBD_RING_SIZE,
> - &rxr->rx_desc_mapping[j]);
> + dma_alloc_coherent(&bp->pdev->dev,
> + RXBD_RING_SIZE,
> + &rxr->rx_desc_mapping[j],
> + GFP_KERNEL);
> if (rxr->rx_desc_ring[j] == NULL)
> return -ENOMEM;
>
> @@ -795,8 +797,10 @@ bnx2_alloc_rx_mem(struct bnx2 *bp)
>
> for (j = 0; j < bp->rx_max_pg_ring; j++) {
> rxr->rx_pg_desc_ring[j] =
> - pci_alloc_consistent(bp->pdev, RXBD_RING_SIZE,
> - &rxr->rx_pg_desc_mapping[j]);
> + dma_alloc_coherent(&bp->pdev->dev,
> + RXBD_RING_SIZE,
> + &rxr->rx_pg_desc_mapping[j],
> + GFP_KERNEL);
> if (rxr->rx_pg_desc_ring[j] == NULL)
> return -ENOMEM;
>
> @@ -816,16 +820,16 @@ bnx2_free_mem(struct bnx2 *bp)
>
> for (i = 0; i < bp->ctx_pages; i++) {
> if (bp->ctx_blk[i]) {
> - pci_free_consistent(bp->pdev, BCM_PAGE_SIZE,
> - bp->ctx_blk[i],
> - bp->ctx_blk_mapping[i]);
> + dma_free_coherent(&bp->pdev->dev, BCM_PAGE_SIZE,
> + bp->ctx_blk[i],
> + bp->ctx_blk_mapping[i]);
> bp->ctx_blk[i] = NULL;
> }
> }
> if (bnapi->status_blk.msi) {
> - pci_free_consistent(bp->pdev, bp->status_stats_size,
> - bnapi->status_blk.msi,
> - bp->status_blk_mapping);
> + dma_free_coherent(&bp->pdev->dev, bp->status_stats_size,
> + bnapi->status_blk.msi,
> + bp->status_blk_mapping);
> bnapi->status_blk.msi = NULL;
> bp->stats_blk = NULL;
> }
> @@ -846,8 +850,8 @@ bnx2_alloc_mem(struct bnx2 *bp)
> bp->status_stats_size = status_blk_size +
> sizeof(struct statistics_block);
>
> - status_blk = pci_alloc_consistent(bp->pdev, bp->status_stats_size,
> - &bp->status_blk_mapping);
> + status_blk = dma_alloc_coherent(&bp->pdev->dev, bp->status_stats_size,
> + &bp->status_blk_mapping, GFP_KERNEL);
> if (status_blk == NULL)
> goto alloc_mem_err;
>
> @@ -885,9 +889,10 @@ bnx2_alloc_mem(struct bnx2 *bp)
> if (bp->ctx_pages == 0)
> bp->ctx_pages = 1;
> for (i = 0; i < bp->ctx_pages; i++) {
> - bp->ctx_blk[i] = pci_alloc_consistent(bp->pdev,
> + bp->ctx_blk[i] = dma_alloc_coherent(&bp->pdev->dev,
> BCM_PAGE_SIZE,
> - &bp->ctx_blk_mapping[i]);
> + &bp->ctx_blk_mapping[i],
> + GFP_KERNEL);
> if (bp->ctx_blk[i] == NULL)
> goto alloc_mem_err;
> }
> @@ -2674,9 +2679,9 @@ bnx2_alloc_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gf
>
> if (!page)
> return -ENOMEM;
> - mapping = pci_map_page(bp->pdev, page, 0, PAGE_SIZE,
> + mapping = dma_map_page(&bp->pdev->dev, page, 0, PAGE_SIZE,
> PCI_DMA_FROMDEVICE);
> - if (pci_dma_mapping_error(bp->pdev, mapping)) {
> + if (dma_mapping_error(&bp->pdev->dev, mapping)) {
> __free_page(page);
> return -EIO;
> }
> @@ -2697,8 +2702,8 @@ bnx2_free_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
> if (!page)
> return;
>
> - pci_unmap_page(bp->pdev, dma_unmap_addr(rx_pg, mapping), PAGE_SIZE,
> - PCI_DMA_FROMDEVICE);
> + dma_unmap_page(&bp->pdev->dev, dma_unmap_addr(rx_pg, mapping),
> + PAGE_SIZE, PCI_DMA_FROMDEVICE);
>
> __free_page(page);
> rx_pg->page = NULL;
> @@ -2721,9 +2726,9 @@ bnx2_alloc_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gfp
> if (unlikely((align = (unsigned long) skb->data & (BNX2_RX_ALIGN - 1))))
> skb_reserve(skb, BNX2_RX_ALIGN - align);
>
> - mapping = pci_map_single(bp->pdev, skb->data, bp->rx_buf_use_size,
> - PCI_DMA_FROMDEVICE);
> - if (pci_dma_mapping_error(bp->pdev, mapping)) {
> + mapping = dma_map_single(&bp->pdev->dev, skb->data, bp->rx_buf_use_size,
> + PCI_DMA_FROMDEVICE);
> + if (dma_mapping_error(&bp->pdev->dev, mapping)) {
> dev_kfree_skb(skb);
> return -EIO;
> }
> @@ -2829,7 +2834,7 @@ bnx2_tx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
> }
> }
>
> - pci_unmap_single(bp->pdev, dma_unmap_addr(tx_buf, mapping),
> + dma_unmap_single(&bp->pdev->dev, dma_unmap_addr(tx_buf, mapping),
> skb_headlen(skb), PCI_DMA_TODEVICE);
>
> tx_buf->skb = NULL;
> @@ -2838,7 +2843,7 @@ bnx2_tx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
> for (i = 0; i < last; i++) {
> sw_cons = NEXT_TX_BD(sw_cons);
>
> - pci_unmap_page(bp->pdev,
> + dma_unmap_page(&bp->pdev->dev,
> dma_unmap_addr(
> &txr->tx_buf_ring[TX_RING_IDX(sw_cons)],
> mapping),
> @@ -2945,7 +2950,7 @@ bnx2_reuse_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr,
> cons_rx_buf = &rxr->rx_buf_ring[cons];
> prod_rx_buf = &rxr->rx_buf_ring[prod];
>
> - pci_dma_sync_single_for_device(bp->pdev,
> + dma_sync_single_for_device(&bp->pdev->dev,
> dma_unmap_addr(cons_rx_buf, mapping),
> BNX2_RX_OFFSET + BNX2_RX_COPY_THRESH, PCI_DMA_FROMDEVICE);
>
> @@ -2987,7 +2992,7 @@ bnx2_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, struct sk_buff *skb,
> }
>
> skb_reserve(skb, BNX2_RX_OFFSET);
> - pci_unmap_single(bp->pdev, dma_addr, bp->rx_buf_use_size,
> + dma_unmap_single(&bp->pdev->dev, dma_addr, bp->rx_buf_use_size,
> PCI_DMA_FROMDEVICE);
>
> if (hdr_len == 0) {
> @@ -3049,7 +3054,7 @@ bnx2_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, struct sk_buff *skb,
> return err;
> }
>
> - pci_unmap_page(bp->pdev, mapping_old,
> + dma_unmap_page(&bp->pdev->dev, mapping_old,
> PAGE_SIZE, PCI_DMA_FROMDEVICE);
>
> frag_size -= frag_len;
> @@ -3120,7 +3125,7 @@ bnx2_rx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
>
> dma_addr = dma_unmap_addr(rx_buf, mapping);
>
> - pci_dma_sync_single_for_cpu(bp->pdev, dma_addr,
> + dma_sync_single_for_cpu(&bp->pdev->dev, dma_addr,
> BNX2_RX_OFFSET + BNX2_RX_COPY_THRESH,
> PCI_DMA_FROMDEVICE);
>
> @@ -5338,7 +5343,7 @@ bnx2_free_tx_skbs(struct bnx2 *bp)
> continue;
> }
>
> - pci_unmap_single(bp->pdev,
> + dma_unmap_single(&bp->pdev->dev,
> dma_unmap_addr(tx_buf, mapping),
> skb_headlen(skb),
> PCI_DMA_TODEVICE);
> @@ -5349,7 +5354,7 @@ bnx2_free_tx_skbs(struct bnx2 *bp)
> j++;
> for (k = 0; k < last; k++, j++) {
> tx_buf = &txr->tx_buf_ring[TX_RING_IDX(j)];
> - pci_unmap_page(bp->pdev,
> + dma_unmap_page(&bp->pdev->dev,
> dma_unmap_addr(tx_buf, mapping),
> skb_shinfo(skb)->frags[k].size,
> PCI_DMA_TODEVICE);
> @@ -5379,7 +5384,7 @@ bnx2_free_rx_skbs(struct bnx2 *bp)
> if (skb == NULL)
> continue;
>
> - pci_unmap_single(bp->pdev,
> + dma_unmap_single(&bp->pdev->dev,
> dma_unmap_addr(rx_buf, mapping),
> bp->rx_buf_use_size,
> PCI_DMA_FROMDEVICE);
> @@ -5732,9 +5737,9 @@ bnx2_run_loopback(struct bnx2 *bp, int loopback_mode)
> for (i = 14; i < pkt_size; i++)
> packet[i] = (unsigned char) (i & 0xff);
>
> - map = pci_map_single(bp->pdev, skb->data, pkt_size,
> - PCI_DMA_TODEVICE);
> - if (pci_dma_mapping_error(bp->pdev, map)) {
> + map = dma_map_single(&bp->pdev->dev, skb->data, pkt_size,
> + PCI_DMA_TODEVICE);
> + if (dma_mapping_error(&bp->pdev->dev, map)) {
> dev_kfree_skb(skb);
> return -EIO;
> }
> @@ -5772,7 +5777,7 @@ bnx2_run_loopback(struct bnx2 *bp, int loopback_mode)
>
> udelay(5);
>
> - pci_unmap_single(bp->pdev, map, pkt_size, PCI_DMA_TODEVICE);
> + dma_unmap_single(&bp->pdev->dev, map, pkt_size, PCI_DMA_TODEVICE);
> dev_kfree_skb(skb);
>
> if (bnx2_get_hw_tx_cons(tx_napi) != txr->tx_prod)
> @@ -5789,7 +5794,7 @@ bnx2_run_loopback(struct bnx2 *bp, int loopback_mode)
> rx_hdr = rx_buf->desc;
> skb_reserve(rx_skb, BNX2_RX_OFFSET);
>
> - pci_dma_sync_single_for_cpu(bp->pdev,
> + dma_sync_single_for_cpu(&bp->pdev->dev,
> dma_unmap_addr(rx_buf, mapping),
> bp->rx_buf_size, PCI_DMA_FROMDEVICE);
>
> @@ -6457,8 +6462,8 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device *dev)
> } else
> mss = 0;
>
> - mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE);
> - if (pci_dma_mapping_error(bp->pdev, mapping)) {
> + mapping = dma_map_single(&bp->pdev->dev, skb->data, len, PCI_DMA_TODEVICE);
> + if (dma_mapping_error(&bp->pdev->dev, mapping)) {
> dev_kfree_skb(skb);
> return NETDEV_TX_OK;
> }
> @@ -6486,9 +6491,9 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device *dev)
> txbd = &txr->tx_desc_ring[ring_prod];
>
> len = frag->size;
> - mapping = pci_map_page(bp->pdev, frag->page, frag->page_offset,
> - len, PCI_DMA_TODEVICE);
> - if (pci_dma_mapping_error(bp->pdev, mapping))
> + mapping = dma_map_page(&bp->pdev->dev, frag->page, frag->page_offset,
> + len, PCI_DMA_TODEVICE);
> + if (dma_mapping_error(&bp->pdev->dev, mapping))
> goto dma_error;
> dma_unmap_addr_set(&txr->tx_buf_ring[ring_prod], mapping,
> mapping);
> @@ -6527,7 +6532,7 @@ dma_error:
> ring_prod = TX_RING_IDX(prod);
> tx_buf = &txr->tx_buf_ring[ring_prod];
> tx_buf->skb = NULL;
> - pci_unmap_single(bp->pdev, dma_unmap_addr(tx_buf, mapping),
> + dma_unmap_single(&bp->pdev->dev, dma_unmap_addr(tx_buf, mapping),
> skb_headlen(skb), PCI_DMA_TODEVICE);
>
> /* unmap remaining mapped pages */
> @@ -6535,7 +6540,7 @@ dma_error:
> prod = NEXT_TX_BD(prod);
> ring_prod = TX_RING_IDX(prod);
> tx_buf = &txr->tx_buf_ring[ring_prod];
> - pci_unmap_page(bp->pdev, dma_unmap_addr(tx_buf, mapping),
> + dma_unmap_page(&bp->pdev->dev, dma_unmap_addr(tx_buf, mapping),
> skb_shinfo(skb)->frags[i].size,
> PCI_DMA_TODEVICE);
> }
^ permalink raw reply
* Re: [PATCH v2 1/2] bnx2: allocate with GFP_KERNEL flag on RX path init
From: Michael Chan @ 2010-07-16 21:24 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100716105540.613d40cc@dhcp-lab-109.englab.brq.redhat.com>
On Fri, 2010-07-16 at 01:55 -0700, Stanislaw Gruszka wrote:
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Michael Chan <mchan@broadcom.com>
> ---
> v1->v2: use GFP_ATOMIC in bnx2_rx_skb
>
> drivers/net/bnx2.c | 17 +++++++++--------
> 1 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index a203f39..a7df539 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -2664,13 +2664,13 @@ bnx2_set_mac_addr(struct bnx2 *bp, u8 *mac_addr, u32 pos)
> }
>
> static inline int
> -bnx2_alloc_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
> +bnx2_alloc_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gfp_t gfp)
> {
> dma_addr_t mapping;
> struct sw_pg *rx_pg = &rxr->rx_pg_ring[index];
> struct rx_bd *rxbd =
> &rxr->rx_pg_desc_ring[RX_RING(index)][RX_IDX(index)];
> - struct page *page = alloc_page(GFP_ATOMIC);
> + struct page *page = alloc_page(gfp);
>
> if (!page)
> return -ENOMEM;
> @@ -2705,7 +2705,7 @@ bnx2_free_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
> }
>
> static inline int
> -bnx2_alloc_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
> +bnx2_alloc_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gfp_t gfp)
> {
> struct sk_buff *skb;
> struct sw_bd *rx_buf = &rxr->rx_buf_ring[index];
> @@ -2713,7 +2713,7 @@ bnx2_alloc_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
> struct rx_bd *rxbd = &rxr->rx_desc_ring[RX_RING(index)][RX_IDX(index)];
> unsigned long align;
>
> - skb = netdev_alloc_skb(bp->dev, bp->rx_buf_size);
> + skb = __netdev_alloc_skb(bp->dev, bp->rx_buf_size, gfp);
> if (skb == NULL) {
> return -ENOMEM;
> }
> @@ -2974,7 +2974,7 @@ bnx2_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, struct sk_buff *skb,
> int err;
> u16 prod = ring_idx & 0xffff;
>
> - err = bnx2_alloc_rx_skb(bp, rxr, prod);
> + err = bnx2_alloc_rx_skb(bp, rxr, prod, GFP_ATOMIC);
> if (unlikely(err)) {
> bnx2_reuse_rx_skb(bp, rxr, skb, (u16) (ring_idx >> 16), prod);
> if (hdr_len) {
> @@ -3039,7 +3039,8 @@ bnx2_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, struct sk_buff *skb,
> rx_pg->page = NULL;
>
> err = bnx2_alloc_rx_page(bp, rxr,
> - RX_PG_RING_IDX(pg_prod));
> + RX_PG_RING_IDX(pg_prod),
> + GFP_ATOMIC);
> if (unlikely(err)) {
> rxr->rx_pg_cons = pg_cons;
> rxr->rx_pg_prod = pg_prod;
> @@ -5179,7 +5180,7 @@ bnx2_init_rx_ring(struct bnx2 *bp, int ring_num)
>
> ring_prod = prod = rxr->rx_pg_prod;
> for (i = 0; i < bp->rx_pg_ring_size; i++) {
> - if (bnx2_alloc_rx_page(bp, rxr, ring_prod) < 0) {
> + if (bnx2_alloc_rx_page(bp, rxr, ring_prod, GFP_KERNEL) < 0) {
> netdev_warn(bp->dev, "init'ed rx page ring %d with %d/%d pages only\n",
> ring_num, i, bp->rx_pg_ring_size);
> break;
> @@ -5191,7 +5192,7 @@ bnx2_init_rx_ring(struct bnx2 *bp, int ring_num)
>
> ring_prod = prod = rxr->rx_prod;
> for (i = 0; i < bp->rx_ring_size; i++) {
> - if (bnx2_alloc_rx_skb(bp, rxr, ring_prod) < 0) {
> + if (bnx2_alloc_rx_skb(bp, rxr, ring_prod, GFP_KERNEL) < 0) {
> netdev_warn(bp->dev, "init'ed rx ring %d with %d/%d skbs only\n",
> ring_num, i, bp->rx_ring_size);
> break;
^ permalink raw reply
* RE: [RFC] Enhance dev_ioctl to return <hwaddr>:<if_name::if_index> mapping
From: Loke, Chetan @ 2010-07-16 20:49 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, bhutchings, netdev
In-Reply-To: <20100716.131835.124042396.davem@davemloft.net>
Ooops... I got the 'CC' list this time
On Fri, Jul 16, 2010 at 4:33 PM, David Miller <davem@davemloft.net>
wrote:
> From: Chetan Loke <chetanloke@gmail.com>
> Date: Fri, 16 Jul 2010 16:24:16 -0400
>
>> Thanks for your time guys.
>
> You dropped everything from the CC: list, so nobody other
> than me saw this. :)
>
>
On Fri, Jul 16, 2010 at 4:24 PM, Chetan Loke <chetanloke@gmail.com>
wrote:
> On Fri, Jul 16, 2010 at 4:18 PM, David Miller <davem@davemloft.net>
wrote:
>> From: Chetan Loke <chetanloke@gmail.com>
>> Date: Fri, 16 Jul 2010 16:15:44 -0400
>>
>>> Ok, what if, i) ifindex == 0 in the call to SIOCGIFINDEX or ii) if
the
>>> ifindex is not found ? May be then in the else clause we could
search
>>> using the hw-addr before bailing out ;)? This way we can avoid
adding
>>> a new API. Still not a good idea?
>>
>> I'm really not going to consider this seriously, sorry. I've
>> made my position pretty clear, and gave sufficient reasons for
>> it.
>>
>> Myself and others have also shown you several ways to fetch the
>> information you need, and of them netlink is probably the most
>> efficient, but the others work just as well.
>>
>> The new interface proposals are just not a good idea.
>>
>
> No problem Dave. I will patch our internal iso and add dev_getbyhwaddr
> in the else clause.
>
> Thanks for your time guys.
>
> regards
> Chetan Loke
>
^ permalink raw reply
* Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code
From: David Miller @ 2010-07-16 20:45 UTC (permalink / raw)
To: jwboyer
Cc: qy03fugy, miltonm, mporter, benh, paulus, solomon, dwmw2, vapier,
jkosina, Artem.Bityutskiy, linux, randy.dunlap, john.linn,
florian, nico, joe, ladis, davidb, linuxppc-dev, linux-kernel,
linux-mtd, netdev, vamos-dev
In-Reply-To: <20100716142055.GA11736@zod.rchland.ibm.com>
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Fri, 16 Jul 2010 10:20:55 -0400
> On Fri, Jul 16, 2010 at 02:29:02PM +0200, Christian Dietrich wrote:
>>The config options for REDWOOD_[456] were commented out in the powerpc
>>Kconfig. The ifdefs referencing this options therefore are dead and all
>>references to this can be removed (Also dependencies in other KConfig
>>files).
>>
>>Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
>>Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
>
> This seems fine with me.
>
> The only question is which tree it coms through. I'm happy to take it
> in via mine if the netdev and MTD people are fine with that. Otherwise,
> my ack is below.
>
> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Please take it:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [RFC] Enhance dev_ioctl to return <hwaddr>:<if_name::if_index> mapping
From: David Miller @ 2010-07-16 20:18 UTC (permalink / raw)
To: chetanloke; +Cc: shemminger, Chetan.Loke, bhutchings, netdev
In-Reply-To: <AANLkTineSDEEKY-9ve2maSBmPWBxkW5XmqnHlLtIOClx@mail.gmail.com>
From: Chetan Loke <chetanloke@gmail.com>
Date: Fri, 16 Jul 2010 16:15:44 -0400
> Ok, what if, i) ifindex == 0 in the call to SIOCGIFINDEX or ii) if the
> ifindex is not found ? May be then in the else clause we could search
> using the hw-addr before bailing out ;)? This way we can avoid adding
> a new API. Still not a good idea?
I'm really not going to consider this seriously, sorry. I've
made my position pretty clear, and gave sufficient reasons for
it.
Myself and others have also shown you several ways to fetch the
information you need, and of them netlink is probably the most
efficient, but the others work just as well.
The new interface proposals are just not a good idea.
^ permalink raw reply
* Re: [PATCH] ibmveth: lost IRQ while closing/opening device leads to service loss
From: David Miller @ 2010-07-16 20:16 UTC (permalink / raw)
To: rcj; +Cc: netdev, santil, brking
In-Reply-To: <20100716145724.GA25385@linux.vnet.ibm.com>
From: Robert Jennings <rcj@linux.vnet.ibm.com>
Date: Fri, 16 Jul 2010 09:57:25 -0500
> The order of freeing the IRQ and freeing the device in firmware
> in ibmveth_close can cause the adapter to become unusable after a
> subsequent ibmveth_open. Only a reboot of the OS will make the
> network device usable again. This is seen when cycling the adapter
> up and down while there is network activity.
>
> There is a window where an IRQ will be left unserviced (H_EOI will not
> be called). The solution is to make a VIO_IRQ_DISABLE h_call, free the
> device with firmware, and then call free_irq.
>
> Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
Applied, thanks.
> No changes to the patch, I realized I left out '[PATCH]' in the subject
> and I didn't want any automated tools missing this fix.
Rules may be sometimes seen as anal, but they are not _that_ anal.
Also you can always look in patchwork to see if your change is
there, and your original patch was.
You actually make more work for me if you resubmit patches already
sitting in the queue :-/
^ permalink raw reply
* Re: [RFC] Enhance dev_ioctl to return <hwaddr>:<if_name::if_index> mapping
From: Chetan Loke @ 2010-07-16 20:15 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, Chetan.Loke, bhutchings, netdev
In-Reply-To: <20100716.130445.149851386.davem@davemloft.net>
On Fri, Jul 16, 2010 at 4:04 PM, David Miller <davem@davemloft.net> wrote:
> From: Chetan Loke <chetanloke@gmail.com>
> Date: Fri, 16 Jul 2010 16:02:23 -0400
>
>> So all user space apps should replicate code when all of that can be
>> replaced at the cost of a single for-loop in a non fast-path code
>> within the kernel?
>
> When there is a way to do something already, we don't add "yet another"
> way to do it. The kernel already suffers from API masterbation as-is.
>
Ok, what if, i) ifindex == 0 in the call to SIOCGIFINDEX or ii) if the
ifindex is not found ? May be then in the else clause we could search
using the hw-addr before bailing out ;)? This way we can avoid adding
a new API. Still not a good idea?
^ permalink raw reply
* Re: [PATCH] Drivers: net: 8139cp: Improved conformance to the Linux coding style guidelines.
From: David Miller @ 2010-07-16 20:13 UTC (permalink / raw)
To: joseph.kogut; +Cc: netdev, linux-kernel
In-Reply-To: <1279286391-31464-1-git-send-email-joseph.kogut@gmail.com>
From: Joseph Kogut <joseph.kogut@gmail.com>
Date: Fri, 16 Jul 2010 06:19:51 -0700
Please fix the clock on your computer, I don't think it's
6am in the -0700 timezone right now :-)
^ permalink raw reply
* Re: [RFC] Enhance dev_ioctl to return <hwaddr>:<if_name::if_index> mapping
From: David Miller @ 2010-07-16 20:04 UTC (permalink / raw)
To: chetanloke; +Cc: shemminger, Chetan.Loke, bhutchings, netdev
In-Reply-To: <AANLkTinAiJJqhrro8Jlrb0WgHzDSCx_dtWXL5N9ZKUbd@mail.gmail.com>
From: Chetan Loke <chetanloke@gmail.com>
Date: Fri, 16 Jul 2010 16:02:23 -0400
> So all user space apps should replicate code when all of that can be
> replaced at the cost of a single for-loop in a non fast-path code
> within the kernel?
When there is a way to do something already, we don't add "yet another"
way to do it. The kernel already suffers from API masterbation as-is.
^ permalink raw reply
* Re: [RFC] Enhance dev_ioctl to return <hwaddr>:<if_name::if_index> mapping
From: Chetan Loke @ 2010-07-16 20:02 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, Chetan.Loke, bhutchings, netdev
In-Reply-To: <20100716.124031.220080717.davem@davemloft.net>
On Fri, Jul 16, 2010 at 3:40 PM, David Miller <davem@davemloft.net> wrote:
> From: Chetan Loke <chetanloke@gmail.com>
> Date: Fri, 16 Jul 2010 15:35:48 -0400
>
>> Yes, I opened a socket and then sent the IFCONF ioctl.What I meant was
>> that interfaces that didn't have an IP weren't returned.
>
> If you use the correct set of ioctl()'s it will, just as
> "/sbin/ifconfig -a" lists all interfaces regardless of whether they
> have IP addresses.
>
> Run strace on 'ifconfig', see what it does :-)
I grep the /sys nodes in my existing code already ;) and I didn't want
to do that.If we plop the single for-each-netdev loop then wouldn't it
be easier?
>
> And then you also have the option of using netlink as well.
> This is how "ip l l" lists all interfaces, also regardless of
> configuration.
>
So all user space apps should replicate code when all of that can be
replaced at the cost of a single for-loop in a non fast-path code
within the kernel?
^ permalink raw reply
* Re: [GIT PULL] vhost-net fixes
From: David Miller @ 2010-07-16 19:57 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20100716122530.GA29478@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 16 Jul 2010 15:25:30 +0300
> David, please pull the following fixes for 2.6.35.
> Thanks!
>
> The following changes since commit 91a72a70594e5212c97705ca6a694bd307f7a26b:
>
> net/core: neighbour update Oops (2010-07-14 18:02:16 -0700)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net
>
> Michael S. Tsirkin (2):
> vhost-net: avoid flush under lock
> vhost: avoid pr_err on condition guest can trigger
Pulled, thanks!
^ 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