On Fri, Dec 03, 2010 at 12:41:48PM +0100, Miloslav Trmač wrote:
>
> Signed-off-by: Miloslav Trmač
All applied. Thanks Miloslav!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send t
On Wed, Dec 08, 2010 at 08:08:13AM +0800, Harald Welte wrote:
>
> Is there a list of machines (/proc/cpuinfo) on which the problem has shown up
> so far?
Yes, this is the one that's show the problem:
| -bash-4.0# cat /proc/cpuinfo
| processor : 0
| vendor_id : CentaurHauls
| cpu family
Sorry for jumping into this thread so late.
I am almost constantly on business travel (without any VIA system with me), so
I cannot try to reproduce the problem. It probably has never shown up before
since my typical test case is dm-crypt and there you will of course never see
any unaligned buffe
On Fri, 2010-12-03 at 13:42 +, David Howells wrote:
> Mimi Zohar wrote:
>
> > +#define KEY_TRUSTED_PREFIX "trusted:"
> > +#define KEY_TRUSTED_PREFIX_LEN (sizeof (KEY_TRUSTED_PREFIX) - 1)
> > +#define KEY_USER_PREFIX "user:"
> > +#define KEY_USER_PREFIX_LEN (sizeof (KEY_USER_PREFIX) - 1)
>
>
Hi,
On Tue, Dec 07, 2010 at 07:39:56PM +0800, Herbert Xu wrote:
> On Tue, Dec 07, 2010 at 11:41:41AM +0100, Phil Sutter wrote:
> >
> > Yes, CONFIG_PREEMPT is active in my test system's kernel.
>
> OK, can you see if the problem is still reproducible without
> preemption?
Yes, it is. I just redid
On Tue, Dec 07, 2010 at 11:41:41AM +0100, Phil Sutter wrote:
>
> Yes, CONFIG_PREEMPT is active in my test system's kernel.
OK, can you see if the problem is still reproducible without
preemption?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor
Hi,
On Thu, Dec 02, 2010 at 02:14:41PM +0800, Herbert Xu wrote:
> > Yes, it does, but triggering the bug is not really trivial. I've had
> > best results with a speed testing tool using the asynchronous interface,
> > memory corruption occured in each run. The same tool operating
> > synchronously
The following patchset adds Traffic Flow Confidentiality padding. The
first patch introduces a new Netlink XFRM attribute to configure TFC via
userspace. Patch two and three implement the padding logic in IPv4 and
IPv6 ESP. Padding is always done using the RFC4303 format an is clamped
to the PMTU.
The XFRMA_TFC attribute for XFRM state installation configures
Traffic Flow Confidentiality by padding ESP packets to a specified
length.
Signed-off-by: Martin Willi
---
include/linux/xfrm.h |6 ++
include/net/xfrm.h |1 +
net/xfrm/xfrm_user.c | 16 ++--
3 files chang
Add TFC padding to all packets smaller than the boundary configured
on the xfrm state. If the boundary is larger than the PMTU, limit
padding to the PMTU.
Signed-off-by: Martin Willi
---
net/ipv4/esp4.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
Add TFC padding to all packets smaller than the boundary configured
on the xfrm state. If the boundary is larger than the PMTU, limit
padding to the PMTU.
Signed-off-by: Martin Willi
---
net/ipv6/esp6.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
thanks
On 02/12/10 10:37, ext Herbert Xu wrote:
> On Tue, Nov 30, 2010 at 10:13:26AM +0200, Dmitry Kasatkin wrote:
>
>> Changes to v1:
>> - omap type specific handling removed
>> - fixed backlog handling bug in "redundunt locking is removed"
>> - aes module initialized once per request instead
12 matches
Mail list logo
