* Re: [patch net-next-2.6] net: reinject arps into bonding slave instead of master
From: Jiri Pirko @ 2011-03-10 20:52 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Andy Gospodarek, netdev, davem, shemminger, kaber, fubar,
eric.dumazet
In-Reply-To: <4D793845.1060702@gmail.com>
Thu, Mar 10, 2011 at 09:44:53PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 10/03/2011 07:48, Jiri Pirko a écrit :
>>>But for all others setups, where there exist some net_devices before
>>>the "untagging" one, you would face some troubles. For example, with
>>>eth0+eth1 -> br0 -> br0.100, you cannot untag before entering
>>>__netif_receive_skb. If you do so, the bridge would receive untagged
>>>frame and if the frame is not for the local host, the bridge would
>>>forward an untagged frame while it is expected to forward a tagged
>>>one. Even if the bridge is in a position to know the frame *was*
>>>tagged, we cannot expect the bridge to do special processing to
>>>handle this situation. Doing so would break layering.
>>
>>I disagree.
>>eth0 -> untag on early __netif_receive_skb (sets up skb->vlan_tci)
>> ->rx_handler of bridge
>>->br0 -> tag is detected by vlan_tx_tag_present()
>> -> reinject to __netif_receive_skb with skb->dev == br0.100
>
>For local delivery, is should work.
>
>But if the bridge must forward the frame to another host (bridges are
>designed for such things :-)), it will have to insert the vlan header
>back into the frame. I don't understand how it could work
>automagically in this situation.
This works for hw_accel path. Would look the same.
>
>>This way the flow would be very similar to vlan-hw-accel, am I right?
>
>So your point is to remove any 802.1Q header in any ingres frame,
>whatever the local interface setup. Right?
>
>How would this support nested vlan headers?
>
>eth0 -> eth0.100 -> eth0.100.200 -> eth0.100.200.300.
>
>Who will choose eth0.100.200.300 as the last skb->dev?
Hate to think about this more, that's for sure.
>
>>I have following patch in mind. Note it's raw DRAFT.
>
>I need to take some time to review your patch.
>
>In the mean time, what is the status of the whole patch series? Can we expect an ACK from someone?
It was posponed by davem. I plan to solve vlans first, then repost the
whole series (so that bond recv_probe would see vlan arps)
>
> Nicolas.
^ permalink raw reply
* virtio_net: remove recv refill work?
From: Shirley Ma @ 2011-03-10 21:03 UTC (permalink / raw)
To: Rusty Russell; +Cc: kvm, netdev, Michael S. Tsirkin
Hello Rusty,
What's the reason to use refill work in receiving path?
static void refill_work(struct work_struct *work)
{
struct virtnet_info *vi;
bool still_empty;
vi = container_of(work, struct virtnet_info, refill.work);
napi_disable(&vi->napi);
still_empty = !try_fill_recv(vi, GFP_KERNEL);
napi_enable(&vi->napi);
/* In theory, this can happen: if we don't get any buffers in
* we will *never* try to fill again. */
if (still_empty)
schedule_delayed_work(&vi->refill, HZ/2);
}
It looks more expensive than only refilling the buffers in recv path. It
could cause more guest exits, maybe more RX interrupts. Can we move the
refill work in recv path only?
If we can remove it, I will run some test to compare the difference with
the change.
Thanks
Shirley
^ permalink raw reply
* Re: [patch net-next-2.6] net: reinject arps into bonding slave instead of master
From: Jiri Pirko @ 2011-03-10 21:05 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: netdev
In-Reply-To: <4D793845.1060702@gmail.com>
Thu, Mar 10, 2011 at 09:44:53PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 10/03/2011 07:48, Jiri Pirko a écrit :
>>>But for all others setups, where there exist some net_devices before
>>>the "untagging" one, you would face some troubles. For example, with
>>>eth0+eth1 -> br0 -> br0.100, you cannot untag before entering
>>>__netif_receive_skb. If you do so, the bridge would receive untagged
>>>frame and if the frame is not for the local host, the bridge would
>>>forward an untagged frame while it is expected to forward a tagged
>>>one. Even if the bridge is in a position to know the frame *was*
>>>tagged, we cannot expect the bridge to do special processing to
>>>handle this situation. Doing so would break layering.
>>
>>I disagree.
>>eth0 -> untag on early __netif_receive_skb (sets up skb->vlan_tci)
>> ->rx_handler of bridge
>>->br0 -> tag is detected by vlan_tx_tag_present()
>> -> reinject to __netif_receive_skb with skb->dev == br0.100
>
>For local delivery, is should work.
>
>But if the bridge must forward the frame to another host (bridges are
>designed for such things :-)), it will have to insert the vlan header
>back into the frame. I don't understand how it could work
>automagically in this situation.
See dev_hard_start_xmit and search for vlan :)
^ permalink raw reply
* Re: virtio_net: remove recv refill work?
From: Shirley Ma @ 2011-03-10 21:22 UTC (permalink / raw)
To: Rusty Russell; +Cc: kvm, netdev, Michael S. Tsirkin
In-Reply-To: <1299791038.25664.213.camel@localhost.localdomain>
Never mind, the refill work is needed only for OOM. It can't be
replaced.
thanks
Shirley
^ permalink raw reply
* [PATCH 2.6.38-rc8 build failure] net: bridge builtin vs. ipv6 modular
From: Randy Dunlap @ 2011-03-10 21:28 UTC (permalink / raw)
To: Patrick Schaaf, Stephen Hemminger; +Cc: netdev, davem
In-Reply-To: <1299752394.4109.31.camel@lat1>
This can be fixed in either of 2 ways. One way is to require that the
bridge code building depend on how the IPV6 code is built (builtin or modular);
the other way is to handle the kconfig variations in net/bridge/br_multicast.c --
but this loses some functionality if IPV6=m and BRIDGE=y.
I prefer the Kconfig patch over the br_multicast.c patch.
Both patches are below for consideration.
---
From: Randy Dunlap <randy.dunlap@oracle.com>
When configs BRIDGE=y and IPV6=m, this build error occurs:
br_multicast.c:(.text+0xa3341): undefined reference to `ipv6_dev_get_saddr'
BRIDGE_IGMP_SNOOPING is boolean; if it were tristate, then adding
depends on IPV6 || IPV6=n
to BRIDGE_IGMP_SNOOPING would be a good fix. As it is currently,
making BRIDGE depend on the IPV6 config works.
Reported-by: Patrick Schaaf <netdev@bof.de>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
---
net/bridge/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- lnx-2638-rc8.orig/net/bridge/Kconfig
+++ lnx-2638-rc8/net/bridge/Kconfig
@@ -6,6 +6,7 @@ config BRIDGE
tristate "802.1d Ethernet Bridging"
select LLC
select STP
+ depends on IPV6 || IPV6=n
---help---
If you say Y here, then your Linux box will be able to act as an
Ethernet bridge, which means that the different Ethernet segments it
===== alternate patch =====
From: Randy Dunlap <randy.dunlap@oracle.com>
Handle IPV6 vs. BRIDGE config differences in br_multicast.c.
This allows IPV6 to be modular with bridge code either built-in
or modular, but if IPV6=m and BRIDGE=y, some functionality is
lost.
Built with all 6 combinations of IPV6={ymn} and BRIDGE={ym}.
Reported-by: Patrick Schaaf <netdev@bof.de>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
---
net/bridge/br_multicast.c | 37 ++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
--- lnx-2638-rc8.orig/net/bridge/br_multicast.c
+++ lnx-2638-rc8/net/bridge/br_multicast.c
@@ -10,6 +10,11 @@
*
*/
+#if defined(CONFIG_IPV6) || \
+ (defined(CONFIG_IPV6_MODULE) && defined(CONFIG_BRIDGE_MODULE))
+#define USE_IPV6 1
+#endif
+
#include <linux/err.h>
#include <linux/if_ether.h>
#include <linux/igmp.h>
@@ -24,7 +29,7 @@
#include <linux/slab.h>
#include <linux/timer.h>
#include <net/ip.h>
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
#include <net/ipv6.h>
#include <net/mld.h>
#include <net/addrconf.h>
@@ -36,7 +41,7 @@
#define mlock_dereference(X, br) \
rcu_dereference_protected(X, lockdep_is_held(&br->multicast_lock))
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static inline int ipv6_is_transient_multicast(const struct in6_addr *addr)
{
if (ipv6_addr_is_multicast(addr) && IPV6_ADDR_MC_FLAG_TRANSIENT(addr))
@@ -52,7 +57,7 @@ static inline int br_ip_equal(const stru
switch (a->proto) {
case htons(ETH_P_IP):
return a->u.ip4 == b->u.ip4;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
case htons(ETH_P_IPV6):
return ipv6_addr_equal(&a->u.ip6, &b->u.ip6);
#endif
@@ -65,7 +70,7 @@ static inline int __br_ip4_hash(struct n
return jhash_1word(mdb->secret, (__force u32)ip) & (mdb->max - 1);
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static inline int __br_ip6_hash(struct net_bridge_mdb_htable *mdb,
const struct in6_addr *ip)
{
@@ -79,7 +84,7 @@ static inline int br_ip_hash(struct net_
switch (ip->proto) {
case htons(ETH_P_IP):
return __br_ip4_hash(mdb, ip->u.ip4);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
case htons(ETH_P_IPV6):
return __br_ip6_hash(mdb, &ip->u.ip6);
#endif
@@ -121,7 +126,7 @@ static struct net_bridge_mdb_entry *br_m
return br_mdb_ip_get(mdb, &br_dst);
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static struct net_bridge_mdb_entry *br_mdb_ip6_get(
struct net_bridge_mdb_htable *mdb, const struct in6_addr *dst)
{
@@ -152,7 +157,7 @@ struct net_bridge_mdb_entry *br_mdb_get(
case htons(ETH_P_IP):
ip.u.ip4 = ip_hdr(skb)->daddr;
break;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
case htons(ETH_P_IPV6):
ipv6_addr_copy(&ip.u.ip6, &ipv6_hdr(skb)->daddr);
break;
@@ -411,7 +416,7 @@ out:
return skb;
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
struct in6_addr *group)
{
@@ -496,7 +501,7 @@ static struct sk_buff *br_multicast_allo
switch (addr->proto) {
case htons(ETH_P_IP):
return br_ip4_multicast_alloc_query(br, addr->u.ip4);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
case htons(ETH_P_IPV6):
return br_ip6_multicast_alloc_query(br, &addr->u.ip6);
#endif
@@ -773,7 +778,7 @@ static int br_ip4_multicast_add_group(st
return br_multicast_add_group(br, port, &br_group);
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static int br_ip6_multicast_add_group(struct net_bridge *br,
struct net_bridge_port *port,
const struct in6_addr *group)
@@ -845,7 +850,7 @@ static void br_multicast_send_query(stru
br_group.proto = htons(ETH_P_IP);
__br_multicast_send_query(br, port, &br_group);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
br_group.proto = htons(ETH_P_IPV6);
__br_multicast_send_query(br, port, &br_group);
#endif
@@ -989,7 +994,7 @@ static int br_ip4_multicast_igmp3_report
return err;
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static int br_ip6_multicast_mld2_report(struct net_bridge *br,
struct net_bridge_port *port,
struct sk_buff *skb)
@@ -1185,7 +1190,7 @@ out:
return err;
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static int br_ip6_multicast_query(struct net_bridge *br,
struct net_bridge_port *port,
struct sk_buff *skb)
@@ -1334,7 +1339,7 @@ static void br_ip4_multicast_leave_group
br_multicast_leave_group(br, port, &br_group);
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static void br_ip6_multicast_leave_group(struct net_bridge *br,
struct net_bridge_port *port,
const struct in6_addr *group)
@@ -1446,7 +1451,7 @@ err_out:
return err;
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
static int br_multicast_ipv6_rcv(struct net_bridge *br,
struct net_bridge_port *port,
struct sk_buff *skb)
@@ -1583,7 +1588,7 @@ int br_multicast_rcv(struct net_bridge *
switch (skb->protocol) {
case htons(ETH_P_IP):
return br_multicast_ipv4_rcv(br, port, skb);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+#if defined(USE_IPV6)
case htons(ETH_P_IPV6):
return br_multicast_ipv6_rcv(br, port, skb);
#endif
^ permalink raw reply
* Re: [PATCH 2.6.38-rc8 build failure] net: bridge builtin vs. ipv6 modular
From: David Miller @ 2011-03-10 21:49 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev, shemminger, netdev
In-Reply-To: <20110310132801.4a919df2.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Thu, 10 Mar 2011 13:28:01 -0800
> This can be fixed in either of 2 ways. One way is to require that the
> bridge code building depend on how the IPV6 code is built (builtin or modular);
> the other way is to handle the kconfig variations in net/bridge/br_multicast.c --
> but this loses some functionality if IPV6=m and BRIDGE=y.
>
> I prefer the Kconfig patch over the br_multicast.c patch.
> Both patches are below for consideration.
I definitely prefer the Kconfig variant, although it's unfortunate that we
have a stateful dependency in the bridging multicast code.
IPV4 seems to let us use INADDR_ANY as the source address in the multicast
query, but IPV6 does not allow this (as per RFC 2710).
Anyways, I've applied the Kconfig patch, thanks Randy!
^ permalink raw reply
* [PATCH] ip6ip6: autoload ip6 tunnel
From: Stephen Hemminger @ 2011-03-10 21:43 UTC (permalink / raw)
To: David Miller
Cc: netdev, Vasiliy Kulikov, Michael Tokarev, Kees Cook, James Morris
Add necessary alias to autoload ip6ip6 tunnel module.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Patch is against 2.6.38-rc7 (not net-next).
--- a/net/ipv6/ip6_tunnel.c 2011-03-10 13:33:16.613345613 -0800
+++ b/net/ipv6/ip6_tunnel.c 2011-03-10 13:37:32.372100323 -0800
@@ -57,6 +57,7 @@
MODULE_AUTHOR("Ville Nuorvala");
MODULE_DESCRIPTION("IPv6 tunneling device");
MODULE_LICENSE("GPL");
+MODULE_ALIAS_NETDEV("ip6tnl0");
#ifdef IP6_TNL_DEBUG
#define IP6_TNL_TRACE(x...) printk(KERN_DEBUG "%s:" x "\n", __func__)
^ permalink raw reply
* Re: [PATCH] ip6ip6: autoload ip6 tunnel
From: David Miller @ 2011-03-10 22:00 UTC (permalink / raw)
To: shemminger; +Cc: netdev, segoon, mjt, kees.cook, jmorris
In-Reply-To: <20110310134319.25b1b901@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 10 Mar 2011 13:43:19 -0800
> Add necessary alias to autoload ip6ip6 tunnel module.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> Patch is against 2.6.38-rc7 (not net-next).
Yep, understood. I'll do a merge then apply this, thanks Stephen!
^ permalink raw reply
* RE: [PATCH V4] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Shyam_Iyer @ 2011-03-10 22:05 UTC (permalink / raw)
To: Narendra_K, greg
Cc: a.beregalov, linux-next, jbarnes, linux-pci, linux-hotplug,
netdev, mjg, Matt_Domsch, Charles_Rose, Jordan_Hargrave, sfr
In-Reply-To: <20110307211552.GA11016@fedora14-r610.oslab.blr.amer.dell.com>
> -----Original Message-----
> From: K, Narendra
> Sent: Monday, March 07, 2011 3:56 PM
> To: Greg KH
> Cc: a.beregalov@gmail.com; linux-next@vger.kernel.org;
> jbarnes@virtuousgeek.org; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; mjg@redhat.com;
> Domsch, Matt; Rose, Charles; Hargrave, Jordan; Iyer, Shyam;
> sfr@canb.auug.org.au
> Subject: Re: [PATCH V4] Export ACPI _DSM provided firmware instance
> number and string name to sysfs
>
> On Tue, Mar 08, 2011 at 01:26:16AM +0530, Greg KH wrote:
> > On Mon, Mar 07, 2011 at 11:44:52AM -0800, Narendra_K@Dell.com wrote:
> > > --- a/drivers/pci/pci-label.c
> > > +++ b/drivers/pci/pci-label.c
> > > @@ -29,7 +29,9 @@
> > > #include <linux/nls.h>
> > > #include <linux/acpi.h>
> > > #include <linux/pci-acpi.h>
> > > +#ifdef CONFIG_ACPI
> > > #include <acpi/acpi_drivers.h>
> > > +#endif
> >
> > You should never need a #ifdef in a .c file for an include file. If
> so,
> > something is really wrong.
>
> I agree. Also, i realized that the include was not required to address
> the
> reported error. Please find the revised patch here.
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Fix compilation error when CONFIG_ACPI is unset
>
> This patch fixes compilation error descibed below introduced by
> the commit 6058989bad05b82e78baacce69ec14f27a11b5fd
>
> drivers/pci/pci-label.c: In function ‘pci_create_firmware_label_files’:
> drivers/pci/pci-label.c:366:2: error: implicit declaration of function
> ‘device_has_dsm’
>
> Signed-off-by: Narendra K <narendra_k@dell.com>
> ---
> drivers/pci/pci-label.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> index 824e247..8c80138 100644
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -174,6 +174,12 @@ pci_remove_acpi_index_label_files(struct pci_dev
> *pdev)
> return -1;
> }
>
> +static inline bool
> +device_has_dsm(struct device *dev)
> +{
> + return false;
> +}
> +
> #else
>
> static const char device_label_dsm_uuid[] = {
> --
> 1.7.3.1
>
> With regards,
> Narendra K
So this works and fixes the additional build failure.
I tested with CONFIG_ACPI set/unset and with "make allmodconfig"
Additionally I found that including acpi/apci_drivers.h is not necessary and introduces these warnings..
The below patch fixes the additional warnigs..
In file included from drivers/pci/pci-label.c:32:
include/acpi/acpi_drivers.h:103: warning: ‘struct acpi_device’ declared inside parameter list
include/acpi/acpi_drivers.h:103: warning: its scope is only this definition or declaration, which is probably not what you want
include/acpi/acpi_drivers.h:107: warning: ‘struct acpi_pci_root’ declared inside parameter list
Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>
---
drivers/pci/pci-label.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index bf4ebee..488b0ce 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -29,7 +29,6 @@
#include <linux/nls.h>
#include <linux/acpi.h>
#include <linux/pci-acpi.h>
-#include <acpi/acpi_drivers.h>
#include <acpi/acpi_bus.h>
#include "pci.h"
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3] tcp: ioctl type SIOCOUTQNSD returns amount of data not sent
From: Hagen Paul Pfeifer @ 2011-03-10 22:12 UTC (permalink / raw)
To: David Miller
Cc: sledz, netdev, linux-kernel, alan, kuznet, pekkas, jmorris,
yoshfuji, kaber, m.schuknecht
In-Reply-To: <20110309.140951.232741403.davem@davemloft.net>
* David Miller | 2011-03-09 14:09:51 [-0800]:
>From: Steffen Sledz <sledz@dresearch.de>
>Date: Sun, 6 Mar 2011 20:59:55 +0100
>
>> From: Mario Schuknecht <m.schuknecht@dresearch.de>
>>
>> In contrast to SIOCOUTQ which returns the amount of data sent
>> but not yet acknowledged plus data not yet sent this patch only
>> returns the data not sent.
>>
>> For various methods of live streaming bitrate control it may
>> be helpful to know how much data are in the tcp outqueue are
>> not sent yet.
>>
>> Signed-off-by: Mario Schuknecht <m.schuknecht@dresearch.de>
>> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
>
>Applied, thanks.
A little bit late - but why not using struct tcp_info for that? The
information is already provided via getsockopt(TCP_INFO).
Hagen
^ permalink raw reply
* Re: [Patch]ariadne: remove redundant NULL check
From: David Miller @ 2011-03-10 22:12 UTC (permalink / raw)
To: j223yang; +Cc: netdev, linux-kernel
In-Reply-To: <20110310172031.GA10734@asset.uwaterloo.ca>
From: j223yang@asset.uwaterloo.ca
Date: Thu, 10 Mar 2011 12:20:31 -0500
> Simply remove redundant 'dev' NULL check.
>
> Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
This patch was corrupted by your email client, it turned TAB
characters into spaces which makes the patch unusable.
Also your signoff is badly formed, a space is missing between
your name and the "<" that begins your email address.
^ permalink raw reply
* Re: [PATCH v3] tcp: ioctl type SIOCOUTQNSD returns amount of data not sent
From: David Miller @ 2011-03-10 22:16 UTC (permalink / raw)
To: hagen
Cc: sledz, netdev, linux-kernel, alan, kuznet, pekkas, jmorris,
yoshfuji, kaber, m.schuknecht
In-Reply-To: <20110310221205.GF3121@nuttenaction>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Thu, 10 Mar 2011 23:12:05 +0100
> * David Miller | 2011-03-09 14:09:51 [-0800]:
>
>>From: Steffen Sledz <sledz@dresearch.de>
>>Date: Sun, 6 Mar 2011 20:59:55 +0100
>>
>>> From: Mario Schuknecht <m.schuknecht@dresearch.de>
>>>
>>> In contrast to SIOCOUTQ which returns the amount of data sent
>>> but not yet acknowledged plus data not yet sent this patch only
>>> returns the data not sent.
>>>
>>> For various methods of live streaming bitrate control it may
>>> be helpful to know how much data are in the tcp outqueue are
>>> not sent yet.
>>>
>>> Signed-off-by: Mario Schuknecht <m.schuknecht@dresearch.de>
>>> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
>>
>>Applied, thanks.
>
> A little bit late - but why not using struct tcp_info for that? The
> information is already provided via getsockopt(TCP_INFO).
It's pretty heavy handed to copy that entire TCP_INFO struct into
userspace during every I/O sequence the application makes.
^ permalink raw reply
* [patch] ariadne: remove redundant NULL check
From: j223yang @ 2011-03-10 22:36 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
Simply remove redundant 'dev' NULL check.
Source code uses spaces instead of TAB, except 'printk' and 'return' lines.
Signed-off-by: Jinqiu Yang <crindy646@gmail.com>
---
ariadne.c | 5 -----
1 file changed, 5 deletions(-)
--- a/drivers/net/ariadne.c 2011-03-10 11:20:14.076039323 -0500
+++ b/drivers/net/ariadne.c 2011-03-10 11:21:59.111164537 -0500
@@ -425,11 +425,6 @@ static irqreturn_t ariadne_interrupt(int
int csr0, boguscnt;
int handled = 0;
- if (dev == NULL) {
- printk(KERN_WARNING "ariadne_interrupt(): irq for unknown device.\n");
- return IRQ_NONE;
- }
-
lance->RAP = CSR0; /* PCnet-ISA Controller Status */
if (!(lance->RDP & INTR)) /* Check if any interrupt has been */
^ permalink raw reply
* Re: [patch] ariadne: remove redundant NULL check
From: David Miller @ 2011-03-10 22:39 UTC (permalink / raw)
To: j223yang; +Cc: netdev, linux-kernel
In-Reply-To: <20110310223636.GA11399@asset.uwaterloo.ca>
From: j223yang@asset.uwaterloo.ca
Date: Thu, 10 Mar 2011 17:36:37 -0500
> Simply remove redundant 'dev' NULL check.
> Source code uses spaces instead of TAB, except 'printk' and 'return' lines.
>
>
> Signed-off-by: Jinqiu Yang <crindy646@gmail.com>
Patch is still corrupted by your email client, the same way as before.
And when you fix it, you don't need to mention this in the commit
message.
Please, take the time to do some testing by sending the patch to
yourself, and then try to apply the patch in the email you receive.
^ permalink raw reply
* Re: [patch] ariadne: remove redundant NULL check
From: David Miller @ 2011-03-10 22:40 UTC (permalink / raw)
To: j223yang; +Cc: netdev, linux-kernel
In-Reply-To: <20110310.143942.183042624.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 10 Mar 2011 14:39:42 -0800 (PST)
> From: j223yang@asset.uwaterloo.ca
> Date: Thu, 10 Mar 2011 17:36:37 -0500
>
>> Simply remove redundant 'dev' NULL check.
>> Source code uses spaces instead of TAB, except 'printk' and 'return' lines.
>>
>>
>> Signed-off-by: Jinqiu Yang <crindy646@gmail.com>
>
> Patch is still corrupted by your email client, the same way as before.
Sorry, I apologize, this is not your fault.
This is one of those terrible old drivers that have bad coding
style.
I'll apply this patch, thank you.
^ permalink raw reply
* Re: [PATCH 3/8] macb: convert printk to pr_ and friends
From: Joe Perches @ 2011-03-10 22:48 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <1299751843-9743-4-git-send-email-jamie@jamieiles.com>
On Thu, 2011-03-10 at 10:10 +0000, Jamie Iles wrote:
> macb is already using the dev_dbg() and friends helpers so use pr_foo()
> along with a pr_fmt() definition to make the printing a little cleaner.
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Hi Jamie.
Because these conversions use a struct net_device,
they would be better as:
netdev_<foo>(struct net_device *dev, const char *fmt, ...)
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> @@ -175,11 +176,11 @@ static void macb_handle_link_change(struct net_device *dev)
>
> if (status_change) {
> if (phydev->link)
> - printk(KERN_INFO "%s: link up (%d/%s)\n",
> + pr_info("%s: link up (%d/%s)\n",
> dev->name, phydev->speed,
> DUPLEX_FULL == phydev->duplex ? "Full":"Half");
netdev_info(dev, "link up (%d/%s)\n",
phydev->speed,
phydev->duplex == DUPLEX_FULL ? "Full" : "Half");
> else
> - printk(KERN_INFO "%s: link down\n", dev->name);
> + pr_info("%s: link down\n", dev->name);
netdev_info(dev, "link down\n");
> @@ -193,7 +194,7 @@ static int macb_mii_probe(struct net_device *dev)
>
> phydev = phy_find_first(bp->mii_bus);
> if (!phydev) {
> - printk (KERN_ERR "%s: no PHY found\n", dev->name);
> + pr_err("%s: no PHY found\n", dev->name);
netdev_err(dev, "no PHY found\n");
> @@ -206,7 +207,7 @@ static int macb_mii_probe(struct net_device *dev)
> PHY_INTERFACE_MODE_RMII :
> PHY_INTERFACE_MODE_MII);
> if (ret) {
> - printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
> + pr_err("%s: Could not attach to PHY\n", dev->name);
netdev_err(dev, "could not attach to PHY\n");
etc...
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Stephen Hemminger @ 2011-03-10 23:28 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110308093215.GA23842@xanadu.blop.info>
On Tue, 8 Mar 2011 10:32:15 +0100
Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> CUBIC Hystart uses two heuristics to exit slow start earlier, before
> losses start to occur. Unfortunately, it tends to exit slow start far too
> early, causing poor performance since convergence to the optimal cwnd is
> then very slow. This was reported in
> http://permalink.gmane.org/gmane.linux.network/188169 and
> https://partner-bugzilla.redhat.com/show_bug.cgi?id=616985
Ignore the RHEL bug. RHEL 5 ships with TCP BIC (not CUBIC) by default.
There are many research papers which show that BIC is too aggressive,
and not fair.
--
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-03-10 23:34 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
I think all the major known regressions are cured and we should be
ready to go for 2.6.38-final
1) Fix regression in IPV6 route lookups, cures BZ 29252 and 30462
2) We use ifa_address where we mean ifa_local in ipv4 stack,
reported by Julian Anastasov.
3) pktgen time reporting units are wrong, fix from Daniel Turull
4) IPV6=m/BRIDGE=y results in broken build, fix from Randy Dunlap.
5) Network modloading security fix needs to handle ip6 tunnel case,
fix from Stephen Hemminger.
6) bnx2x driver fixes from Dmitry Kravkov and Eilon Greenstein.
7) smsc911x drops full sized VLAN packets erroneously, fix from Göran
Weinholt.
8) Fix Makefile logic for entering net/ipv6 directory for the case
where we are only building {exthdrs,addrconf}_core.o Fix from
Thomas Graf.
9) Multi-threaded signal handling is botched because we use plain
mutex_lock() to synchronize readers in recvmsg(), change to use
mutex_lock_interruptible(). Fix from Rainer Weikusat.
10) Bonding driver state machine locking doesn't cover enough code,
fix from Nils Carlson.
12) Fix BUG_ON trigger in RDS stack, fix from Neil Horman.
13) Multicase handling fixes to r6040 driver from Shawn Lin.
Please pull, thanks a lot!
The following changes since commit 9179746652faf0aba07b8b7f770dcf29892a24c6:
Merge branch 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (2011-03-10 13:22:10 -0800)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Daniel Turull (1):
pktgen: fix errata in show results
David S. Miller (3):
ipv4: Fix erroneous uses of ifa_address.
ipv6: Don't create clones of host routes.
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Dmitry Kravkov (4):
bnx2x: fix non-pmf device load flow
bnx2x: fix link notification
bnx2x: (NPAR) prevent HW access in D3 state
bnx2x: fix MaxBW configuration
Florian Fainelli (1):
r6040: bump to version 0.27 and date 23Feb2011
Göran Weinholt (1):
net/smsc911x.c: Set the VLAN1 register to fix VLAN MTU problem
Jon Mason (1):
vxge: update MAINTAINERS
Neil Horman (1):
rds: prevent BUG_ON triggering on congestion map updates
Nicolas Kaiser (1):
drivers/net/macvtap: fix error check
Nils Carlson (2):
bonding 802.3ad: Fix the state machine locking v2
bonding 802.3ad: Rename rx_machine_lock to state_machine_lock
Rainer Weikusat (1):
net: fix multithreaded signal handling in unix recv routines
Randy Dunlap (1):
net: bridge builtin vs. ipv6 modular
Shawn Lin (1):
r6040: fix multicast operations
Thomas Graf (1):
net: Enter net/ipv6/ even if CONFIG_IPV6=n
j223yang@asset.uwaterloo.ca (1):
ariadne: remove redundant NULL check
stephen hemminger (1):
ip6ip6: autoload ip6 tunnel
MAINTAINERS | 5 +-
drivers/net/ariadne.c | 5 --
drivers/net/bnx2x/bnx2x.h | 5 +-
drivers/net/bnx2x/bnx2x_cmn.c | 22 +++++++
drivers/net/bnx2x/bnx2x_cmn.h | 9 +++
drivers/net/bnx2x/bnx2x_ethtool.c | 18 +++---
drivers/net/bnx2x/bnx2x_main.c | 19 +++---
drivers/net/bonding/bond_3ad.c | 32 ++++++----
drivers/net/bonding/bond_3ad.h | 3 +-
drivers/net/macvtap.c | 3 +-
drivers/net/r6040.c | 115 +++++++++++++++++++++----------------
drivers/net/smsc911x.c | 5 ++
net/Makefile | 4 +-
net/bridge/Kconfig | 1 +
net/core/pktgen.c | 2 +-
net/ipv4/devinet.c | 6 +-
net/ipv6/ip6_tunnel.c | 1 +
net/ipv6/route.c | 4 +-
net/rds/ib_send.c | 5 +-
net/rds/loop.c | 11 +++-
net/unix/af_unix.c | 17 ++++-
21 files changed, 182 insertions(+), 110 deletions(-)
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-10 23:49 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110310.153444.115930379.davem@davemloft.net>
On Thu, Mar 10, 2011 at 3:34 PM, David Miller <davem@davemloft.net> wrote:
>
> David S. Miller (3):
> ipv4: Fix erroneous uses of ifa_address.
> ipv6: Don't create clones of host routes.
> Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
David, why do you keep on doing those broken back-merges?
It's the _one_ thing you keep on doing wrong, and I don't understand
it. Just the merge message you get should tell you that you're doing
something total SH*T.
Look at that commit message:
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
That is literally the WHOLE message. Ask yourself: is that commit
doing anything useful? Does the commit message explain what it is
doing, and why you are doing it?
And if not (and if you came to some other conclusion than "no" to
either of those questions, you should explain it), then why do you do
it? It sure doesn't help me: it just makes it harder for me to
see/follow the history (and if it's harder for me to see, then it's
harder for _others_ to see). There was no conflict (I double-checked),
and there was no explanation for why it would be done.
Now, I admit that it's a git usability bug: for normal "git commit",
git will _force_ you to write a message, and sadly, for merges, I made
it instead just do the message automatically. My bad. I designed it
for the kind of merges I do, where the the automatic merge message
actually tells you what the merge is all about. But for back-merges,
the automatic message is totally worthless, and it is DOUBLY worthless
when you do it the way you do it, namely from some local directory of
your own.
That's just STUPID. Look at that message once more, and ponder. What does
"Merge branch 'master' of /home/davem/src/GIT/linux-2.6/"
tell anybody? It's not even pointing to my repository, and you have
actively BROKEN the small amount of smarts (as admitted above, not
enough) that git does do normally, which is at least tell you where
the merge comes from. You broke it by fetching my repository into your
own anonymous tree, and then merging it from there, and thus the
automatic merge message lost sight of the fact that it was my upstream
tree, because you had made it your own random repo.
Grr. This has been going on for too long. Don't do it. Don't do random
backwards merges without explanations, and with the actual source data
removed.
We're _really_ good at doing commit messages, and the kernel commit
log should be a great example to other projects. But in the last week
or so, I've now _twice_ had to flame core developers for making
totally useless commit messages.
So don't do back-merges. And if you DO do back-merges, don't make the
commit message totally useless.
You can use either 'git commit --amend" to fix the message afterwards
and explain WHY you did the stupid thing, or you can just do "git pull
--no-commit" to not actually commit the merge and then write your
commit message as you do it. But preferably you shouldn't do the
back-merges at all.
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2011-03-10 23:55 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTimnHtVS=SFopgyjAAQDW8bXDKDXf+YvEtPdpPsA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 10 Mar 2011 15:49:40 -0800
> Grr. This has been going on for too long. Don't do it. Don't do random
> backwards merges without explanations, and with the actual source data
> removed.
>
> We're _really_ good at doing commit messages, and the kernel commit
> log should be a great example to other projects. But in the last week
> or so, I've now _twice_ had to flame core developers for making
> totally useless commit messages.
>
> So don't do back-merges. And if you DO do back-merges, don't make the
> commit message totally useless.
>
> You can use either 'git commit --amend" to fix the message afterwards
> and explain WHY you did the stupid thing, or you can just do "git pull
> --no-commit" to not actually commit the merge and then write your
> commit message as you do it. But preferably you shouldn't do the
> back-merges at all.
I'm sorry about this, won't happen again.
I should have put:
Merge to get commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b
("net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules")
so that we can add Stephen Hemminger's fix to handle ip6 tunnels
as well, which uses the MODULE_ALIAS_NETDEV() macro created by
that change.
Again, sorry.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:01 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTimnHtVS=SFopgyjAAQDW8bXDKDXf+YvEtPdpPsA@mail.gmail.com>
On Thu, Mar 10, 2011 at 3:49 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Now, I admit that it's a git usability bug: for normal "git commit",
> git will _force_ you to write a message, and sadly, for merges, I made
> it instead just do the message automatically. My bad. I designed it
> for the kind of merges I do, where the the automatic merge message
> actually tells you what the merge is all about.
Btw, the reason I got really upset this time (and I've let it slide
before), is that this time your back-merge not only had that totally
useless merge message (that's happened before), but *because* you did
that back-merge, it also ends up making _my_ merge message totally
useless - the one that normally contains good and useful information
(a valid source of merging, and the abbreviated shortlog of what was
merged).
Why? Because you had done the back-merge very recently, my pull
request then ends up being a fast-forward, so your _useless_ merge
message basically entirely replaces the one that would have been
useful.
Yes, I could do it with "git pull --no-ff", but I have to admit to
hating adding more artificial merges into the tree just to get the
merge information. I didn't think the "--no-ff" flag was a good idea,
and I've never used it so far, but I have to say that now I'm
wavering.
I probably also should just talk to Junio and tell him that the whole
"totally automatic merge messages" was another horrible design
mistake. But if we do fix that in git, I suspect it will (a) break
scripts that expected the automatic silent merge and (b) take a long
time to percolate to people. So it might be one of those "we have to
live with it due to backwards compatibility reasons". Ugh.
Linus
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/7] be2net: Checksum field valid only for TCP/UDP
From: Ram Pai @ 2011-03-11 0:05 UTC (permalink / raw)
To: Padmanabh Ratnakar; +Cc: netdev, davem, Sathya Perla, Subramanian Seetharaman
In-Reply-To: <79e10ac8-3f25-4ee2-9a0d-08d39cd9fe9c@exht1.ad.emulex.com>
On Mon, Mar 07, 2011 at 06:38:16PM +0530, Padmanabh Ratnakar wrote:
> L4 checksum field is valid only for TCP/UDP packets in Lancer
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> Signed-off-by: Subramanian Seetharaman <subbu.seetharaman@emulex.com>
> ---
> drivers/net/benet/be_main.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
> index bf34434..ac7ae21 100644
> --- a/drivers/net/benet/be_main.c
> +++ b/drivers/net/benet/be_main.c
> @@ -865,14 +865,17 @@ static void be_rx_stats_update(struct be_rx_obj *rxo,
>
> static inline bool csum_passed(struct be_eth_rx_compl *rxcp)
> {
> - u8 l4_cksm, ipv6, ipcksm;
> + u8 l4_cksm, ipv6, ipcksm, tcpf, udpf;
>
> l4_cksm = AMAP_GET_BITS(struct amap_eth_rx_compl, l4_cksm, rxcp);
> ipcksm = AMAP_GET_BITS(struct amap_eth_rx_compl, ipcksm, rxcp);
> ipv6 = AMAP_GET_BITS(struct amap_eth_rx_compl, ip_version, rxcp);
> + tcpf = AMAP_GET_BITS(struct amap_eth_rx_compl, tcpf, rxcp);
> + udpf = AMAP_GET_BITS(struct amap_eth_rx_compl, udpf, rxcp);
>
> - /* Ignore ipcksm for ipv6 pkts */
> - return l4_cksm && (ipcksm || ipv6);
> + /* L4 checksum is not reliable for non TCP/UDP packets.
> + * Also ignore ipcksm for ipv6 pkts */
> + return (tcpf || udpf) && l4_cksm && (ipcksm || ipv6);
Is it invalid for non-Lancer too ? if not, then should'nt the
above condition be applied only for lancer?
RP
^ permalink raw reply
* Re: [PATCH 3/8] macb: convert printk to pr_ and friends
From: Jamie Iles @ 2011-03-11 0:09 UTC (permalink / raw)
To: Joe Perches; +Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <1299797284.20104.162.camel@Joe-Laptop>
On Thu, Mar 10, 2011 at 02:48:04PM -0800, Joe Perches wrote:
> On Thu, 2011-03-10 at 10:10 +0000, Jamie Iles wrote:
> > macb is already using the dev_dbg() and friends helpers so use pr_foo()
> > along with a pr_fmt() definition to make the printing a little cleaner.
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
>
> Hi Jamie.
>
> Because these conversions use a struct net_device,
> they would be better as:
>
> netdev_<foo>(struct net_device *dev, const char *fmt, ...)
Ahh nice, I hadn't come across those before. I'll update all of the
pr_* and dev_* statements to use the netdev variants.
Thanks for that!
Jamie
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:29 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110310.155556.48513201.davem@davemloft.net>
On Thu, Mar 10, 2011 at 3:55 PM, David Miller <davem@davemloft.net> wrote:
> I should have put:
>
> Merge to get commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b
> ("net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules")
> so that we can add Stephen Hemminger's fix to handle ip6 tunnels
> as well, which uses the MODULE_ALIAS_NETDEV() macro created by
> that change.
Yeah, that would have explained it. That said, if you are merging for
something like that, may I suggest actually starting off with
git merge 8909c9ad8ff03611c9c96c9a92656213e4bb495b
that then actually makes the history itself also show the relationship
(you'd still have to write the commit message explaining why,
otherwise git will try to be "helpful" by making the merge commit
message be
Merge commit '8909c9ad8ff03611c9c96c9a92656213e4bb495b'
which while _technically_ more useful and indicative of what you
wanted to do isn't actually any more readable than the one you have
now.
But the reason it would have been better is that it would literally
have made the git commit parenthood point to the commit you actually
care about.
Of course, since 'gitk' ends up highlighting the SHA1 pointers in the
commit message, even just mentioning it in the message is often almost
equivalent to having the parenthood be explicit. But it would show in
the actual history graph too, which I think would have been a good
thing.
Oh well. Water under the bridge. I think I'll try --no-ff this once,
despite my misgivings about the concept.
Linus
[ The reason I don't like "--no-ff" is that it can cause endless "I'm
going to add my own merge message" wars where people want to write
their name in the snow, and then doing cross-merges doesn't ever
actually converge on a single end-result. Fast-forward merges means
that people merging back-and-forth will always end up converging.
But I guess the whole notion of "upstream" vs "downstream" is the
thing that should be considered to be the real way to avoid that, and
if a project cannot agree on what's upstream and what is downstream, I
suspect the project has deeper problems than a few extra merge
messages ;^) ]
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:34 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTik3AyFTNoytebmOOZ=JSFMkt0bw7au-CSncUHJu@mail.gmail.com>
On Thu, Mar 10, 2011 at 4:29 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Oh well. Water under the bridge. I think I'll try --no-ff this once,
> despite my misgivings about the concept.
Oh wow. That really does end up looking odd. I know some other git
projects use --no-ff, but I don't think we've ever had them in the
kernel, and I've never see the graph look like that before.
But it did allow me to add an explanation for what happened, so maybe
it's worth it.
Linus
^ 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