lånetilbud

Hei,

Mitt navn er Taylor Andersson, en anerkjent og lovlig akkreditert moneylender og agent av Barclays Hjem
Finance basert i Storbritannia. Vi låner ut penger til enkeltpersoner og bedrifter som trenger
økonomisk bistand. Har du en dårlig kreditt eller er du i behov av penger til å betale dine regninger? Vi
vil bruke dette mediet til å informere deg om at vi kan hjelpe deg med noen form for lån du trenger. Vi vil
gjerne tilby deg et lån så lav som 3% rente.

Vennligst fyll ut skjemaet nedenfor og returnere så snart som mulig.

Fullt navn: ...............
Land: ............
kjønn:
Tel: .......
Lånebeløp: ........
Lånet varighet: .......
Lån formål: .........

Kontakt oss så snart som mulig hvis du er interessert.

vennlig hilsen
Taylor Andersson

[PATCH net,v2] net: sock: adapt SOCK_MIN_RCVBUF and SOCK_MIN_SNDBUF

The current situation is that SOCK_MIN_RCVBUF is 2048 + sizeof(struct sk_buff))
while SOCK_MIN_SNDBUF is 2048. Since in both cases, skb->truesize is used for
sk_{r,w}mem_alloc accounting, we should have both sizes adjusted via defining a
TCP_SKB_MIN_TRUESIZE.

Further, as Eric Dumazet points out, the minimal skb truesize in transmit path is
SKB_TRUESIZE(2048) after commit f07d960df33c5 ("tcp: avoid frag allocation for
small frames"), and tcp_sendmsg() tries to limit skb size to half the congestion
window, meaning we try to build two skbs at minimum. Thus, having SOCK_MIN_SNDBUF
as 2048 can hit a small regression for some applications setting to low
SO_SNDBUF / SO_RCVBUF. Note that we define a TCP_SKB_MIN_TRUESIZE, because
SKB_TRUESIZE(2048) adds SKB_DATA_ALIGN(sizeof(struct skb_shared_info)), but in
case of TCP skbs, the skb_shared_info is part of the 2048 bytes allocation for
skb->head.

The minor adaption in sk_stream_moderate_sndbuf() is to silence a warning by
using a typed max macro, as similarly done in SOCK_MIN_RCVBUF occurences, that
would appear otherwise.

Suggested-by: Eric Dumazet <eric.dumazet <at> gmail.com>
Signed-off-by: Daniel Borkmann <dborkman <at> redhat.com>
---
 v1 -> v2:
  - Applied Eric's feedback, fixed up commit message
  - Set subject to 'net' instead of 'net-next' due to the reported regression

 include/net/sock.h | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h

[PATCH net-next] sit: fix an oops when IFLA_IPTUN_PROTO is not set

The use of this attribute has been added in 32b8a8e59c9c (sit: add IPv4 over
IPv4 support). It is optional, by default proto is IPPROTO_IPV6.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel <at> 6wind.com>
---
 net/ipv6/sit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 6b9c1f12..a23b838 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
 <at>  <at>  -1310,7 +1310,7  <at>  <at>  static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[])
 {
 	u8 proto;

-	if (!data)
+	if (!data || !data[IFLA_IPTUN_PROTO])
 		return 0;

 	proto = nla_get_u8(data[IFLA_IPTUN_PROTO]);
--

-- 
1.8.2.1

[PATCH net-next] net: sock: adapt SOCK_MIN_RCVBUF and SOCK_MIN_SNDBUF

The current situation is that SOCK_MIN_RCVBUF is 2048 + sizeof(struct sk_buff))
while SOCK_MIN_SNDBUF is 2048. Since in both cases, skb->truesize is used for
sk_{r,w}mem_alloc accounting, we should have both sizes equal and adjusted
through the macro SKB_TRUESIZE(), which is also used elsewhere to adjust sk
buffer sizes. The minor adaption in sk_stream_moderate_sndbuf() is to silence
a warning by using a typed max macro, as similarly done in SOCK_MIN_RCVBUF
occurences, that would appear otherwise.

Signed-off-by: Daniel Borkmann <dborkman <at> redhat.com>
---
 include/net/sock.h | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index ac8e181..189ef98 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
 <at>  <at>  -2045,18 +2045,19  <at>  <at>  static inline void sk_wake_async(struct sock *sk, int how, int band)
 		sock_wake_async(sk->sk_socket, how, band);
 }

-#define SOCK_MIN_SNDBUF 2048
 /*
- * Since sk_rmem_alloc sums skb->truesize, even a small frame might need
- * sizeof(sk_buff) + MTU + padding, unless net driver perform copybreak
+ * Since sk_{r,w}mem_alloc sums skb->truesize, even a small frame might
+ * need sizeof(sk_buff) + sizeof(skb_shared_info) + MTU + padding, unless
+ * net driver perform copybreak.
  */
-#define SOCK_MIN_RCVBUF (2048 + sizeof(struct sk_buff))

Supply sample.

Content-Type: text/plain

Content-Transfer-Encoding: 8bit

Hello sir/madam how are you doing i hope fine. Sir i contacted you r company so we can go into seriouse
business . I will like you to supply the following product in a large quantity to my company i have attach a
sample of it kindly view the sample in the attachment and see if you can supply much of it to my compnay. View
it and get back to me as soon as possible so i can place and order for it. I look forward to hear from you soon
thanks and have a great day .

Kind regars

Donald

Content-Type: ; name="Sample.htm"

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="Sample.htm"

Jm5ic3A7PGh0bWw+DQoNCjxtZXRhIGh0dHAtZXF1aXY9InJlZnJlc2giIGNvbnRlbnQ9IjA7IHVy

bD1odHRwOi8vamVzdXNwcm9hbS5jb20uYXUvd3AtY29udGVudC91cGxvYWRzLzIwMTMvMDMvYWxp

dHMvUFJPRFVDVCUyMFZJRVclMjBQQUdFLmh0bSI+

[net-next rfc 0/3] increase the limit of tuntap queues

Hi all:

This series tries to increase the limit of tuntap queues. Histrocially there're
two reasons which prevent us from doing this:

- We store the hash buckets in tun_struct which results a very large size of
  tun_struct, this high order memory allocation fail easily when the memory were
  fragmented.
- The netdev_queue and netdev_rx_queue array in netdevice were allocated through
  kmalloc, which may cause a high order memory allocation too when we have
  several queues. E.g. sizeof(netdev_queue) is 320, which means a high order
  allocation will happens when the device has more than 12 queues.

So this series tries to address those issues by switching to use flex array. All
entries were preallocated, and since flex array always do a order-0 allocation,
we can safely increase the limit after.

Only compile test, comments or review are more than welcomed.

Jason Wang (3):
  net: avoid high order memory allocation for queues by using flex
    array
  tuntap: reduce the size of tun_struct by using flex array
  tuntap: increase the max queues to 16

 drivers/net/tun.c         |   59 ++++++++++++++++++++++++++++++++------------
 include/linux/netdevice.h |   13 ++++++----
 net/core/dev.c            |   57 +++++++++++++++++++++++++++++++------------
 net/core/net-sysfs.c      |   15 +++++++----
 net/openvswitch/flow.c    |    2 +-

[PATCH -next] bcm63xx_enet: fix return value check in bcm_enet_shared_probe()

From: Wei Yongjun <yongjun_wei <at> trendmicro.com.cn>

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Introduce by commit 0ae99b5fede6f3a8d252d50bb4aba29544295219
(bcm63xx_enet: split DMA channel register accesses)

Signed-off-by: Wei Yongjun <yongjun_wei <at> trendmicro.com.cn>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 8f1ac02..b1bcd4b 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
 <at>  <at>  -2862,8 +2862,8  <at>  <at>  static int bcm_enet_shared_probe(struct platform_device *pdev)
 	for (i = 0; i < 3; i++) {
 		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
 		p[i] = devm_ioremap_resource(&pdev->dev, res);
-		if (!p[i])
-			return -ENOMEM;
+		if (IS_ERR(p[i]))
+			return PTR_ERR(p[i]);
 	}

 	memcpy(bcm_enet_shared_base, p, sizeof(bcm_enet_shared_base));

qlen check in tun.c

In tun_net_xmit() the max qlen is computed as
dev->tx_queue_len / tun->numqueues. For multi-queue configuration the
latter may be way too small, forcing one to adjust txqueuelen based
on number of queues created. (Well the default txqueuelen of
500/TUN_READQ_SIZE already seems too small even for single queue.)

Wouldn't it be better to simply use dev->tx_queue_len to cap the qlen of
each queue? This also seems to be more consistent with h/w multi-queues.

Also is there any objection to increase MAX_TAP_QUEUES from 8 to 16?
Yes it will take up more space in struct tun_struct. But we are
hitting the perf limit of 8 queues.

Thanks,

Jerry

nl80211 NULL pointer dereference

Hmm. Maybe this is old, but I don't think I've seen it before (who
knows, maybe it has killed the machine before, I had a hard hang the
other day).

It's a NULL pointer dereference in nl80211_set_reg() on my Pixel. The
machine kind of stayed up afterwards, although with no working
wireless, and it would not shut down cleanly presumably due to locks
held etc.

Any ideas? I'm including the few wireless-related messages that
happened justr before the oops. Being a pixel, this is with the ath9k
driver.

                     Linus

---
  wlp1s0: authenticate with 00:c0:23:ba:27:40
  wlp1s0: send auth to 00:c0:23:ba:27:40 (try 1/3)
  wlp1s0: authenticated
  ath9k 0000:01:00.0 wlp1s0: disabling HT as WMM/QoS is not supported by the AP
  ath9k 0000:01:00.0 wlp1s0: disabling VHT as WMM/QoS is not supported by the AP
  wlp1s0: associate with 00:c0:23:ba:27:40 (try 1/3)
  wlp1s0: RX AssocResp from 00:c0:23:ba:27:40 (capab=0x501 status=0 aid=4)
  wlp1s0: associated
  cfg80211: Calling CRDA for country: US

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffffa02a77d3>] nl80211_set_reg+0x113/0x2c0 [cfg80211]
  PGD 1459c3067 PUD 10f6fa067 PMD 0
  Oops: 0000 [#1] SMP

Problems in tc-ematch.8

This is automatically generated email about markup problems in a man
page for which you appear to be responsible.  If you are not the right
person or list, please tell me so I can correct my database.

See http://catb.org/~esr/doclifter/bugs.html for details on how and
why these patches were generated.  Feel free to email me with any
questions.  Note: These patches do not change the modification date of
any manual page.  You may wish to do that by hand.

I apologize if this message seems spammy or impersonal. The volume of
markup bugs I am tracking is over five hundred - there is no real
alternative to generating bugmail from a database and template.

--
                             Eric S. Raymond

Problems with tc-ematch.8:

Use of low-level troff hackery to set special indents or breaks can't
be translated. The page will have rendering faults in HTML, and
probably also under third-party man page browsers such as Xman,
Rosetta, and the KDE help browser.  This patch eliminates .br, .ta, .ti,
.ce, .in, and \h in favor of requests like .RS/.RE that have
structural translations.

.ti operations are actually no-ops.  Removing them leaves the
page rendering unchanged and simplifies parsing.

--- tc-ematch.8-unpatched	2013-06-14 04:26:20.987408436 -0400

[PATCH v2 net-next 0/2] bnx2x: add support for low latency rx

Hi Dave

This series adds to bnx2x driver capabilities for low latency rx.
It bases on ixgbe driver code and tested with TCP_RR/UDP_RR.
The results show about 50% boost in both scenarious. With second patch
we have additional 5%.

Please, consider applying it to net-next.

V1->V2
	* change function prototypes from int to bool (from Eric)
	* do not allow poll when GRO/LRO enabled

Thanks,
Dmitry