* Re: [PATCH] hamachi: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, joe, jpirko, adobriyan, shemminger, netdev,
linux-kernel
In-Reply-To: <1278332023-16524-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:13:41 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ksz884x: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, eric.dumazet, jpirko, dkirjanov, netdev,
linux-kernel
In-Reply-To: <1278332040-17160-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:13:58 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] lance: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, joe, shemminger, eric.dumazet, kaber, netdev,
linux-kernel
In-Reply-To: <1278332046-17195-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:14:03 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mac89x0: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, joe, eric.dumazet, kaber, tj, netdev,
linux-kernel
In-Reply-To: <1278332051-17760-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:14:09 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] natsemi: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, thockin, jpirko, joe, bhutchings, shemminger,
netdev, linux-kernel
In-Reply-To: <1278332059-17795-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:14:17 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: Hagen Paul Pfeifer @ 2010-07-06 2:07 UTC (permalink / raw)
To: Philip Prindeville; +Cc: Alexander Clouter, netdev
In-Reply-To: <4C321EAF.9000508@redfish-solutions.com>
* Philip Prindeville | 2010-07-05 12:04:31 [-0600]:
>I understand that. That's part of the reason that I've submitted
>patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>etc. There is pressure within certain technical groups to get ISP's
>to voluntarily implement RFC-4594... that's the carrot. The stick
>being FCC heavy-handed regulation of the ISP's if they don't.
Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
operation? At the end the user/service is still required to set his service
class, but this time with CAP_NET_ADMIN. Do you think that Service
Providers/Transit Providers trust (and this is the critical aspect) customers
based on some IP flags - this is extreme unlikely. 99% of users have
effective CAP_NET_ADMIN capabilities - and you cannot stop using them.
Service Providers/Transit Providers will trust customers who pays more and
then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
other customers will be treated normal, with zeroed DSCP. It makes no sense
for ISP's to shift the trust aspect to the customer side.
HGN
^ permalink raw reply
* Re: [PATCH] starfire: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, ionut, joe, jpirko, shemminger, akpm, netdev,
linux-kernel
In-Reply-To: <1278332077-18431-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:14:34 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ni52: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, joe, jpirko, shemminger, jkosina, netdev,
linux-kernel
In-Reply-To: <1278332065-17831-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:14:23 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ns83820: Use the instance of net_device_stats from net_device.
From: David Miller @ 2010-07-06 2:07 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, adobriyan, shemminger, tj, jpirko, netdev,
linux-kernel
In-Reply-To: <1278332071-17865-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Mon, 5 Jul 2010 16:14:28 +0400
> Since net_device has an instance of net_device_stats,
> we can remove the instance of this from the adapter structure.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ks8842: Replace usage of dev_dbg with netdev_dbg
From: David Miller @ 2010-07-06 2:08 UTC (permalink / raw)
To: richard.rojfors; +Cc: netdev
In-Reply-To: <1278285999.2594.4.camel@debian>
From: Richard Röjfors <richard.rojfors@pelagicore.com>
Date: Mon, 05 Jul 2010 01:26:39 +0200
> This patch replaces all usage of dev_dbg with netdev_dbg.
>
> A side effect is that the pointer to the platform device in the adapter
> struct can be removed.
>
> Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
Applied.
^ permalink raw reply
* Re: [PATCH] usbnet: remove direct access to urb->status
From: David Miller @ 2010-07-06 2:08 UTC (permalink / raw)
To: oneukum; +Cc: netdev
In-Reply-To: <201007021558.25774.oneukum@suse.de>
From: Oliver Neukum <oneukum@suse.de>
Date: Fri, 2 Jul 2010 15:58:25 +0200
> From a2e8da61490cba876b1b4814c4832822527c43dd Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oliver@neukum.org>
> Date: Fri, 2 Jul 2010 15:51:55 +0200
> Subject: [PATCH] usbnet: remove direct access to urb->status
>
> USB drivers should not use urb->status directly because
> it is scheduled to become a parameter. This does the conversion
> for drivers/net/usb
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: use skb_dst_copy() in ip_copy_metadata()
From: David Miller @ 2010-07-06 2:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1278064102.2530.29.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 02 Jul 2010 11:48:22 +0200
> Avoid touching dst refcount in ip_fragment().
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] igb: drop support for UDP hashing w/ RSS
From: David Miller @ 2010-07-06 2:08 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, alexander.h.duyck
In-Reply-To: <20100702060056.16863.23072.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 01 Jul 2010 23:01:05 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change removes UDP from the supported protocols for RSS hashing. The
> reason for removing this protocol is because IP fragmentation was causing a
> network flow to be broken into two streams, one for fragmented, and one for
> non-fragmented and this in turn was causing out-of-order issues.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: use netif_<level> instead of netdev_<level>
From: David Miller @ 2010-07-06 2:09 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, joe, emil.s.tantilov
In-Reply-To: <20100702060508.17100.39352.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 01 Jul 2010 23:05:12 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> This patch restores the ability to set msglvl through ethtool.
> The issue was introduced by:
> commit 849c45423c0c108e08d67644728cc9b0ed225fa1
>
> CC: Joe Perches <joe@perches.com>
>
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 05/11] isdn/gigaset: improve CAPI message debugging
From: David Miller @ 2010-07-06 2:23 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705-patch-gigaset-05.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Tue, 6 Jul 2010 02:18:59 +0200 (CEST)
> @@ -384,7 +388,7 @@ void gigaset_skb_sent(struct bc_state *bcs, struct sk_buff *dskb)
>
> /* don't send further B3 messages if disconnected */
> if (bcs->apconnstate < APCONN_ACTIVE) {
> - gig_dbg(DEBUG_LLDATA, "disconnected, discarding ack");
> + gig_dbg(DEBUG_MCMD, "disconnected, discarding ack");
> return;
> }
This is against something other than net-next-2.6 even with your
other two ISDN patches applied, because all of these lines read
"if (ap->connected ..."
Please tell me what exactly these patches are against so that I
can apply them to net-next-2.6 cleanly.
^ permalink raw reply
* Re: [PATCH 2/2] isdn: avoid calling tty_ldisc_flush() in atomic context
From: David Miller @ 2010-07-06 2:24 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel, stable
In-Reply-To: <20100705-patch-isdn-02.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Tue, 6 Jul 2010 02:18:27 +0200 (CEST)
> Remove the call to tty_ldisc_flush() from the RESULT_NO_CARRIER
> branch of isdn_tty_modem_result(), as already proposed in commit
> 00409bb045887ec5e7b9e351bc080c38ab6bfd33.
> This avoids a "sleeping function called from invalid context" BUG
> when the hardware driver calls the statcallb() callback with
> command==ISDN_STAT_DHUP in atomic context, which in turn calls
> isdn_tty_modem_result(RESULT_NO_CARRIER, ~), and from there,
> tty_ldisc_flush() which may sleep.
>
> Impact: bugfix
> Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/isdn: CAPI controller interface amendment
From: David Miller @ 2010-07-06 2:24 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705-patch-isdn-01.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Tue, 6 Jul 2010 02:18:22 +0200 (CEST)
> Mention that the CAPI controller methods load_firmware() and
> reset_ctr() are asynchronous, and should signal completion.
>
> Impact: documentation
> Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Applied to net-next-2.6
Please stop using "Impact: " tags, I just edit them out when
I add your changes.
^ permalink raw reply
* Re: [PATCH 1/4] net: add driver hooks for time stamping.
From: David Miller @ 2010-07-06 2:39 UTC (permalink / raw)
To: richardcochran; +Cc: netdev
In-Reply-To: <20100705.190301.48512969.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 05 Jul 2010 19:03:01 -0700 (PDT)
> From: Richard Cochran <richardcochran@gmail.com>
> Date: Mon, 5 Jul 2010 07:31:07 +0200
>
>> This patch adds hooks for transmit and receive time stamps. The
>> transmit hook allows a software fallback for transmit time stamps,
>> for MACs lacking time stamping hardware. The receive hook does not yet
>> have any effect, but it prepares the way for hardware time stamping
>> in PHY devices. Using the hooks will still require adding two inline
>> function calls to each MAC driver.
>>
>> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
>
> Applied.
Actually, this breaks the build.
There are drivers that never saw phylib.h included in them,
which use internal static functions named "phy_read()" and such
which match global interfaces defined in phylib.h
drivers/net/tulip/dmfe.c:334:12: error: conflicting types for 'phy_read'
include/linux/phy.h:437:19: note: previous definition of 'phy_read' was here
drivers/net/tulip/dmfe.c:335:13: error: conflicting types for 'phy_write'
include/linux/phy.h:452:19: note: previous definition of 'phy_write' was here
You're going to need to resolve this issue first, then make sure at a
minimum that an "allmodconfig" build fully passes with an
unconditional include of phylib.h in skbuff.h
I've reverted all of your patches.
^ permalink raw reply
* RE: Splice status
From: Ofer Heifetz @ 2010-07-06 2:36 UTC (permalink / raw)
To: Changli Gao, Eric Dumazet; +Cc: Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <AANLkTim_eBmT-6HmkqG5d7k0jjrGKAFBjzqVCricTpgK@mail.gmail.com>
Regarding your remark of replacing sendfile with recvfile, I have two questions:
1) what will be used if both are enabled in smb.conf
2) from your experience, which is faster for reading files?
________________________________________
From: Changli Gao [xiaosuo@gmail.com]
Sent: Tuesday, July 06, 2010 5:01 AM
To: Eric Dumazet
Cc: Jens Axboe; Ofer Heifetz; netdev@vger.kernel.org
Subject: Re: Splice status
On Mon, Jul 5, 2010 at 8:50 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 05 juillet 2010 à 13:52 +0300, Ofer Heifetz a écrit :
>> I am using Samba, so from my understanding of the source code, it
> loops and performs splice(sock, pipe) and splice(pipe, fd). There is no
> flush of any sort in between.
>>
>> When you say drain you mean to flush all data to pipe?
>>
>
> Draining pipe before splice() call would only trigger the bug less
> often.
If we don't drain the pipe before calling splice(2), the data spliced
from pipe maybe not be what we expect. Then data corruption occurs.
>
> splice(sock, pipe) can block if caller dont use appropriate "non
> blocking pipe' splice() mode, even if pipe is empty before a splice()
> call.
I don't think it is expected. The code of sys_recvfile is much like
the sendfile(2) implementation in kernel. If sys_recvfile may block
without non_block flag, sendfile(2) may block too.
BTW: Samba can use sendfile(2) instead in sys_recvfile.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: bridge br_multicast: BUG: unable to handle kernel NULL pointer dereference
From: David Miller @ 2010-07-06 3:07 UTC (permalink / raw)
To: herbert; +Cc: frank.arnold, shemminger, yoshfuji, netdev
In-Reply-To: <20100706005008.GA11699@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 6 Jul 2010 08:50:08 +0800
> On Tue, Jul 06, 2010 at 08:48:35AM +0800, Herbert Xu wrote:
>>
>> bridge: Restore NULL check in br_mdb_ip_get
>
> Resend with proper attribution.
>
> bridge: Restore NULL check in br_mdb_ip_get
>
> Somewhere along the line the NULL check in br_mdb_ip_get went
> AWOL, causing crashes when we receive an IGMP packet with no
> multicast table allocated.
It got removed by:
--------------------
commit 8ef2a9a59854994bace13b5c4f7edc2c8d4d124e
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun Apr 18 12:42:07 2010 +0900
bridge br_multicast: Make functions less ipv4 dependent.
Introduce struct br_ip{} to store ip address and protocol
and make functions more generic so that we can support
both IPv4 and IPv6 with less pain.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--------------------
> This patch restores it and ensures all br_mdb_*_get functions
> use it.
>
> Reported-by: Frank Arnold <frank.arnold@amd.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/ne: fix memory leak in ne_drv_probe()
From: David Miller @ 2010-07-06 3:08 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, joe, anemo, netdev, linux-kernel
In-Reply-To: <1278170444-8170-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Sat, 3 Jul 2010 19:20:42 +0400
> net_device allocated with alloc_eip_netdev() must be freed.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: Philip Prindeville @ 2010-07-06 3:08 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Alexander Clouter, netdev
In-Reply-To: <20100706020734.GA2972@nuttenaction>
On 7/5/10 8:07 PM, Hagen Paul Pfeifer wrote:
> * Philip Prindeville | 2010-07-05 12:04:31 [-0600]:
>
>
>> I understand that. That's part of the reason that I've submitted
>> patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>> etc. There is pressure within certain technical groups to get ISP's
>> to voluntarily implement RFC-4594... that's the carrot. The stick
>> being FCC heavy-handed regulation of the ISP's if they don't.
>>
> Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
> operation? At the end the user/service is still required to set his service
> class, but this time with CAP_NET_ADMIN. Do you think that Service
> Providers/Transit Providers trust (and this is the critical aspect) customers
> based on some IP flags - this is extreme unlikely. 99% of users have
> effective CAP_NET_ADMIN capabilities - and you cannot stop using them.
>
QoS is expensive to implement, since it requires a lot more inspection
of the packet, multiple queues, bandwidth reservation, etc.
ISP's are going to look for an excuse not to implement it.
Having it be exploited by users is another arrow in their quill to not
implement it.
Yes, most users have admin/privileged rights on their machines, but
don't know enough to exploit that.
Whatever makes it harder to abusively exploit QoS seems like a good
idea. Harder. Not impossible.
"Stopping them" was never the objective.
> Service Providers/Transit Providers will trust customers who pays more and
> then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
> other customers will be treated normal, with zeroed DSCP. It makes no sense
> for ISP's to shift the trust aspect to the customer side.
>
> HGN
>
>
>
Alas there's more to it than that: the movement is to make QoS be
ubiquitous for all SLA's of broadband.
I'd argue that it makes no sense for them not to trust it: SDP/RTP
packets are hard to identify as such without peaking into the
accompanying SIP conversation... which drives up the cost of their
required infrastructure to handle QoS even more.
Besides, if I deploy a new protocol that uses RTP or leverages QoS, I'd
have to wait for the ISP to update their network with knowledge of that
protocol in order to handle it properly... given the glacial pace that
at which ISP's certify and deploy software updates, configuration
changes, etc. I don't want to have to wait months or years for them to
play catch-up.
What's more, if I'm running SIP over TLS over TCP, they can't peek into
the stream anyway to figure out what UDP ports I'm using for SDP.
So I can sacrifice control, privacy, or timeliness... or they can simply
trust my QoS markings.
But what's the downside of their trusting my markings, anyway?
Let's say that I have 7mb/s DSL, and with that standard base profile
comes 240kb/s EF policing, 512kb/s AF4x, etc. Further let's suppose
that I exceed my SLA: they could either downgrade the excess to the next
lowest bin, or discard it... Hence I'm highly incentivized to remain
within my agreed SLA envelope.
^ permalink raw reply
* Re: [PATCH net-2.6] net: Fix definition of netif_vdbg() when VERBOSE_DEBUG is defined
From: David Miller @ 2010-07-06 3:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers, joe
In-Reply-To: <1278090524.2095.41.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 02 Jul 2010 18:08:44 +0100
> netif_vdbg() was originally defined as entirely equivalent to
> netdev_vdbg(), but I assume that it was intended to take the same
> parameters as netif_dbg() etc. (Currently it is only used by the
> sfc driver, in which I worked on that assumption.)
>
> In commit a4ed89c I changed the definition used when VERBOSE_DEBUG is
> not defined, but I failed to notice that the definition used when
> VERBOSE_DEBUG is defined was also not as I expected. Change that to
> match netif_dbg() as well.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: David Miller @ 2010-07-06 3:13 UTC (permalink / raw)
To: philipp_subx; +Cc: hagen, alex, netdev
In-Reply-To: <4C329E15.2000601@redfish-solutions.com>
From: Philip Prindeville <philipp_subx@redfish-solutions.com>
Date: Mon, 05 Jul 2010 21:08:05 -0600
> Yes, most users have admin/privileged rights on their machines, but
> don't know enough to exploit that.
Even "stupid" users are a very slim, marginal, step away from making
use of it once they get shown with a HOWTO on some web site what is
possible with this if QoS is being abided by on their network.
Look, this discussion seems completely pointless. The behavior is
never changing, setting the TOS will always be non-privileged.
We cannot change the current behavior no matter what political or
other motivation we might have for doing so. It's been non-privileged
for more than 15 years, and we'd knowingly break applications with the
change.
And I don't even agree with the arguments being proposed for doing
this. Users can control their packets however they wish. The only
thing the ISP can do to prevent toying with the TOS bits is putting
logic into your little black box that hooks up to your cable/dsl line.
So this TOS being privileged proposal it's a "no go" from any angle as
far as I'm concerned.
^ permalink raw reply
* Re: Splice status
From: Eric Dumazet @ 2010-07-06 3:56 UTC (permalink / raw)
To: Changli Gao; +Cc: Jens Axboe, Ofer Heifetz, netdev@vger.kernel.org
In-Reply-To: <AANLkTim_eBmT-6HmkqG5d7k0jjrGKAFBjzqVCricTpgK@mail.gmail.com>
Le mardi 06 juillet 2010 à 10:01 +0800, Changli Gao a écrit :
> On Mon, Jul 5, 2010 at 8:50 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le lundi 05 juillet 2010 à 13:52 +0300, Ofer Heifetz a écrit :
> >> I am using Samba, so from my understanding of the source code, it
> > loops and performs splice(sock, pipe) and splice(pipe, fd). There is no
> > flush of any sort in between.
> >>
> >> When you say drain you mean to flush all data to pipe?
> >>
> >
> > Draining pipe before splice() call would only trigger the bug less
> > often.
>
> If we don't drain the pipe before calling splice(2), the data spliced
> from pipe maybe not be what we expect. Then data corruption occurs.
>
This is not true. A pipe is a pipe is a buffer. You dont need it to be
empty when using it. Nowhere in documentation its stated.
However, a single skb can fill a pipe, even if "its empty"
> >
> > splice(sock, pipe) can block if caller dont use appropriate "non
> > blocking pipe' splice() mode, even if pipe is empty before a splice()
> > call.
>
> I don't think it is expected. The code of sys_recvfile is much like
> the sendfile(2) implementation in kernel. If sys_recvfile may block
> without non_block flag, sendfile(2) may block too.
Then it would be a bug. You might fix it easily.
Using splice() correctly (ie, not blocking on sock->pipe) should work
too.
Again, you can block on splice(sock, pipe), iff you have a second thread
doing the opposite (pipe->file) in parallel to unblock you. But samba
recvfile algo is using a single thread.
>
> BTW: Samba can use sendfile(2) instead in sys_recvfile.
>
^ 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