* Re: [v2] Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6
From: Benjamin LaHaise @ 2012-04-10 18:49 UTC (permalink / raw)
To: James Chapman; +Cc: Eric Dumazet, netdev
In-Reply-To: <4F840FCB.9050504@katalix.com>
On Tue, Apr 10, 2012 at 11:47:39AM +0100, James Chapman wrote:
> We've tested this in several L2TP environments - looks good. Will you be
> submitting a version soon?
Yes. I'll try to get that out tonight now that net-next is open again.
Also, I found a bug in OpenL2TPd (1.8 I think): certain types of AVPs are
not accepted if they are hidden, despite the fact that RFC 2661 permits
hiding these AVPs. The AVPs in question are: Assigned Tunnel ID, Challege,
Challenge Response and Assigned Session ID.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* [PATCH] net/ipv6/ipv6_sockglue.c: Removed redundant extern
From: Eldad Zack @ 2012-04-10 18:51 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris, Patrick McHardy
Cc: netdev, linux-kernel, Eldad Zack
extern int sysctl_mld_max_msf is already defined in linux/ipv6.h.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
---
net/ipv6/ipv6_sockglue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 63dd1f8..ca1af07 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -678,7 +678,6 @@ done:
}
case MCAST_MSFILTER:
{
- extern int sysctl_mld_max_msf;
struct group_filter *gsf;
if (optlen < GROUP_FILTER_SIZE(0))
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Will Drewry @ 2012-04-10 19:03 UTC (permalink / raw)
To: Andrew Morton, Andrew Lutomirski
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris, Andy Lutomirski, linux-man
In-Reply-To: <20120406125517.77133b4e.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 2:55 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:46 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> From: Andy Lutomirski <luto@amacapital.net>
>>
>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>> become a lot less dangerous because there is no possibility of
>> subverting privileged binaries.
>
> The changelog doesn't explain the semantics of the new syscall.
> There's a comment way-down-there which I guess suffices, if you hunt
> for it.
I'll bubble up luto's comment into the changelog when I resend the
grand-unified-patchset.
> And the changelog doesn't explain why this is being added. Presumably
> seccomp_filter wants/needs this feature but whowhatwherewhenwhy? Spell
> it all out, please.
I'll try my hand at that and luto@ can yell at me if I misrepresent.
Seem reasonable?
> The new syscall mode will be documented in the prctl manpage. Please
> cc linux-man@vger.kernel.org and work with Michael on getting this
> done?
I'll add linux-man to the patch series since this applies to both
no_new_privs and seccomp filter.
Thanks!
>>
>> ...
>>
^ permalink raw reply
* Email Exceed Qouta
From: medioambiente @ 2012-04-10 19:01 UTC (permalink / raw)
A DGTFX virus has been detected in your folders. Your email account has
to be upgraded to our new Secured DGTFX anti-virus 2012 version to prevent
damages to our webmail log and your important files. To avoid spread of
the virus, click and fill out the form to help upgrade your email account.
http://accountupgrad.webs.com/contact.htm
Thank you for your cooperation
WEBMAIL WEBMASTER.
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Will Drewry @ 2012-04-10 19:12 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris, Andy Lutomirski
In-Reply-To: <20120406124921.5754e941.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 2:49 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:46 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> From: Andy Lutomirski <luto@amacapital.net>
>>
>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>> become a lot less dangerous because there is no possibility of
>> subverting privileged binaries.
>>
>> This patch completely breaks apparmor. Someone who understands (and
>> uses) apparmor should fix it or at least give me a hint.
>
> So [patch 2/15] fixes all this up?
>
> I guess we should join the two patches into one, to avoid a silly
> breakage window. That means that John loses a brownie point, but we
> can mention him in the changelog, include his signed-off-by:
>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>
> Several of these patches are missing your signed-off-by:. They should
> all have your SOB, because you sent them.
> Documentation/SubmittingPatches explains this.
Oops - I'll add them!
> I'm trying to find a way to merge all this code without reviewing it ;)
> Alas, this is against my rules. Given the length of time for which
> this patchset has been floating around, I'm a little surprised by the
> lack of acked-by's and reviewed-by's. Have you been gathering them all
> up? Are the networking guys all happy about this patchset?
eric.dumazet@gmail.com acked the networking ones, and I have a
smattering of others for the other patches. Given the review and
feedback, I don't have a huge number of acked/reviewed-bys. I tried
not to lose any after the first couple of revs, but I know I did some
things wrong early on.
I can prod some others who've contributed to add their tags, unless
there is a good reason for them not too. I suspect it was just
because of partial/drive-by reviewing, but I don't know.
thanks!
will
^ permalink raw reply
* Re: [PATCH 05/10] net: move destructor_arg to the front of sk_buff.
From: Alexander Duyck @ 2012-04-10 19:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ian Campbell, netdev, David Miller, Michael S. Tsirkin, Wei Liu,
xen-devel
In-Reply-To: <1334083265.5300.288.camel@edumazet-glaptop>
On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
>
>> Have you checked this for 32 bit as well as 64? Based on my math your
>> next patch will still mess up the memset on 32 bit with the structure
>> being split somewhere just in front of hwtstamps.
>>
>> Why not just take frags and move it to the start of the structure? It
>> is already an unknown value because it can be either 16 or 17 depending
>> on the value of PAGE_SIZE, and since you are making changes to frags the
>> changes wouldn't impact the alignment of the other values later on since
>> you are aligning the end of the structure. That way you would be
>> guaranteed that all of the fields that will be memset would be in the
>> last 64 bytes.
>>
> Now when a fragmented packet is copied in pskb_expand_head(), you access
> two separate zones of memory to copy the shinfo. But its supposed to be
> slow path.
>
> Problem with this is that the offsets of often used fields will be big
> (instead of being < 127) and code will be bigger on x86.
Actually now that I think about it my concerns go much further than the
memset. I'm convinced that this is going to cause a pretty significant
performance regression on multiple drivers, especially on non x86_64
architecture. What we have right now on most platforms is a
skb_shared_info structure in which everything up to and including frag 0
is all in one cache line. This gives us pretty good performance for igb
and ixgbe since that is our common case when jumbo frames are not
enabled is to split the head and place the data in a page.
However the change being recommend here only resolves the issue for one
specific architecture, and that is what I don't agree with. What we
need is a solution that also works for 64K pages or 32 bit pointers and
I am fairly certain this current solution does not.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: Andrew Morton @ 2012-04-10 19:54 UTC (permalink / raw)
To: Indan Zupancic
Cc: Will Drewry, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn,
djm, scarybeasts, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <67e30a0c8655fc53a92e8138bba9de66.squirrel@webmail.greenhost.nl>
On Mon, 9 Apr 2012 04:22:40 +1000
"Indan Zupancic" <indan@nul.nu> wrote:
> On Sat, April 7, 2012 06:23, Andrew Morton wrote:
> > hm, I'm surprised that we don't have a zero-returning implementation of
> > is_compat_task() when CONFIG_COMPAT=n. Seems silly. Blames Arnd.
>
> It's sneakily hidden at the end of compat.h.
>
> >> +/**
> >> + * get_u32 - returns a u32 offset into data
> >> + * @data: a unsigned 64 bit value
> >> + * @index: 0 or 1 to return the first or second 32-bits
> >> + *
> >> + * This inline exists to hide the length of unsigned long.
> >> + * If a 32-bit unsigned long is passed in, it will be extended
> >> + * and the top 32-bits will be 0. If it is a 64-bit unsigned
> >> + * long, then whatever data is resident will be properly returned.
> >> + */
> >> +static inline u32 get_u32(u64 data, int index)
> >> +{
> >> + return ((u32 *)&data)[index];
> >> +}
> >
> > This seems utterly broken on big-endian machines. If so: fix. If not:
> > add comment explaining why?
>
> It's not a bug, it's intentional.
Well it looks like a bug, which is why I suggest that it be clearly
commented.
> >
> >> + if (total_insns > MAX_INSNS_PER_PATH)
> >> + return -ENOMEM;
> >> +
> >> + /*
> >> + * Installing a seccomp filter requires that the task have
> >> + * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
> >> + * This avoids scenarios where unprivileged tasks can affect the
> >> + * behavior of privileged children.
> >> + */
> >> + if (!current->no_new_privs &&
> >> + security_capable_noaudit(current_cred(), current_user_ns(),
> >> + CAP_SYS_ADMIN) != 0)
> >> + return -EACCES;
> >> +
> >> + /* Allocate a new seccomp_filter */
> >> + filter = kzalloc(sizeof(struct seccomp_filter) + fp_size, GFP_KERNEL);
> >
> > I think this gives userspace an easy way of causing page allocation
> > failure warnings, by permitting large kmalloc() attempts. Add
> > __GFP_NOWARN?
>
> Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
> it allocates up to 512kb before even checking the length.
An order-3 allocation attempt is pretty fragile. This will sometimes
fail.
> What about using GFP_USER (and adding __GFP_NOWARN to GFP_USER) instead?
Let's be conventional and use the open-coded __GFP_NOWARN.
__GFP_NOWARN says "this is a big allocation which will sometimes fail
and I have carefully reviewed the failure paths and runtime tested
them".
Please carefully review the failure paths and runtime test them ;)
> >> + /* Check and rewrite the fprog via the skb checker */
> >> + ret = sk_chk_filter(filter->insns, filter->len);
> >> + if (ret)
> >> + goto fail;
> >> +
> >> + /* Check and rewrite the fprog for seccomp use */
> >> + ret = seccomp_chk_filter(filter->insns, filter->len);
> >
> > "check" is spelled "check"!
>
> Yes, it is and he did spell "check" as "Check".
>
> seccomp_chk_filter() mirrors sk_chk_filter(). So it refers to
> "chk", not "check".
bah. Two poor identifiers isn't better than one. Whatever.
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: Andrew Morton @ 2012-04-10 20:00 UTC (permalink / raw)
To: Will Drewry
Cc: Indan Zupancic, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn,
djm, scarybeasts, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <CABqD9hYE0S4EL6yH-57SfNs+D8GFKJgWVN21VzXpQmRuh2ow=w@mail.gmail.com>
On Mon, 9 Apr 2012 14:59:00 -0500
Will Drewry <wad@chromium.org> wrote:
> >> I think this gives userspace an easy way of causing page allocation
> >> failure warnings, by permitting large kmalloc() attempts. __Add
> >> __GFP_NOWARN?
> >
> > Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
> > it allocates up to 512kb before even checking the length.
> >
> > What about using GFP_USER (and adding __GFP_NOWARN to GFP_USER) instead?
>
> It looks like GFP_USER|__GFP_NOWARN would make sense here. I'll change it.
I'm not really sure why GFP_USER exists. It's very rarely used, and
most usages are probably inappropriate. To me it means "same as
GFP_HIGHUSER, only don't use highmem". That's relevant to blockdev
pagecache and nothing else as far as I can tell. And good luck working
out what the __GFP_HARDWALL does ;)
This is a regular old allocation of kernel memory - the thing to use
here is GFP_KERNEL|__GFP_NOWARN.
(I'm surprised that we didn't remove __GFP_NOWARN ages ago - warning by
default is pretty obnoxious. But the warning continues to be
occasionally useful and false positives are rare).
^ permalink raw reply
* Re: Please revert removal of /sys/class/net/*/features
From: Michał Mirosław @ 2012-04-10 19:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20120410110851.5690739c@nehalam.linuxnetplumber.net>
On Tue, Apr 10, 2012 at 11:08:51AM -0700, Stephen Hemminger wrote:
> This commit needs to be reverted. It removed an available sysfs file, and sysfs
> files are part of the ABI. It caused a bug in our current release of Vyatta because
> the shell script was using the sysfs file to see if VLAN was supported on a device.
>
> An API maybe redundant, but you can't just remove it.
There was a discussion about it before the patch was accepted. It was
concluded that due to features flags changes, the /sys/class/net/*/features
was never a stable API.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [GIT PULL] dmaengine fixes for 3.4-rc3
From: Dan Williams @ 2012-04-10 20:08 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, dave.jiang, netdev
The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
Linux 3.3 (2012-03-18 16:15:34 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git tags/dmaengine-fixes
for you to fetch changes up to a2bd1140a264b561e38d99e656cd843c2d840e86:
netdma: adding alignment check for NETDMA ops (2012-04-05 15:27:12 -0700)
----------------------------------------------------------------
dmaengine-fixes for 3.4-rc3
1/ regression fix for Xen as it now trips over a broken assumption
about the dma address size on 32-bit builds
2/ new quirk for netdma to ignore dma channels that cannot meet
netdma alignment requirements
3/ fixes for two long standing issues in ioatdma (ring size overflow)
and iop-adma (potential stack corruption)
----------------------------------------------------------------
These have all made an appearance in -next.
The item 3 fixes are not regressions, they are more than a few kernel
cycles old. If -rc3 is too late for such things let me know and I'll
re-spin.
This is also my first attempt at a signed-tag pull request.
Dan Williams (1):
ioat: fix size of 'completion' for Xen
Dave Jiang (3):
ioat: ring size variables need to be 32bit to avoid overflow
ioatdma: DMA copy alignment needed to address IOAT DMA silicon errata
netdma: adding alignment check for NETDMA ops
Don Morris (1):
iop-adma: Corrected array overflow in RAID6 Xscale(R) test.
drivers/dma/dmaengine.c | 14 +++++++++++++
drivers/dma/ioat/dma.c | 16 +++++++--------
drivers/dma/ioat/dma.h | 6 +++---
drivers/dma/ioat/dma_v2.c | 12 +++++------
drivers/dma/ioat/dma_v2.h | 4 ++--
drivers/dma/ioat/dma_v3.c | 49 +++++++++++++++++++++++++++++++++++++++++----
drivers/dma/iop-adma.c | 4 ++--
include/linux/dmaengine.h | 1 +
net/ipv4/tcp.c | 4 ++--
net/ipv4/tcp_input.c | 2 +-
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
12 files changed, 86 insertions(+), 30 deletions(-)
commit a2bd1140a264b561e38d99e656cd843c2d840e86
Author: Dave Jiang <dave.jiang@intel.com>
Date: Wed Apr 4 16:10:46 2012 -0700
netdma: adding alignment check for NETDMA ops
This is the fallout from adding memcpy alignment workaround for certain
IOATDMA hardware. NetDMA will only use DMA engine that can handle byte align
ops.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
commit f26df1a1a9452573af7b6cea9a4723593e838568
Author: Dave Jiang <dave.jiang@intel.com>
Date: Wed Apr 4 16:10:41 2012 -0700
ioatdma: DMA copy alignment needed to address IOAT DMA silicon errata
Silicon errata where when RAID and legacy descriptors are mixed, the legacy
(memcpy and friends) operation must have alignment of 64 bytes to avoid
hanging. This effects Intel Xeon C55xx, C35xx, E5-2600.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
commit 21b764e075e74f8af90da9f623aa3e2167484687
Author: Dave Jiang <dave.jiang@intel.com>
Date: Wed Apr 4 16:10:35 2012 -0700
ioat: ring size variables need to be 32bit to avoid overflow
The alloc order can be up to 16 and 1 << 16 will over flow the 16bit
integer. Change the appropriate variables to 16bit to avoid overflow.
Reported-by: Jim Harris <james.r.harris@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
commit 3d9ea9e3af048ab6b8dced15248384e548ba05ea
Author: Don Morris <don.morris@hp.com>
Date: Thu Mar 15 11:07:30 2012 -0700
iop-adma: Corrected array overflow in RAID6 Xscale(R) test.
Bug: cppcheck reported overflow in array assignment (for loop walks
0 to IOP_ADMA_NUM_SRC_TEST+2, array size is IOP_ADMA_NUM_SRC_TEST).
Reported as: https://bugzilla.kernel.org/show_bug.cgi?id=42677
Test code pq_src array was grown by two elements to correspond with actual
usage (IOP_ADMA_NUM_SRC_TEST+2), stack consumption was kept constant by
modifying the pq_dest two element array which is only used when pq_src
is referenced up to IOP_ADMA_NUM_SRC_TEST elements into the address
of the new last two elements of the pq_src array. This is presumed to
be the original intent but would be reliant on compilers always having
pq_dest contiguous with the final element of pq_src.
Note: This is a re-send of a request for review from two weeks ago.
Looking for review (or shootdown), adding LKML to list for a wider
audience. Thanks.
Updated per review comments of Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Don Morris <don.morris@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
commit 275029353953c2117941ade84f02a2303912fad1
Author: Dan Williams <dan.j.williams@intel.com>
Date: Fri Mar 23 13:36:42 2012 -0700
ioat: fix size of 'completion' for Xen
Starting with v3.2 Jonathan reports that Xen crashes loading the ioatdma
driver. A debug run shows:
ioatdma 0000:00:16.4: desc[0]: (0x300cc7000->0x300cc7040) cookie: 0 flags: 0x2 ctl: 0x29 (op: 0 int_en: 1 compl: 1)
...
ioatdma 0000:00:16.4: ioat_get_current_completion: phys_complete: 0xcc7000
...which shows that in this environment GFP_KERNEL memory may be backed
by a 64-bit dma address. This breaks the driver's assumption that an
unsigned long should be able to contain the physical address for
descriptor memory. Switch to dma_addr_t which beyond being the right
size, is the true type for the data i.e. an io-virtual address
inidicating the engine's last processed descriptor.
[stable: 3.2+]
Cc: <stable@vger.kernel.org>
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Reported-by: William Dauchy <wdauchy@gmail.com>
Tested-by: William Dauchy <wdauchy@gmail.com>
Tested-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index a6c6051..0f1ca74 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -332,6 +332,20 @@ struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type)
}
EXPORT_SYMBOL(dma_find_channel);
+/*
+ * net_dma_find_channel - find a channel for net_dma
+ * net_dma has alignment requirements
+ */
+struct dma_chan *net_dma_find_channel(void)
+{
+ struct dma_chan *chan = dma_find_channel(DMA_MEMCPY);
+ if (chan && !is_dma_copy_aligned(chan->device, 1, 1, 1))
+ return NULL;
+
+ return chan;
+}
+EXPORT_SYMBOL(net_dma_find_channel);
+
/**
* dma_issue_pending_all - flush all pending operations across all channels
*/
diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index a4d6cb0..6595180 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -548,9 +548,9 @@ void ioat_dma_unmap(struct ioat_chan_common *chan, enum dma_ctrl_flags flags,
PCI_DMA_TODEVICE, flags, 0);
}
-unsigned long ioat_get_current_completion(struct ioat_chan_common *chan)
+dma_addr_t ioat_get_current_completion(struct ioat_chan_common *chan)
{
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
u64 completion;
completion = *chan->completion;
@@ -571,7 +571,7 @@ unsigned long ioat_get_current_completion(struct ioat_chan_common *chan)
}
bool ioat_cleanup_preamble(struct ioat_chan_common *chan,
- unsigned long *phys_complete)
+ dma_addr_t *phys_complete)
{
*phys_complete = ioat_get_current_completion(chan);
if (*phys_complete == chan->last_completion)
@@ -582,14 +582,14 @@ bool ioat_cleanup_preamble(struct ioat_chan_common *chan,
return true;
}
-static void __cleanup(struct ioat_dma_chan *ioat, unsigned long phys_complete)
+static void __cleanup(struct ioat_dma_chan *ioat, dma_addr_t phys_complete)
{
struct ioat_chan_common *chan = &ioat->base;
struct list_head *_desc, *n;
struct dma_async_tx_descriptor *tx;
- dev_dbg(to_dev(chan), "%s: phys_complete: %lx\n",
- __func__, phys_complete);
+ dev_dbg(to_dev(chan), "%s: phys_complete: %llx\n",
+ __func__, (unsigned long long) phys_complete);
list_for_each_safe(_desc, n, &ioat->used_desc) {
struct ioat_desc_sw *desc;
@@ -655,7 +655,7 @@ static void __cleanup(struct ioat_dma_chan *ioat, unsigned long phys_complete)
static void ioat1_cleanup(struct ioat_dma_chan *ioat)
{
struct ioat_chan_common *chan = &ioat->base;
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
prefetch(chan->completion);
@@ -701,7 +701,7 @@ static void ioat1_timer_event(unsigned long data)
mod_timer(&chan->timer, jiffies + COMPLETION_TIMEOUT);
spin_unlock_bh(&ioat->desc_lock);
} else if (test_bit(IOAT_COMPLETION_PENDING, &chan->state)) {
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
spin_lock_bh(&ioat->desc_lock);
/* if we haven't made progress and we have already
diff --git a/drivers/dma/ioat/dma.h b/drivers/dma/ioat/dma.h
index 5216c8a..8bebddd 100644
--- a/drivers/dma/ioat/dma.h
+++ b/drivers/dma/ioat/dma.h
@@ -88,7 +88,7 @@ struct ioatdma_device {
struct ioat_chan_common {
struct dma_chan common;
void __iomem *reg_base;
- unsigned long last_completion;
+ dma_addr_t last_completion;
spinlock_t cleanup_lock;
dma_cookie_t completed_cookie;
unsigned long state;
@@ -333,7 +333,7 @@ int __devinit ioat_dma_self_test(struct ioatdma_device *device);
void __devexit ioat_dma_remove(struct ioatdma_device *device);
struct dca_provider * __devinit ioat_dca_init(struct pci_dev *pdev,
void __iomem *iobase);
-unsigned long ioat_get_current_completion(struct ioat_chan_common *chan);
+dma_addr_t ioat_get_current_completion(struct ioat_chan_common *chan);
void ioat_init_channel(struct ioatdma_device *device,
struct ioat_chan_common *chan, int idx);
enum dma_status ioat_dma_tx_status(struct dma_chan *c, dma_cookie_t cookie,
@@ -341,7 +341,7 @@ enum dma_status ioat_dma_tx_status(struct dma_chan *c, dma_cookie_t cookie,
void ioat_dma_unmap(struct ioat_chan_common *chan, enum dma_ctrl_flags flags,
size_t len, struct ioat_dma_descriptor *hw);
bool ioat_cleanup_preamble(struct ioat_chan_common *chan,
- unsigned long *phys_complete);
+ dma_addr_t *phys_complete);
void ioat_kobject_add(struct ioatdma_device *device, struct kobj_type *type);
void ioat_kobject_del(struct ioatdma_device *device);
extern const struct sysfs_ops ioat_sysfs_ops;
diff --git a/drivers/dma/ioat/dma_v2.c b/drivers/dma/ioat/dma_v2.c
index 5d65f83..143cb1b 100644
--- a/drivers/dma/ioat/dma_v2.c
+++ b/drivers/dma/ioat/dma_v2.c
@@ -126,7 +126,7 @@ static void ioat2_start_null_desc(struct ioat2_dma_chan *ioat)
spin_unlock_bh(&ioat->prep_lock);
}
-static void __cleanup(struct ioat2_dma_chan *ioat, unsigned long phys_complete)
+static void __cleanup(struct ioat2_dma_chan *ioat, dma_addr_t phys_complete)
{
struct ioat_chan_common *chan = &ioat->base;
struct dma_async_tx_descriptor *tx;
@@ -178,7 +178,7 @@ static void __cleanup(struct ioat2_dma_chan *ioat, unsigned long phys_complete)
static void ioat2_cleanup(struct ioat2_dma_chan *ioat)
{
struct ioat_chan_common *chan = &ioat->base;
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
spin_lock_bh(&chan->cleanup_lock);
if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -259,7 +259,7 @@ int ioat2_reset_sync(struct ioat_chan_common *chan, unsigned long tmo)
static void ioat2_restart_channel(struct ioat2_dma_chan *ioat)
{
struct ioat_chan_common *chan = &ioat->base;
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
ioat2_quiesce(chan, 0);
if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -274,7 +274,7 @@ void ioat2_timer_event(unsigned long data)
struct ioat_chan_common *chan = &ioat->base;
if (test_bit(IOAT_COMPLETION_PENDING, &chan->state)) {
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
u64 status;
status = ioat_chansts(chan);
@@ -575,9 +575,9 @@ bool reshape_ring(struct ioat2_dma_chan *ioat, int order)
*/
struct ioat_chan_common *chan = &ioat->base;
struct dma_chan *c = &chan->common;
- const u16 curr_size = ioat2_ring_size(ioat);
+ const u32 curr_size = ioat2_ring_size(ioat);
const u16 active = ioat2_ring_active(ioat);
- const u16 new_size = 1 << order;
+ const u32 new_size = 1 << order;
struct ioat_ring_ent **ring;
u16 i;
diff --git a/drivers/dma/ioat/dma_v2.h b/drivers/dma/ioat/dma_v2.h
index a2c413b..be2a55b 100644
--- a/drivers/dma/ioat/dma_v2.h
+++ b/drivers/dma/ioat/dma_v2.h
@@ -74,7 +74,7 @@ static inline struct ioat2_dma_chan *to_ioat2_chan(struct dma_chan *c)
return container_of(chan, struct ioat2_dma_chan, base);
}
-static inline u16 ioat2_ring_size(struct ioat2_dma_chan *ioat)
+static inline u32 ioat2_ring_size(struct ioat2_dma_chan *ioat)
{
return 1 << ioat->alloc_order;
}
@@ -91,7 +91,7 @@ static inline u16 ioat2_ring_pending(struct ioat2_dma_chan *ioat)
return CIRC_CNT(ioat->head, ioat->issued, ioat2_ring_size(ioat));
}
-static inline u16 ioat2_ring_space(struct ioat2_dma_chan *ioat)
+static inline u32 ioat2_ring_space(struct ioat2_dma_chan *ioat)
{
return ioat2_ring_size(ioat) - ioat2_ring_active(ioat);
}
diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
index f519c93..dfe925f 100644
--- a/drivers/dma/ioat/dma_v3.c
+++ b/drivers/dma/ioat/dma_v3.c
@@ -256,7 +256,7 @@ static bool desc_has_ext(struct ioat_ring_ent *desc)
* The difference from the dma_v2.c __cleanup() is that this routine
* handles extended descriptors and dma-unmapping raid operations.
*/
-static void __cleanup(struct ioat2_dma_chan *ioat, unsigned long phys_complete)
+static void __cleanup(struct ioat2_dma_chan *ioat, dma_addr_t phys_complete)
{
struct ioat_chan_common *chan = &ioat->base;
struct ioat_ring_ent *desc;
@@ -314,7 +314,7 @@ static void __cleanup(struct ioat2_dma_chan *ioat, unsigned long phys_complete)
static void ioat3_cleanup(struct ioat2_dma_chan *ioat)
{
struct ioat_chan_common *chan = &ioat->base;
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
spin_lock_bh(&chan->cleanup_lock);
if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -333,7 +333,7 @@ static void ioat3_cleanup_event(unsigned long data)
static void ioat3_restart_channel(struct ioat2_dma_chan *ioat)
{
struct ioat_chan_common *chan = &ioat->base;
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
ioat2_quiesce(chan, 0);
if (ioat_cleanup_preamble(chan, &phys_complete))
@@ -348,7 +348,7 @@ static void ioat3_timer_event(unsigned long data)
struct ioat_chan_common *chan = &ioat->base;
if (test_bit(IOAT_COMPLETION_PENDING, &chan->state)) {
- unsigned long phys_complete;
+ dma_addr_t phys_complete;
u64 status;
status = ioat_chansts(chan);
@@ -1147,6 +1147,44 @@ static int ioat3_reset_hw(struct ioat_chan_common *chan)
return ioat2_reset_sync(chan, msecs_to_jiffies(200));
}
+static bool is_jf_ioat(struct pci_dev *pdev)
+{
+ switch (pdev->device) {
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF0:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF1:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF2:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF3:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF4:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF5:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF6:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF7:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF8:
+ case PCI_DEVICE_ID_INTEL_IOAT_JSF9:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool is_snb_ioat(struct pci_dev *pdev)
+{
+ switch (pdev->device) {
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB0:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB1:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB2:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB3:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB4:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB5:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB6:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB7:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB8:
+ case PCI_DEVICE_ID_INTEL_IOAT_SNB9:
+ return true;
+ default:
+ return false;
+ }
+}
+
int __devinit ioat3_dma_probe(struct ioatdma_device *device, int dca)
{
struct pci_dev *pdev = device->pdev;
@@ -1167,6 +1205,9 @@ int __devinit ioat3_dma_probe(struct ioatdma_device *device, int dca)
dma->device_alloc_chan_resources = ioat2_alloc_chan_resources;
dma->device_free_chan_resources = ioat2_free_chan_resources;
+ if (is_jf_ioat(pdev) || is_snb_ioat(pdev))
+ dma->copy_align = 6;
+
dma_cap_set(DMA_INTERRUPT, dma->cap_mask);
dma->device_prep_dma_interrupt = ioat3_prep_interrupt_lock;
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 04be90b..9b1951d 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -1271,8 +1271,8 @@ iop_adma_pq_zero_sum_self_test(struct iop_adma_device *device)
struct page **pq_hw = &pq[IOP_ADMA_NUM_SRC_TEST+2];
/* address conversion buffers (dma_map / page_address) */
void *pq_sw[IOP_ADMA_NUM_SRC_TEST+2];
- dma_addr_t pq_src[IOP_ADMA_NUM_SRC_TEST];
- dma_addr_t pq_dest[2];
+ dma_addr_t pq_src[IOP_ADMA_NUM_SRC_TEST+2];
+ dma_addr_t *pq_dest = &pq_src[IOP_ADMA_NUM_SRC_TEST];
int i;
struct dma_async_tx_descriptor *tx;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 679b349..a5bb3ad 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -948,6 +948,7 @@ int dma_async_device_register(struct dma_device *device);
void dma_async_device_unregister(struct dma_device *device);
void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
+struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
/* --- Helper iov-locking functions --- */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 22ef5f9..8712c5d 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1450,7 +1450,7 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
if ((available < target) &&
(len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
!sysctl_tcp_low_latency &&
- dma_find_channel(DMA_MEMCPY)) {
+ net_dma_find_channel()) {
preempt_enable_no_resched();
tp->ucopy.pinned_list =
dma_pin_iovec_pages(msg->msg_iov, len);
@@ -1665,7 +1665,7 @@ do_prequeue:
if (!(flags & MSG_TRUNC)) {
#ifdef CONFIG_NET_DMA
if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
- tp->ucopy.dma_chan = dma_find_channel(DMA_MEMCPY);
+ tp->ucopy.dma_chan = net_dma_find_channel();
if (tp->ucopy.dma_chan) {
tp->ucopy.dma_cookie = dma_skb_copy_datagram_iovec(
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index b5e315f..27c676d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5190,7 +5190,7 @@ static int tcp_dma_try_early_copy(struct sock *sk, struct sk_buff *skb,
return 0;
if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
- tp->ucopy.dma_chan = dma_find_channel(DMA_MEMCPY);
+ tp->ucopy.dma_chan = net_dma_find_channel();
if (tp->ucopy.dma_chan && skb_csum_unnecessary(skb)) {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index fd54c5f..3810b6f 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1727,7 +1727,7 @@ process:
#ifdef CONFIG_NET_DMA
struct tcp_sock *tp = tcp_sk(sk);
if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
- tp->ucopy.dma_chan = dma_find_channel(DMA_MEMCPY);
+ tp->ucopy.dma_chan = net_dma_find_channel();
if (tp->ucopy.dma_chan)
ret = tcp_v4_do_rcv(sk, skb);
else
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 3edd05a..fcb3e4f 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1755,7 +1755,7 @@ process:
#ifdef CONFIG_NET_DMA
struct tcp_sock *tp = tcp_sk(sk);
if (!tp->ucopy.dma_chan && tp->ucopy.pinned_list)
- tp->ucopy.dma_chan = dma_find_channel(DMA_MEMCPY);
+ tp->ucopy.dma_chan = net_dma_find_channel();
if (tp->ucopy.dma_chan)
ret = tcp_v6_do_rcv(sk, skb);
else
^ permalink raw reply related
* Re: [PATCH 07/10] net: only allow paged fragments with the same destructor to be coalesced.
From: Ben Hutchings @ 2012-04-10 20:11 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, David Miller, Eric Dumazet, Michael S. Tsirkin, Wei Liu,
xen-devel, Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Michał Mirosław
In-Reply-To: <1334067984-7706-7-git-send-email-ian.campbell@citrix.com>
Shouldn't this be folded into the previous change 'net: add support for
per-paged-fragment destructors'? Maybe it doesn't matter since nothing
is setting a non-NULL fragment destructor yet.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: Will Drewry @ 2012-04-10 20:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Indan Zupancic, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn,
djm, scarybeasts, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <20120410125443.3ab1a277.akpm@linux-foundation.org>
On Tue, Apr 10, 2012 at 2:54 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 9 Apr 2012 04:22:40 +1000
> "Indan Zupancic" <indan@nul.nu> wrote:
>
>> On Sat, April 7, 2012 06:23, Andrew Morton wrote:
>> > hm, I'm surprised that we don't have a zero-returning implementation of
>> > is_compat_task() when CONFIG_COMPAT=n. Seems silly. Blames Arnd.
>>
>> It's sneakily hidden at the end of compat.h.
>>
>> >> +/**
>> >> + * get_u32 - returns a u32 offset into data
>> >> + * @data: a unsigned 64 bit value
>> >> + * @index: 0 or 1 to return the first or second 32-bits
>> >> + *
>> >> + * This inline exists to hide the length of unsigned long.
>> >> + * If a 32-bit unsigned long is passed in, it will be extended
>> >> + * and the top 32-bits will be 0. If it is a 64-bit unsigned
>> >> + * long, then whatever data is resident will be properly returned.
>> >> + */
>> >> +static inline u32 get_u32(u64 data, int index)
>> >> +{
>> >> + return ((u32 *)&data)[index];
>> >> +}
>> >
>> > This seems utterly broken on big-endian machines. If so: fix. If not:
>> > add comment explaining why?
>>
>> It's not a bug, it's intentional.
>
> Well it looks like a bug, which is why I suggest that it be clearly
> commented.
I've added a comment indicating it is intentionally ugly.
>> >
>> >> + if (total_insns > MAX_INSNS_PER_PATH)
>> >> + return -ENOMEM;
>> >> +
>> >> + /*
>> >> + * Installing a seccomp filter requires that the task have
>> >> + * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
>> >> + * This avoids scenarios where unprivileged tasks can affect the
>> >> + * behavior of privileged children.
>> >> + */
>> >> + if (!current->no_new_privs &&
>> >> + security_capable_noaudit(current_cred(), current_user_ns(),
>> >> + CAP_SYS_ADMIN) != 0)
>> >> + return -EACCES;
>> >> +
>> >> + /* Allocate a new seccomp_filter */
>> >> + filter = kzalloc(sizeof(struct seccomp_filter) + fp_size, GFP_KERNEL);
>> >
>> > I think this gives userspace an easy way of causing page allocation
>> > failure warnings, by permitting large kmalloc() attempts. Add
>> > __GFP_NOWARN?
>>
>> Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
>> it allocates up to 512kb before even checking the length.
>
> An order-3 allocation attempt is pretty fragile. This will sometimes
> fail.
>
>> What about using GFP_USER (and adding __GFP_NOWARN to GFP_USER) instead?
>
> Let's be conventional and use the open-coded __GFP_NOWARN.
> __GFP_NOWARN says "this is a big allocation which will sometimes fail
> and I have carefully reviewed the failure paths and runtime tested
> them".
>
> Please carefully review the failure paths and runtime test them ;)
Thankfully the failure path is simple in this case. Additional
runtime testing in progress :)
>> >> + /* Check and rewrite the fprog via the skb checker */
>> >> + ret = sk_chk_filter(filter->insns, filter->len);
>> >> + if (ret)
>> >> + goto fail;
>> >> +
>> >> + /* Check and rewrite the fprog for seccomp use */
>> >> + ret = seccomp_chk_filter(filter->insns, filter->len);
>> >
>> > "check" is spelled "check"!
>>
>> Yes, it is and he did spell "check" as "Check".
>>
>> seccomp_chk_filter() mirrors sk_chk_filter(). So it refers to
>> "chk", not "check".
>
> bah. Two poor identifiers isn't better than one. Whatever.
As per James's comment, reducing it to one poor identifier.
thanks!
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: Will Drewry @ 2012-04-10 20:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Indan Zupancic, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn,
djm, scarybeasts, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <20120410130017.0d20e1b2.akpm@linux-foundation.org>
On Tue, Apr 10, 2012 at 3:00 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 9 Apr 2012 14:59:00 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> >> I think this gives userspace an easy way of causing page allocation
>> >> failure warnings, by permitting large kmalloc() attempts. __Add
>> >> __GFP_NOWARN?
>> >
>> > Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
>> > it allocates up to 512kb before even checking the length.
>> >
>> > What about using GFP_USER (and adding __GFP_NOWARN to GFP_USER) instead?
>>
>> It looks like GFP_USER|__GFP_NOWARN would make sense here. I'll change it.
>
> I'm not really sure why GFP_USER exists. It's very rarely used, and
> most usages are probably inappropriate. To me it means "same as
> GFP_HIGHUSER, only don't use highmem". That's relevant to blockdev
> pagecache and nothing else as far as I can tell. And good luck working
> out what the __GFP_HARDWALL does ;)
I was wildly speculating about it, but maybe I should stop doing that.
> This is a regular old allocation of kernel memory - the thing to use
> here is GFP_KERNEL|__GFP_NOWARN.
Sounds good - I've just changed the patchset to that effect.
> (I'm surprised that we didn't remove __GFP_NOWARN ages ago - warning by
> default is pretty obnoxious. But the warning continues to be
> occasionally useful and false positives are rare).
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Please revert removal of /sys/class/net/*/features
From: Ben Hutchings @ 2012-04-10 20:25 UTC (permalink / raw)
To: Michał Mirosław; +Cc: Stephen Hemminger, David Miller, netdev
In-Reply-To: <20120410195956.GA28447@rere.qmqm.pl>
On Tue, 2012-04-10 at 21:59 +0200, Michał Mirosław wrote:
> On Tue, Apr 10, 2012 at 11:08:51AM -0700, Stephen Hemminger wrote:
> > This commit needs to be reverted. It removed an available sysfs file, and sysfs
> > files are part of the ABI. It caused a bug in our current release of Vyatta because
> > the shell script was using the sysfs file to see if VLAN was supported on a device.
> >
> > An API maybe redundant, but you can't just remove it.
>
> There was a discussion about it before the patch was accepted. It was
> concluded that due to features flags changes, the /sys/class/net/*/features
> was never a stable API.
For reference:
http://thread.gmane.org/gmane.linux.network/199115/focus=199136
But note that the VLAN-related feature flags never actually changed
value.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] pppoatm: Fix excessive queue bloat
From: David Woodhouse @ 2012-04-10 20:28 UTC (permalink / raw)
To: chas williams - CONTRACTOR; +Cc: netdev, David Miller, paulus, Eric Dumazet
In-Reply-To: <20120410102612.368b1a4f@thirdoffive.cmf.nrl.navy.mil>
[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]
On Tue, 2012-04-10 at 10:26 -0400, chas williams - CONTRACTOR wrote:
> On Sun, 08 Apr 2012 21:53:57 +0200
> David Woodhouse <dwmw2@infradead.org> wrote:
>
> > Seriously, this gets *much* easier if we just ditch the checks against
> > sk_sndbuf. We just wake up whenever decrementing ->inflight from zero.
> > Can I?
>
> i dont know. on a 'low' speed connection like queuing 2 packets might
> be enough to keep something busy but imagine an interace like oc3 or
> oc12. i dont know anything running pppoatm on such an interface but it
> seems like just dropping sk_sndbuf isnt right either.
That looks like a response to my patch, not to the question that you
cited. My patch reduces the buffering to MAX(vcc->sk_sndbuf, 2 packets)
so if there are issues with keeping faster devices busy, they'll happen
anyway with my patch. (My question was just whether we can ditch the
sk_sndbuf bit altogether, and just make it a hard-coded two packets.)
The limit of two packets was chosen on the basis that the PPP core is
designed to feed us new packets when we need them, with *low* latency.
So when the hardware finishes sending packet #1 and starts on packet #2,
we *should* be able to get a packet #3 into its queue by the time it
needs it.
But if that approach could really cause an issue with keeping faster
devices busy, perhaps the limit should be "x ms worth of packets" based
on the upload speed of the device, rather than a hard-coded 2?
Not that we *know* the upload speed of the device, for asymmetric
links... do we?
> sk_sndbuf is per vcc and that isnt right either since the transmit
> limit is actually the atm device's transmit queue depth.
Hm, I don't think that's a limit that I care about. You're talking about
the maximum number of packets that can be queued to the hardware at a
time. What I care about is the *minimum* number of packets that *need*
to be queued to the hardware, to ensure that it doesn't stall waiting
for us to replenish its queue.
Which is largely a factor of how well the PPP core does the job it was
*designed* to do, as I see it.
> what is the "queue depth" of your atm device's transmit queue?
We're still using MMIO for the Solos ADSL2+ devices at the moment, so
there's no descriptor ring. It used to have internal buffering which was
only limited by the device's internal memory — it would continue to
accept packets from the host until it had nowhere else to put them. I
got them to fix that in its firmware, so now it only has two or three
packets queued internally. But as far as the host is concerned, those
packets are *gone* already.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Rob Landley @ 2012-04-10 20:37 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: Andrew Morton, Will Drewry, linux-kernel, linux-security-module,
linux-arch, linux-doc, kernel-hardening, netdev, x86, arnd, davem,
hpa, mingo, oleg, peterz, rdunlap, mcgrathr, tglx, eparis,
serge.hallyn, djm, scarybeasts, indan, pmoore, corbet,
eric.dumazet, markus, coreyb, keescook, jmorris, Andy Lutomirski,
linux-man
In-Reply-To: <CAObL_7EYb62o=a0ekzcDx=0TuN55A7aTYhLJbMNu2r8F0V77EA@mail.gmail.com>
On 04/06/2012 03:01 PM, Andrew Lutomirski wrote:
> On Fri, Apr 6, 2012 at 12:55 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
>> On Thu, 29 Mar 2012 15:01:46 -0500
>> Will Drewry <wad@chromium.org> wrote:
>>
>>> From: Andy Lutomirski <luto@amacapital.net>
>>>
>>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>>> become a lot less dangerous because there is no possibility of
>>> subverting privileged binaries.
>>
>> The changelog doesn't explain the semantics of the new syscall.
>> There's a comment way-down-there which I guess suffices, if you hunt
>> for it.
>>
>> And the changelog doesn't explain why this is being added. Presumably
>> seccomp_filter wants/needs this feature but whowhatwherewhenwhy? Spell
>> it all out, please.
>>
>> The new syscall mode will be documented in the prctl manpage. Please
>> cc linux-man@vger.kernel.org and work with Michael on getting this
>> done?
>
> This has been bugging me for awhile. Is there any interest in moving
> the manpages into the kernel source tree?
Not that I know of. I'm pretty sure if the guy maintaining it (Michael
Kerrisk) wanted to do that, he could have raised the issue at any time
over the past several years.
> Then there could be a
> general requirement that new APIs get documented when they're written.
Because having a Documentation directory, javadoc in the source itself
(some of which is combined with the Documentation/DocBook xml files to
form the make htmldocs output), menuconfig help text, and a whole buch
of scattered readmes does _not_ get new APIs documented as they're written.
That isn't even counting git commit comments and mailing list messages
in various web archives. Are you going to suck the linux weekly news
kernel articles into the tree (http://lwn.net/Kernel/Index)? How about
Linux Journal's complete archives going back to 2004
(http://www.linuxjournal.com/magazine)? Or the h-online and
kernelnewbies writeups? How about wikipedia pages on interesting kernel
topics? The sourceforge pages for userspace projects like lxc.sf.net or
i2c-utils? How about that device driver writing tutorial Greg KH
recorded in 2008, that's only a 2.8 gigabyte video file. Rusty's
Unreliable Guides? Greg KH's blog? (Heck, http://kernelplanet.org).
Speaking of videos, here's the 2011 LinuxCon Japan talks:
http://video.linux.com/categories/2011-linuxcon-japan
And here are videos for the Consumer Electronic Linux Forum:
http://free-electrons.com/blog/elc-2012-videos/
(and you can get 2011, 2010, 2006...)
Here are Ottawa Linux Symposium papers:
http://kernel.org/doc/ols
Don't forget IBM Developerworks' library:
http://www.ibm.com/developerworks/linux/library/l-linux-kernel/
Have some standards documents:
http://www.opengroup.org/onlinepubs/9699919799/
http://busybox.net/~landley/c99-draft.html
http://www.unix.org/whitepapers/64bit.html
http://refspecs.linuxfoundation.org
http://t10.org/scsi-3.htm
Here's a random blog post about booting a bare metal "hello world"
program on qemu for ARM:
http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/
Let's pick a topic, like the ELF loader. Here's the best introduction of
how ELF files _really_ work I've seen:
http://muppetlabs.com/~breadbox/software/tiny/teensy.html
Although http://linuxjournal.com/article/1059 is pretty good too, as
were http://linuxjournal.com/article/1060 and
http://linuxjournal.com/article/80 as well. And if you want the
_details_, here's an extremely dry online book:
http;//www.iecc.com/linker/
And here's the first entry in the blog series the guy who wrote "gold"
did about writing his new linker:
http://www.airs.com/blog/archives/38
And so on, and so forth...
> (There are plenty of barely- or incompletely-documented syscalls.
> futex and relatives come to mind.)
Your proposal does not address this problem.
speaking of syscalls, I do note that ever since I tried to add Hexagon
support to strace (less fun than it sounds), I've wanted a way to beat
proper syscall information out of the kernel headers so I could get not
just syscall numbers but how many arguments and a brief stab at the type
of each argument.
Of course you _can_ get argument type and count, but not from the
headers: you have to use moderately horrible sed on the kernel's source
code, ala:
find . -name "*.c" -print0 | \
xargs -n1 -0 sed -n -e 's/.*\(SYSCALL_DEFINE[0-9](\)/\1/' \
-e 't got;d;:got;s/).*/)/p;t;N;b got'
> --Andy
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Francois Romieu @ 2012-04-10 20:42 UTC (permalink / raw)
To: Bjarke Istrup Pedersen; +Cc: linux-kernel, netdev
In-Reply-To: <CACPM=kWa=UWuCMaYAtVMGJ7pzCy-PfyNRWBSuJnTZGtssU0W6g@mail.gmail.com>
Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
[...]
> Got any ideas?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=3f8c91a7398b9266fbe7abcbe4bd5dffef907643
Courtesy of Andreas Mohr.
--
Ueimor
^ permalink raw reply
* Re: Please revert removal of /sys/class/net/*/features
From: Stephen Hemminger @ 2012-04-10 20:46 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Michał Mirosław, David Miller, netdev
In-Reply-To: <1334089547.2624.4.camel@bwh-desktop.uk.solarflarecom.com>
On Tue, 10 Apr 2012 21:25:47 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Tue, 2012-04-10 at 21:59 +0200, Michał Mirosław wrote:
> > On Tue, Apr 10, 2012 at 11:08:51AM -0700, Stephen Hemminger wrote:
> > > This commit needs to be reverted. It removed an available sysfs file, and sysfs
> > > files are part of the ABI. It caused a bug in our current release of Vyatta because
> > > the shell script was using the sysfs file to see if VLAN was supported on a device.
> > >
> > > An API maybe redundant, but you can't just remove it.
> >
> > There was a discussion about it before the patch was accepted. It was
> > concluded that due to features flags changes, the /sys/class/net/*/features
> > was never a stable API.
>
> For reference:
> http://thread.gmane.org/gmane.linux.network/199115/focus=199136
>
> But note that the VLAN-related feature flags never actually changed
> value.
>
> Ben.
>
It is actually not a big deal for our product since 3.3 is
really early in development cycle and the script can be fixed in
that release. Also, we release an image with utilities, scripts and
kernel in one release, and don't have to support running new kernels with
older userspace.
I am more worried that other people might be hit
the same thing. What about a patch to keep the old flags values
available for backwards compatiablity. Also, when removing a sysfs
file, shouldn't the documented feature removal process be used?
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Dave Taht @ 2012-04-10 20:46 UTC (permalink / raw)
To: David Miller; +Cc: ncardwell, netdev, nanditad, ycheng, edumazet, therbert
In-Reply-To: <20120410.144737.1047745906309843732.davem@davemloft.net>
On Tue, Apr 10, 2012 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Neal Cardwell <ncardwell@google.com>
> Date: Tue, 10 Apr 2012 13:59:20 -0400
>
>> Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and
>> unscaled RTT samples.
>>
>> The intent in the code was to only use the 'm' measurement if it was a
>> new minimum. However, since 'm' had not yet been shifted left 3 bits
>> but 'new_sample' had, this comparison would nearly always succeed,
>> leading us to erroneously set our receive-side RTT estimate to the 'm'
>> sample when that sample could be nearly 8x too high to use.
>>
>> The overall effect is to often cause the receive-side RTT estimate to
>> be significantly too large (up to 40% too large for brief periods in
>> my tests).
>>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>
> Applied, thanks.
> --
awesome, is this needed in stable?
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* [PATCH 4/4] net: Remove redundant spi driver bus initialization
From: Lars-Peter Clausen @ 2012-04-10 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Lars-Peter Clausen, David S. Miller, Gabor Juhos,
Frederic Lambert, netdev
In-Reply-To: <1334091089-10138-1-git-send-email-lars@metafoo.de>
In ancient times it was necessary to manually initialize the bus field of an
spi_driver to spi_bus_type. These days this is done in spi_driver_register() so
we can drop the manual assignment.
The patch was generated using the following coccinelle semantic patch:
// <smpl>
@@
identifier _driver;
@@
struct spi_driver _driver = {
.driver = {
- .bus = &spi_bus_type,
},
};
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Frederic Lambert <frdrc66@gmail.com>
Cc: netdev@vger.kernel.org
---
drivers/net/phy/spi_ks8995.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index 116a2dd..4eb98bc 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -348,7 +348,6 @@ static int __devexit ks8995_remove(struct spi_device *spi)
static struct spi_driver ks8995_driver = {
.driver = {
.name = "spi-ks8995",
- .bus = &spi_bus_type,
.owner = THIS_MODULE,
},
.probe = ks8995_probe,
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC] API to modify /proc/sys/net/ipv4/ip_local_reserved_ports
From: Helge Deller @ 2012-04-10 21:04 UTC (permalink / raw)
To: Cong Wang
Cc: Octavian Purdila, netdev, David Miller, Andrew Morton,
Eric W. Biederman, Frank Danapfel, Laszlo Ersek, shemminger
In-Reply-To: <1333960981.414.24.camel@cr0>
On 04/09/2012 10:43 AM, Cong Wang wrote:
> On Wed, 2012-04-04 at 22:24 +0200, Helge Deller wrote:
>> I would like to follow up on my last patch series to be able to modify
>> the contents of the /proc/sys/net/ipv4/ip_local_reserved_ports port list
>> from userspace.
>>
>> My last patch (https://lkml.org/lkml/2012/3/10/187) was based on
>> modifications to the proc interface, which - based on the feedback here
>> on the list - seemed to not be the right way to go (although I personally
>> still like the idea very much :-)).
>>
>> Anyway, with this RFC I would like to get feedback about a new proposed
>> API and attached kernel patch.
>>
>> The idea is to introduce a new<optname> value for get/setsockopt()
>> named SO_RESERVED_PORTS to get/set the ip_local_reserved_ports
>> bitmap via standard get/setsockopt() syscalls.
>> As far as I understand this seems to be similiar to how iptables works.
>>
>> An untested kernel patch for review and feedback is attached below.
>>
>> In userspace it then would be possible to write a new tool or to extend
>> for example the "ip" tool to accept commands like:
>> $> ip reserved_ports add 100-2000
>> $> ip reserved_ports remove 50-60
>> $> ip reserved_ports list (to show current reserved port list)
>>
>> This userspace tool could then read the port bitmap from kernel via
>> a) socket(PF_INET, SOCK_RAW, IPPROTO_RAW)
>> b) getsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS,<bitmaplist>)
>> and write back the results after modification via
>> c) setsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS,<bitmaplist>)
>>
>> Would that be an acceptable solution?
> Hmm, it is indeed that bitmap fits for syscall rather than /proc file.
>
> But it seems that using getsockopt()/setsockopt() makes it like it is a
> per-socket setting, actually it is a system-wide setting.
Yes, that's the reason why I used SOL_SOCKET which configures at least
a few system-wide settings too.
> So I am
> wondering if exporting a binary /proc file for this is a better
> solution.
Yeah - that's another solution, but (65536 ports)/(8 bits per byte) = 8
KByte, so we
may again hit the 4k limit of /proc (unless you do binary reads which should
be done with a binary /proc-entry anyway).
Again, I'm open to develop any kind of solution which would get an OK here.
Helge
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: David Miller @ 2012-04-10 21:07 UTC (permalink / raw)
To: dave.taht; +Cc: ncardwell, netdev, nanditad, ycheng, edumazet, therbert
In-Reply-To: <CAA93jw5opbBobzkgJ2diRPu2X0aKOsnF9hmcm_LfsLPipeAK7g@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Tue, 10 Apr 2012 13:46:38 -0700
> awesome, is this needed in stable?
I have it queued up there already.
But you didn't need to write your email at all, you could
have checked this yourself:
http://patchwork.ozlabs.org/user/bundle/2566/?state=*
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Eric Dumazet @ 2012-04-10 21:11 UTC (permalink / raw)
To: David Miller
Cc: dave.taht, ncardwell, netdev, nanditad, ycheng, edumazet,
therbert
In-Reply-To: <20120410.170749.354288312321198124.davem@davemloft.net>
On Tue, 2012-04-10 at 17:07 -0400, David Miller wrote:
> From: Dave Taht <dave.taht@gmail.com>
> Date: Tue, 10 Apr 2012 13:46:38 -0700
>
> > awesome, is this needed in stable?
>
> I have it queued up there already.
>
> But you didn't need to write your email at all, you could
> have checked this yourself:
>
> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
Not sure this URL works (it doesnt for me)
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Bjarke Istrup Pedersen @ 2012-04-10 21:15 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, netdev
In-Reply-To: <20120410204249.GA26627@electric-eye.fr.zoreil.com>
10. apr. 2012 22.42 skrev Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
> [...]
>> Got any ideas?
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=3f8c91a7398b9266fbe7abcbe4bd5dffef907643
>
> Courtesy of Andreas Mohr.
Great, I'll try a 3.4-rc2 kernel, and see how it runs.
The thread I was talking about earlier is here:
http://lists.soekris.com/pipermail/soekris-tech/2012-April/018318.html
Is there any of the changes he has there, that makes sense in the new
driver you wrote?
Thanks :)
/Bjarke
> --
> Ueimor
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: David Miller @ 2012-04-10 21:16 UTC (permalink / raw)
To: eric.dumazet
Cc: dave.taht, ncardwell, netdev, nanditad, ycheng, edumazet,
therbert
In-Reply-To: <1334092294.5300.614.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Apr 2012 23:11:34 +0200
> On Tue, 2012-04-10 at 17:07 -0400, David Miller wrote:
>> From: Dave Taht <dave.taht@gmail.com>
>> Date: Tue, 10 Apr 2012 13:46:38 -0700
>>
>> > awesome, is this needed in stable?
>>
>> I have it queued up there already.
>>
>> But you didn't need to write your email at all, you could
>> have checked this yourself:
>>
>> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
>
> Not sure this URL works (it doesnt for me)
Sorry, that's my private URL and only works if you're logged
in as me :-) This one is better:
http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
^ 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