* Re: [PATCHv2.1] net: wireless: iwlwifi: remove minor dead code
From: Emmanuel Grumbach @ 2013-11-12 5:24 UTC (permalink / raw)
To: Michal Nazarewicz, Johannes Berg
Cc: Sergei Shtylyov, Emmanuel Grumbach, John W. Linville,
Intel Linux Wireless, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <xa1tr4amwkrt.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
On 11/12/2013 02:01 AM, Michal Nazarewicz wrote:
> inta is checked to be zero in a IRQ_NONE branch so afterwards it
> cannot be zero as it is never modified.
>
> Signed-off-by: Michal Nazarewicz <mina86-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/net/wireless/iwlwifi/pcie/rx.c | 24 +++++++++---------------
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> On Mon, Nov 11 2013, Johannes Berg wrote:
>> no signed-off-by
>
> Sorry, fixed. Interestingly, I did not forget about it in my first patch.
>
no worries - I picked it up in our internal tree.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] core/dev: do not ignore dmac in dev_forward_skb()
From: Isaku Yamahata @ 2013-11-12 5:25 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Maciej Żenczykowski, isaku.yamahata, David S. Miller,
Eric Dumazet, Linux NetDev, Nicolas Dichtel, yamahatanetdev
In-Reply-To: <CAMEtUuzmZd0RXO+=YhCW7OwfE1kvc2aA2K0gqXRN+LwS-O1f2w@mail.gmail.com>
On Mon, Nov 11, 2013 at 05:12:10PM -0800,
Alexei Starovoitov <ast@plumgrid.com> wrote:
> On Mon, Nov 11, 2013 at 4:39 PM, Maciej Żenczykowski
> <zenczykowski@gmail.com> wrote:
> > Ack.
> >
> > I'm sure this breaks whatever the original commit was trying to 'fix',
> > however it does so in a clearly incorrect manner by effectively
> > disabling dst mac address filtering.
>
> actually it doesn't break it. Isaku's testcase works for me.
The changeset of 963a88b31ddbbe99f38502239b1a46601773d217
"tunnels: harmonize cleanup done on skb on xmit path"
addresses the issue by calling skb_scrub_packet() when sending skb
through tunnel. So it is safe to revert it.
thanks,
--
Isaku Yamahata <isaku.yamahata@gmail.com>
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Cong Wang @ 2013-11-12 6:48 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: netdev, stable
In-Reply-To: <8761s0cqhh.fsf@natisbad.org>
On Sun, 10 Nov 2013 at 13:53 GMT, Arnaud Ebalard <arno@natisbad.org> wrote:
> Hi,
>
> I decided to upgrade the kernel on one of my ReadyNAS 102 from 3.11.1 to
> 3.11.7. The device is based on Marvell Armada 370 SoC and uses mvneta
> driver. Mine runs Debian armel unstable but I can confirm the issue also
> happens on a debian harmhf unstable.
>
[...]
>
> Then, knowing that, I started a git bisect session on stable tree to end
> up with the following suspects. I failed to go any further to a single
> commit, due to crashes, but I could recompile a kernel w/ debug info and
> report what I get if neeeded.
>
> commit dc0791aee672 tcp: do not forget FIN in tcp_shifted_skb() [bad]
> commit 18ddf5127c9f tcp: must unclone packets before mangling them
> commit 80bd5d8968d8 tcp: TSQ can use a dynamic limit
> commit dbeb18b22197 tcp: TSO packets automatic sizing
> commit 50704410d014 Linux 3.11.6 [good]
>
This regression is probably introduced the last TSQ commit, Eric has a patch
for mvneta in the other thread:
http://article.gmane.org/gmane.linux.network/290359
^ permalink raw reply
* Re: [PATCH net-next v3 5/10] bonding: create bond_first_slave_rcu()
From: Ding Tianhong @ 2013-11-12 6:55 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131111125917.GX19702@redhat.com>
On 2013/11/11 20:59, Veaceslav Falico wrote:
> On Mon, Nov 11, 2013 at 08:36:41PM +0800, Ding Tianhong wrote:
>> The bond_first_slave_rcu() will be used to instead of bond_first_slave()
>> in rcu_read_lock().
>>
>> So move the struct netdev_adjacent to the netdevice.h and make the
>> bond_first_slave_rcu() could use the struct.
>
> The whole point in netdev_adjacent functions was to hide it from the users
> who wanted to use it directly. See
>
> http://www.spinics.net/lists/netdev/msg248026.html
>
> for reference. Please try to avoid that.
>
Hi, Veaceslav
following the point, I rebuild the bond_first_slave_rcu(),
if you have no comments, I will move it in the patch set.
Regards
Ding
+/* Caller must have rcu_read_lock */
+#define bond_first_slave_rcu(bond) \
+ netdev_lower_get_first_private_rcu(bond->dev)
+
#define bond_is_first_slave(bond, pos) (pos == bond_first_slave(bond))
#define bond_is_last_slave(bond, pos) (pos == bond_last_slave(bond))
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 15fa01c..abfcfad 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2869,6 +2869,7 @@ void *netdev_lower_get_next_private_rcu(struct net_device *dev,
priv = netdev_lower_get_next_private_rcu(dev, &(iter)))
void *netdev_adjacent_get_private(struct list_head *adj_list);
+void *netdev_lower_get_first_private_rcu(struct net_device *dev);
struct net_device *netdev_master_upper_dev_get(struct net_device *dev);
struct net_device *netdev_master_upper_dev_get_rcu(struct net_device *dev);
int netdev_upper_dev_link(struct net_device *dev, struct net_device *upper_dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index 8ffc52e..39bc202 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4570,6 +4570,27 @@ void *netdev_lower_get_next_private_rcu(struct net_device *dev,
EXPORT_SYMBOL(netdev_lower_get_next_private_rcu);
/**
+ * netdev_lower_get_first_private_rcu - Get the first ->private from the
+ * lower neighbour list, RCU
+ * variant
+ * @dev: device
+ *
+ * Gets the first netdev_adjacent->private from the dev's lower neighbour
+ * list. The caller must hold RCU read lock.
+ */
+void *netdev_lower_get_first_private_rcu(struct net_device *dev)
+{
+ struct netdev_adjacent *lower;
+
+ lower = list_first_or_null_rcu(&dev->adj_list.lower,
+ struct netdev_adjacent, list);
+ if (lower)
+ return lower->private;
+ return NULL;
+}
+EXPORT_SYMBOL(netdev_lower_get_first_private_rcu);
^ permalink raw reply related
* Re: TCP performance regression
From: Willy Tarreau @ 2013-11-12 7:42 UTC (permalink / raw)
To: David Laight; +Cc: Eric Dumazet, Sujith Manoharan, netdev, Dave Taht
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73FD@saturn3.aculab.com>
On Mon, Nov 11, 2013 at 04:35:30PM -0000, David Laight wrote:
> > > It should be ok if the mac driver only gives the hardware a small
> > > number of bytes/packets - or one appropriate for the link speed.
> >
> > There is some confusion here.
> >
> > mvneta has a TX ring buffer, which can hold up to 532 TX descriptors.
> >
> > If this driver used skb_orphan(), a single TCP flow could use the whole
> > TX ring.
> >
> > TCP Small Queue would only limit the number of skbs on Qdisc.
> >
> > Try then to send a ping message, it will have to wait a lot.
>
> 532 is a ridiculously large number especially for a slow interface.
> At a guess you don't want more than 10-20ms of data in the tx ring.
Well, it's not *that* large, 532 descriptors is 800 kB or 6.4 ms with
1500-bytes packets, and 273 microseconds for 64-byte packets. In fact
it's not a slow interface, it's the systems it runs on which are
generally not that fast. For example it is possible to saturate two
gig ports at once on a single-core Armada370. But you need buffers
large enough to compensate for the context switch time if you use
multiple threads to send.
Regards,
Willy
^ permalink raw reply
* Re: WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70()
From: Zhouping Liu @ 2013-11-12 7:45 UTC (permalink / raw)
To: linux-mm, LKML; +Cc: Mel Gorman, netdev
In-Reply-To: <988917896.22733181.1384226183266.JavaMail.root@redhat.com>
CC'ing netdev@ to make more relative people know it.
On 11/12/2013 11:16 AM, Zhouping Liu wrote:
> Hi All,
>
> I found the WARNING in the latest mainline with commint 8b5baa460b.
>
> [61323.305424] ------------[ cut here ]------------
> [61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70()
> [61323.319779] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache sg nfsd netxen_nic hpilo sp5100_tco auth_rpcgss hpwdt amd64_edac_mod edac_mce_amd microcode pcspkr shpchp serio_raw i2c_piix4 edac_core ipmi_si k10temp nfs_acl lockd ipmi_msghandler acpi_power_meter acpi_cpufreq sunrpc xfs libcrc32c radeon i2c_algo_bit drm_kms_helper ttm sd_mod crc_t10dif ata_generic crct10dif_common drm pata_acpi ahci libahci pata_atiixp libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod
> [61323.368625] CPU: 8 PID: 12860 Comm: swapoff Not tainted 3.12.0+ #1
> [61323.375452] Hardware name: HP ProLiant DL585 G7, BIOS A16 12/17/2012
> [61323.382463] 0000000000000009 ffff882dfce43e68 ffffffff816204b7 0000000000000000
> [61323.390692] ffff882dfce43ea0 ffffffff8106495d ffff88190b551d00 ffff88080ff0b600
> [61323.398940] ffff88080ff0b650 0000000000000001 ffff880810fe64a0 ffff882dfce43eb0
> [61323.407188] Call Trace:
> [61323.409916] [] dump_stack+0x45/0x56
> [61323.415616] [] warn_slowpath_common+0x7d/0xa0
> [61323.422257] [] warn_slowpath_null+0x1a/0x20
> [61323.428705] [] sk_clear_memalloc+0x49/0x70
> [61323.435094] [] xs_swapper+0x41/0x60 [sunrpc]
> [61323.441671] [] nfs_swap_deactivate+0x2d/0x30 [nfs]
> [61323.448796] [] destroy_swap_extents+0x61/0x70
> [61323.455436] [] SyS_swapoff+0x220/0x610
> [61323.461420] [] ? do_page_fault+0x1a/0x70
> [61323.467582] [] system_call_fastpath+0x16/0x1b
> [61323.474215] ---[ end trace 919f685513b38356 ]---
>
> I found the warning during doing swapoff the swap over NFS mount, so if you need to reproduce it,
> you should do the following:
> 1. Open CONFIG_NFS_SWAP in testing machine
> 2. Create a NFS server, and create a swap file in NFS server
> in NFS server: # dd if=/dev/zero of=/NFS_FOLDER/swapfile bs=1M count=1024; mkswap swapfile
> 3. Inside testing machine, setup a swap over NFS, then swapoff it, the swapoff action will
> trigger the WARNING.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Arnaud Ebalard @ 2013-11-12 7:56 UTC (permalink / raw)
To: Cong Wang; +Cc: linux-arm-kernel, netdev, stable, edumazet
In-Reply-To: <slrnl83jr5.49f.xiyou.wangcong@linux-6brj.site>
Hi,
Thanks for the pointer. See below.
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Sun, 10 Nov 2013 at 13:53 GMT, Arnaud Ebalard <arno@natisbad.org> wrote:
>> Hi,
>>
>> I decided to upgrade the kernel on one of my ReadyNAS 102 from 3.11.1 to
>> 3.11.7. The device is based on Marvell Armada 370 SoC and uses mvneta
>> driver. Mine runs Debian armel unstable but I can confirm the issue also
>> happens on a debian harmhf unstable.
>>
> [...]
>>
>> Then, knowing that, I started a git bisect session on stable tree to end
>> up with the following suspects. I failed to go any further to a single
>> commit, due to crashes, but I could recompile a kernel w/ debug info and
>> report what I get if neeeded.
>>
>> commit dc0791aee672 tcp: do not forget FIN in tcp_shifted_skb() [bad]
>> commit 18ddf5127c9f tcp: must unclone packets before mangling them
>> commit 80bd5d8968d8 tcp: TSQ can use a dynamic limit
>> commit dbeb18b22197 tcp: TSO packets automatic sizing
>> commit 50704410d014 Linux 3.11.6 [good]
>>
>
> This regression is probably introduced the last TSQ commit, Eric has a patch
> for mvneta in the other thread:
>
> http://article.gmane.org/gmane.linux.network/290359
I had some offline (*) discussions w/ Eric and did some test w/ the patches
he sent. It does not fix the regression I see. It would be nice if someone
w/ the hardware and more knowledge of mvneta driver could reproduce the
issue and spend some time on it.
That been said, even if the driver is most probably not the only one to
blame here (considering the result of bisect and current thread on
netdev), I never managed to get the performance I have on my ReadyNAS
Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
platform (RN102, RN104 or RN2120). Understanding why is on an already a
long todo list.
Cheers,
a+
(*): for some reasons, my messages to netdev and stable are not published
even though I can interact w/ {majordomo,autoanswer}@vger.kernel.org. I
poked postmaster@ bug got no reply yet.
^ permalink raw reply
* Re: [PATCH net-next FIX] RDMA/cma: Fix build breakage when infiniband is built-in
From: Or Gerlitz @ 2013-11-12 8:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, amirv, eyalpe
In-Reply-To: <20131111.004319.58572524940129607.davem@davemloft.net>
On 11/11/2013 07:43, David Miller wrote:
> I really want to merge the net-next tree as soon as possible so I
> committed the following:
>
> ====================
> [PATCH] vlan: Implement vlan_dev_get_egress_qos_mask as an inline.
>
> This is to avoid very silly Kconfig dependencies for modules
> using this routine.
>
> Signed-off-by: David S. Miller<davem@davemloft.net>
Dave, I have checked it in our environment and things work as expected,
thanks for taking care.
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Johannes Berg @ 2013-11-12 8:36 UTC (permalink / raw)
To: Karl Beldan
Cc: Hannes Frederic Sowa, Theodore Ts'o, Daniel Borkmann,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
fweimer-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet, linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131112003709.GA11824@gobelin>
On Tue, 2013-11-12 at 01:37 +0100, Karl Beldan wrote:
> > > 1) I'm pretty sure, but it would be good to get netdev confirmation,
> > > that the call to get_random_bytes() in
> > > net/mac80211/rc80211_minstrel.c's init_sample_table() can be replaced
> > > by calls to prandom_u32().
> >
> > Would make sense. I added wireless-devel to confirm.
> >
> > [...]
> > [ 0.673260] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.674024] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.675012] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.676032] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.677020] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.678011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.679011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [...]
> >
> > In total 80 calls to get_random_bytes.
> >
>
> It is already 8 times what rc80211_minstrel_ht_init uses.
> If you could apply on top of:
> http://marc.info/?l=linux-wireless&m=138392850030987&w=2
> although Johannes has not yet agreed/applied this.
I'll take the patch, I just wanted a more useful commit log :)
I guess if really needed I'll write that myself :(
Anyway, I can't comment on prandom_u32(), but it doesn't really have to
be all that random here, it's just sample tables for what order to try
things in. Technically that could even be static with some per-device
pertubation, I guess?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Willy Tarreau @ 2013-11-12 8:36 UTC (permalink / raw)
To: Arnaud Ebalard; +Cc: Cong Wang, edumazet, stable, linux-arm-kernel, netdev
In-Reply-To: <87y54u59zq.fsf@natisbad.org>
Hi Arnaud,
On Tue, Nov 12, 2013 at 08:56:25AM +0100, Arnaud Ebalard wrote:
> I had some offline (*) discussions w/ Eric and did some test w/ the patches
> he sent. It does not fix the regression I see. It would be nice if someone
> w/ the hardware and more knowledge of mvneta driver could reproduce the
> issue and spend some time on it.
I could give it a try but am falling very short of time at the moment.
> That been said, even if the driver is most probably not the only one to
> blame here (considering the result of bisect and current thread on
> netdev), I never managed to get the performance I have on my ReadyNAS
> Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
> platform (RN102, RN104 or RN2120). Understanding why is on an already a
> long todo list.
Yes I found that your original numbers were already quite low, so it is
also possible that you have a different problem (eg: faulty switch or
auto-negociation problem where the switch goes to half duplex because
the neta does not advertise nway or whatever) that is emphasized by the
latest changes.
> Cheers,
>
> a+
>
> (*): for some reasons, my messages to netdev and stable are not published
> even though I can interact w/ {majordomo,autoanswer}@vger.kernel.org. I
> poked postmaster@ bug got no reply yet.
I can confirm that I got this message from you on netdev so it should be OK
now.
Willy
^ permalink raw reply
* Re: [PATCH net] core/dev: do not ignore dmac in dev_forward_skb()
From: Nicolas Dichtel @ 2013-11-12 8:49 UTC (permalink / raw)
To: Alexei Starovoitov, David S. Miller
Cc: Eric Dumazet, netdev, Maciej Zenczykowski
In-Reply-To: <1384206735-4226-1-git-send-email-ast@plumgrid.com>
Le 11/11/2013 22:52, Alexei Starovoitov a écrit :
> commit 06a23fe31ca3
> ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
> and refactoring 64261f230a91
> ("dev: move skb_scrub_packet() after eth_type_trans()")
>
> are forcing pkt_type to be PACKET_HOST when skb traverses veth.
>
> which means that ip forwarding will kick in inside netns
> even if skb->eth->h_dest != dev->dev_addr
>
> Revert offending commit
>
> Fixes: 06a23fe31ca3 ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
> CC: Maciej Zenczykowski <zenczykowski@gmail.com>
> CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
skb_scrub_packet() is also called after eth_type_trans() in ip_tunnel_rcv().
I do it to be consistent with dev_forward_skb(), thus it should be inverted too.
^ permalink raw reply
* Re: linux-next: manual merge of the random tree with the net-next tree
From: Daniel Borkmann @ 2013-11-12 8:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Theodore Ts'o, linux-next, linux-kernel, Hannes Frederic Sowa,
David Miller, netdev
In-Reply-To: <20131112155549.c160273993147244ed6bc81d@canb.auug.org.au>
Hi Stephen,
On 11/12/2013 05:55 AM, Stephen Rothwell wrote:
> Hi Ted,
>
> Today's linux-next merge of the random tree got a conflict in
> drivers/char/random.c between commit 0244ad004a54 ("random32: add
> prandom_reseed_late() and call when nonblocking pool becomes
> initialized") from the net-next tree and commit 301f0595c0e7 ("random:
> printk notifications for urandom pool initialization") from the random
> tree.
>
> I fixed it up (probably not properly - see below) and can carry the fix
> as necessary (no action is required).
As per Hannes' suggestion, the result should look like (see cover
letter in [1]):
if (r->entropy_total > 128) {
r->initialized = 1;
r->entropy_total = 0;
if (r == &nonblocking_pool) {
prandom_reseed_late();
pr_notice("random: %s pool is initialized\n",
r->name);
}
}
Cheers,
Daniel
[1] http://thread.gmane.org/gmane.linux.network/290303
^ permalink raw reply
* [PATCH net] neigh: Force garbage collection if an entry is deleted administratively
From: Steffen Klassert @ 2013-11-12 8:57 UTC (permalink / raw)
To: David Miller; +Cc: YOSHIFUJI Hideaki, netdev
Since git commit 2724680 ("neigh: Keep neighbour cache entries if number
of them is small enough."), we keep all neighbour cache entries if the
number is below a threshold. But if we now delete an entry administratively
and then try to replace this by a permanent one, we get -EEXIST because the
old entry ist still in the table (in NUD_FAILED state).
So lets force a garbage collect if we delete an entry administratively.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/core/neighbour.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 6072610..ec20880 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1659,6 +1659,8 @@ static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh)
NEIGH_UPDATE_F_OVERRIDE |
NEIGH_UPDATE_F_ADMIN);
neigh_release(neigh);
+
+ neigh_forced_gc(tbl);
goto out;
}
read_unlock(&neigh_tbl_lock);
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Nicolas Dichtel @ 2013-11-12 8:59 UTC (permalink / raw)
To: Julian Anastasov
Cc: hannes, netdev, davem, David.Laight, jiri, vyasevich, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <alpine.LFD.2.03.1311091610090.1411@ssi.bg>
Le 09/11/2013 15:46, Julian Anastasov a écrit :
>
> Hello,
>
> On Sat, 9 Nov 2013, Nicolas Dichtel wrote:
>
>> This feature allows to a send packets with address source set to 0.0.0.0 even if
>> an ip address is available on another interface.
>>
>> It's useful for DHCP client, to allow them to use UDP sockets and be compliant
>> with the RFC2131, Section 4.1:
>>
>> 4.1 Constructing and sending DHCP messages
>> ...
>> DHCP messages broadcast by a client prior to that client obtaining
>> its IP address must have the source address field in the IP header
>> set to 0.
>>
>> Based on a previous work from
>> Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> ...
>
>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index 89909dd730dd..f58945187dbd 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>
> ...
>
>> + if (up->src_any && sk->sk_bound_dev_if) {
>> + struct net_device *dev;
>> + struct in_device *in_dev;
>> +
>> + rcu_read_lock();
>> + dev = dev_get_by_index_rcu(sock_net(sk), sk->sk_bound_dev_if);
>> + in_dev = dev ? __in_dev_get_rcu(dev) : NULL;
>> + if (!inet_confirm_addr(sock_net(sk), in_dev, 0, 0,
>> + RT_SCOPE_HOST))
>
> I don't have an opinion about UDP_SRC_ANY, just some
> comments...
>
> Can a simple !in_dev->ifa_list check replace the
> !inet_confirm_addr call? Looking at __inet_insert_ifa()
> it seems only 0.0.0.0 does not add an ifa. Long ago
> adding 0.0.0.0 was a way to create in_dev for dev but
> now in_dev is created on device registration, i.e. even
> before addresses are added.
>
> For the first patch, may be it is not needed.
> We have two choices:
>
> 1. Do not change args and just fix comments. Of course,
> it is tricky to use this function by using scope instead
> of in_dev as a key for device-specific matching because
> such interface is confusing.
I hesitated to take this choice, but I think that keeping the
original behavior is better.
>
> 2. Add 'net' arg and use in_dev as explained in my
> previous email. Not sure if changing args of exported
> function is acceptable.
FWIK, it's not a problem.
Regards,
Nicolas
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Arnaud Ebalard @ 2013-11-12 9:14 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Cong Wang, linux-arm-kernel, netdev, stable, edumazet
In-Reply-To: <20131112083633.GB10318@1wt.eu>
Hi,
Willy Tarreau <w@1wt.eu> writes:
>> That been said, even if the driver is most probably not the only one to
>> blame here (considering the result of bisect and current thread on
>> netdev), I never managed to get the performance I have on my ReadyNAS
>> Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
>> platform (RN102, RN104 or RN2120). Understanding why is on an already a
>> long todo list.
>
> Yes I found that your original numbers were already quite low,
Tests for the rgression were done w/ scp, and were hence limited by the
crypto (16MB/s using arcfour128). But I also did some tests w/ a simple
wget for a file served by Apache *before* the regression and I never got
more than 60MB/s from what I recall. Can you beat that?
> so it is also possible that you have a different problem (eg: faulty
> switch or auto-negociation problem where the switch goes to half
> duplex because the neta does not advertise nway or whatever) that is
> emphasized by the latest changes
Tested w/ back to back connections to the NAS from various hosts and
through different switch. Never saturated the link.
> I can confirm that I got this message from you on netdev so it should be OK
> now.
Good. Thanks for the info.
a+
^ permalink raw reply
* Re: xen-netback regression in 3.10.18
From: Ian Campbell @ 2013-11-12 9:27 UTC (permalink / raw)
To: David Miller; +Cc: david.vrabel, netdev, stable, paul.durrant, wei.liu2
In-Reply-To: <20131109.155705.1091114498622318881.davem@davemloft.net>
On Sat, 2013-11-09 at 15:57 -0500, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Thu, 7 Nov 2013 12:15:33 +0000
>
> > 3.10.18 included 279f438e36c0 (xen-netback: Don't destroy the netdev
> > until the vif is shut down) but this has a regression that was fixed by
> > dc62ccaccfb1 (xen-netback: transition to CLOSED when removing a VIF)
> >
> > dc62ccaccfb1 depends on ea732dff5cfa (xen-netback: Handle backend state
> > transitions in a more robust way) which is also a bug fix for certain
> > Windows frontend drivers and is thus also a stable candidate.
> >
> > Dave can you ensure these two commits are tagged for the next 3.10.y
> > stable release?
> >
> > ea732dff5cfa10789007bf4a5b935388a0bb2a8f
> > dc62ccaccfb139d9b04bbc5a2688a4402adbfab3
>
> Ian already asked me to do this,
Sorry, bit of a race condition after Dave V and I spoke. Seems like I
won by 3s ;-)
> and the commits are necessary for 3.11 -stable as well.
>
> They've been queued up.
Thanks.
Ian.
^ permalink raw reply
* RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: David Laight @ 2013-11-12 9:43 UTC (permalink / raw)
To: Alan Stern; +Cc: Sarah Sharp, netdev, linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1311111525480.17105-100000@netrider.rowland.org>
> You're right. I do wish the spec had been written more clearly.
I've read a lot of hardware specs in my time ...
> > Reading it all again makes me think that a LINK trb is only
> > allowed on the burst boundary (which might be 16k bytes).
> > The only real way to implement that is to ensure that TD never
> > contain LINK TRB.
>
> That's one way to do it. Or you could allow a Link TRB at an
> intermediate MBP boundary.
If all the fragments are larger than the MBP (assume 16k) then
that would be relatively easy. However that is very dependant
on the source of the data. It might be true for disk data, but
is unlikely to be true for ethernet data.
For bulk data the link TRB can be forced at a packet boundary
by splitting the TD up - the receiving end won't know the difference.
> It comes down to a question of how often you want the controller to
> issue an interrupt. If a ring segment is 4 KB (one page), then it can
> hold 256 TRBs. With scatter-gather transfers, each SG element
> typically refers to something like a 2-page buffer (depends on how
> fragmented the memory is). Therefore a ring segment will describe
> somewhere around 512 pages of data, i.e., something like 2 MB. Since
> SuperSpeed is 500 MB/s, you'd end up getting in the vicinity of 250
> interrupts every second just because of ring segment crossings.
250 interrupts/sec is noise. Send/receive 13000 ethernet packets/sec
and then look at the interrupt rate!
There is no necessity for taking an interrupt from every link segment.
OTOH an interrupt is requested for every bulk TD.
I'm sending ethernet data (with TSO) and each TD is just under 64k
mostly made up of 3 or 4 fragments.
The receive side is interrupting for every receive packet.
> Using larger ring segments would help.
The current ring segments contain 64 entries, a strange choice
since they are created with 2 segments.
(The ring expansion code soon doubles that for my ethernet traffic.)
I would change the code to use a single segment (for coding simplicity)
and queue bulk URB when there isn't enough ring space.
URB with too many fragments could either be rejected, sent in sections,
or partially linearised (and probably still sent in sections).
David
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Willy Tarreau @ 2013-11-12 10:01 UTC (permalink / raw)
To: Arnaud Ebalard; +Cc: Cong Wang, edumazet, linux-arm-kernel, stable, netdev
In-Reply-To: <87a9hagex1.fsf@natisbad.org>
Hi Arnaud,
On Tue, Nov 12, 2013 at 10:14:34AM +0100, Arnaud Ebalard wrote:
> Tests for the rgression were done w/ scp, and were hence limited by the
> crypto (16MB/s using arcfour128). But I also did some tests w/ a simple
> wget for a file served by Apache *before* the regression and I never got
> more than 60MB/s from what I recall. Can you beat that?
Yes, I finally picked my mirabox out of my bag for a quick test. It boots
off 3.10.0-rc7 and I totally saturate one port (stable 988 Mbps) with even
a single TCP stream.
With two systems, one directly connected (dockstar) and the other one via
a switch, I get 2*650 Mbps (a single TCP stream is enough on each).
I'll have to re-run some tests using a more up to date kernel, but that
will probably not be today though.
Regards,
Willy
^ permalink raw reply
* [PATCH net 1/2] tuntap: limit head length of skb allocated
From: Jason Wang @ 2013-11-12 10:02 UTC (permalink / raw)
To: davem, netdev, linux-kernel, mst, stefanha; +Cc: Jason Wang
We currently use hdr_len as a hint of head length which is advertised by
guest. But when guest advertise a very big value, it can lead to an 64K+
allocating of kmalloc() which has a very high possibility of failure when host
memory is fragmented or under heavy stress. The huge hdr_len also reduce the
effect of zerocopy or even disable if a gso skb is linearized in guest.
To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
head, which guarantees an order 0 allocation each time.
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
The patch was needed for stable.
---
drivers/net/tun.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7cb105c..5537b65 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -954,6 +954,11 @@ static struct sk_buff *tun_alloc_skb(struct tun_file *tfile,
struct sock *sk = tfile->socket.sk;
struct sk_buff *skb;
int err;
+ int good_linear = SKB_MAX_HEAD(prepad);
+
+ /* Don't use huge linear part */
+ if (linear > good_linear)
+ linear = good_linear;
/* Under a page? Don't bother with paged skb. */
if (prepad + len < PAGE_SIZE || !linear)
--
1.8.3.2
^ permalink raw reply related
* [PATCH net 2/2] macvtap: limit head length of skb allocated
From: Jason Wang @ 2013-11-12 10:02 UTC (permalink / raw)
To: davem, netdev, linux-kernel, mst, stefanha; +Cc: Jason Wang
In-Reply-To: <1384250577-20330-1-git-send-email-jasowang@redhat.com>
We currently use hdr_len as a hint of head length which is advertised by
guest. But when guest advertise a very big value, it can lead to an 64K+
allocating of kmalloc() which has a very high possibility of failure when host
memory is fragmented or under heavy stress. The huge hdr_len also reduce the
effect of zerocopy or even disable if a gso skb is linearized in guest.
To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
head, which guarantees an order 0 allocation each time.
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
The patch was needed for stable.
---
drivers/net/macvtap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 9dccb1e..7ee6f9d 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -523,6 +523,11 @@ static inline struct sk_buff *macvtap_alloc_skb(struct sock *sk, size_t prepad,
int noblock, int *err)
{
struct sk_buff *skb;
+ int good_linear = SKB_MAX_HEAD(prepad);
+
+ /* Don't use huge linear part */
+ if (linear > good_linear)
+ linear = good_linear;
/* Under a page? Don't bother with paged skb. */
if (prepad + len < PAGE_SIZE || !linear)
--
1.8.3.2
^ permalink raw reply related
* RE: Handle new frag_list of frags GRO packets
From: David Laight @ 2013-11-12 10:12 UTC (permalink / raw)
To: Herbert Xu, Eric Dumazet
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131111185207.GA12277@gondor.apana.org.au>
> Recently GRO started generating packets with frag_lists of frags.
> This was not handled by GSO, thus leading to a crash.
Is the build_dma_sg() code in net/usb/usbnet.c correct?
It creates a 'struct scatterlist' array for all the fragments
in and skb.
I'm not at clear of exactly how skb get put together.
David
^ permalink raw reply
* Re: bridge not getting ip since 3.11.5 and 3.4.66
From: Mark Trompell @ 2013-11-12 10:57 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux-Kernel, netdev
In-Reply-To: <CAEPa5y=tgdGpDMBGY0ijyWSgQ0m5SZW8EMP072OF=sZZUjqN1g@mail.gmail.com>
On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote:
> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote:
>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66,
>>> What information would be helpful and required to find out what's going wrong.
>>
>> CC netdev
>>
>> First thing would be to provide the network scheme. Do you use vlans?
>> Which network
>> cards/drivers are you using? Do you use some kind of virtualization?
>> Is bonding involved?
>>
> Actually this is my desktop machine using kvm for a virtual machine
> that uses eth0 which is connected to the bridge
> which is used as interface for the host.
>
> $ ip addr
> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
> master br0 qlen 1000
> ...
> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
> ...
>
> Anything else?
Okay more about my hardware and configuration:
from lspci:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 04)
/etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
ONBOOT=yes
MACADDR=00:19:99:ac:b3:24
TYPE=Bridge
BOOTPROTO=dhcp
STP=on
NM_CONTROLLED=no
DELAY=0
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:19:99:cd:a5:e6
#BOOTPROTO=dhcp
ONBOOT=yes
BRIDGE=br0
TYPE=Ethernet
NM_CONTROLLED=no
> Greetings
> Mark
^ permalink raw reply
* Re: IPv6: Blackhole route support partial ?
From: Kamala R @ 2013-11-12 11:09 UTC (permalink / raw)
To: Kamala R, davem, linux-kernel, netdev
In-Reply-To: <20131111203954.GB3043@order.stressinduktion.org>
Hi,
Sure, here it is.
--- linux-3.12/net/ipv6/route.c.orig 2013-11-12 16:23:46.000000000 +0530
+++ linux-3.12/net/ipv6/route.c 2013-11-12 16:30:51.000000000 +0530
@@ -1570,9 +1570,13 @@ int ip6_route_add(struct fib6_config *cf
switch (cfg->fc_type) {
case RTN_BLACKHOLE:
rt->dst.error = -EINVAL;
+ rt->dst.input = dst_discard;
+ rt->dst.discard = dst_discard;
break;
case RTN_PROHIBIT:
rt->dst.error = -EACCES;
+ rt->dst.input = ip6_pkt_prohibit;
+ rt->dst.output = ip6_pkt_prohibit_out;
break;
case RTN_THROW:
rt->dst.error = -EAGAIN;
Is this ok ?
Regards,
Kamala
On Tue, Nov 12, 2013 at 2:09 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Hello!
>
> On Mon, Nov 11, 2013 at 07:25:14PM +0530, Kamala R wrote:
>> On adding IPv6 blackhole routes, ICMP unreachable messages are being
>> sent back to source. According to the definition, packets destined to
>> a blackhole address must be dropped silently.
>
> Yes, this is a bug.
>
>> I applied the patch submitted to the 3.7 kernel that indicates that it
>> supports blackhole and prohibit routes correctly. However, the patch
>> only sets the error code and route type correctly, so the show command
>> displays the appropriate output.
>>
>>
>> It seems to me that the input and output function pointers of the dst
>> variable, which determine packet processing, need to be set to
>> dst_discard. This would enable correct behaviour for blackhole routes.
>> Am I on the right path here ?
>
> I think you are. ip6_pkt_discard is not the correct input/output
> function for blackhole routes. In ip6_route_add simply set up the
> function pointers in the switch instead to just initializing them to
> ip6_pkt_discard. dst_discard is fine. Looks like prohibit rules are not
> handled correctly either. They should go to ip6_pkt_prohibit. (Just look at
> how the templates are initialized.)
>
> Could you cook a patch?
>
> Thanks,
>
> Hannes
>
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Karl Beldan @ 2013-11-12 11:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Hannes Frederic Sowa, Theodore Ts'o, Daniel Borkmann,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
fweimer-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet, linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1384245375.14301.1.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
On Tue, Nov 12, 2013 at 09:36:15AM +0100, Johannes Berg wrote:
> On Tue, 2013-11-12 at 01:37 +0100, Karl Beldan wrote:
>
> > > > 1) I'm pretty sure, but it would be good to get netdev confirmation,
> > > > that the call to get_random_bytes() in
> > > > net/mac80211/rc80211_minstrel.c's init_sample_table() can be replaced
> > > > by calls to prandom_u32().
> > >
> > > Would make sense. I added wireless-devel to confirm.
> > >
> > > [...]
> > > [ 0.673260] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.674024] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.675012] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.676032] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.677020] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.678011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.679011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [...]
> > >
> > > In total 80 calls to get_random_bytes.
> > >
> >
> > It is already 8 times what rc80211_minstrel_ht_init uses.
> > If you could apply on top of:
> > http://marc.info/?l=linux-wireless&m=138392850030987&w=2
> > although Johannes has not yet agreed/applied this.
>
> I'll take the patch, I just wanted a more useful commit log :)
>
The commit log still feels very right to me, but I don't want you to go
grumpy ;) and will reword the log - Hannes, have you staged replacing
get_random_bytes with prandom_u32 already or can I do it in a reworded
v2 for minstrel ?
> I guess if really needed I'll write that myself :(
>
> Anyway, I can't comment on prandom_u32(), but it doesn't really have to
> be all that random here, it's just sample tables for what order to try
> things in. Technically that could even be static with some per-device
> pertubation, I guess?
>
The LFSR is way enough for minstrel, as for moving from prandom to
handcrafted sample table, this will be another discussion I guess.
Karl
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* FW: [REGRESSION] be2net: not work in 3.12
From: Sathya Perla @ 2013-11-12 11:13 UTC (permalink / raw)
To: Guo Chao (yan@linux.vnet.ibm.com); +Cc: netdev@vger.kernel.org
In-Reply-To: <20131112010807.GA6044@yanx>
> -----Original Message-----
> From: Guo Chao [mailto:yan@linux.vnet.ibm.com]
>
> Hello:
>
> After commit 92bf14ab(be2net: refactor be_get_resources() code),
> be2net is not working on a PowerPC machine.
>
> [ 72.653560] be2net 0001:01:00.0: Could not use PCIe error reporting
> [ 73.933727] be2net 0001:01:00.0: Max: txqs 8, rxqs 8, rss 7, eqs 0,
> vfs 20
> [ 73.933794] be2net 0001:01:00.0: Max: uc-macs 64, mc-macs 64, vlans 8
> [ 73.933875] be2net 0001:01:00.0: MSIx enable failed
> [ 73.973728] be2net 0001:01:00.0: created 0 TX queue(s)
> [ 73.973795] be2net 0001:01:00.0: created -1 RSS queue(s) and 1
> default RX queue
> [ 74.013735] be2net 0001:01:00.0: opcode 12-1 failed:status 3-11
> [ 74.013811] be2net 0001:01:00.0: queue_setup failed
> [ 74.013949] be2net 0001:01:00.0: Emulex OneConnect(Lancer)
> initialization failed
> [ 74.014018] be2net: probe of 0001:01:00.0 failed with error -1
>
> This change makes it work:
>
> --- a/drivers/net/ethernet/emulex/benet/be_cmds.c
> +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
> @@ -3187,6 +3187,8 @@ static void be_copy_nic_desc(struct be_resources
> *res,
> res->max_rss_qs = le16_to_cpu(desc->rssq_count);
> res->max_rx_qs = le16_to_cpu(desc->rq_count);
> res->max_evt_qs = le16_to_cpu(desc->eq_count);
> + if (res->max_evt_qs == 0)
> + res->max_evt_qs = 8;
> /* Clear flags that driver is not interested in */
> res->if_cap_flags = le32_to_cpu(desc->cap_flags) &
> BE_IF_CAP_FLAGS_WANT;
>
> Looks like firmware returns corrupted value. Can you fall back all
> limits to static ones if detected this?
Could you report the old (working) FW version and the new (broken) FW version.
This clearly seems like a FW bug and I think it should be fixed in FW rather than
the driver.
thanks,
-Sathya
^ 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