linux-kernel - Re: Strange transmit corruption in jsm driver on geode sc1200 system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060825215724.GI13641@csclub.uwaterloo.ca>
Date:	Fri, 25 Aug 2006 17:57:24 -0400
From:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: Strange transmit corruption in jsm driver on geode sc1200 system

On Sat, Aug 26, 2006 at 01:24:41AM +0400, Alexey Dobriyan wrote:
> But you can check. Insert something like this in right place:
> 
> 	printk("%p\n", buffer);

It would be 1/4 of the time given the code is this:

memcpy_toio(&ch->ch_neo_uart->txrxburst, ch->ch_wqueue + tail, s);

tail is the offset in the write queue in the jsm driver, which can be
any offset whatsoever.  So sometimes it is 32bit aligned, but often it
isn't.

The txrxburst of course is 32bit alligned.  Receiving works fine when
copying from the alligned buffer in hardware to wherever in the receiver
queue.

Of course given the __memcpy assembly seems to work fine unalligned on a
pentium4, and probably most othe systems, what could make it not work
correctly on a geode SC1200?

This is the chunk of assembly in use:

static __always_inline void * __memcpy(void * to, const void * from, size_t n)
{
int d0, d1, d2;
__asm__ __volatile__(
        "rep ; movsl\n\t"
        "movl %4,%%ecx\n\t"
        "andl $3,%%ecx\n\t"
#if 1   /* want to pay 2 byte penalty for a chance to skip microcoded rep? */
        "jz 1f\n\t"
#endif
        "rep ; movsb\n\t"
        "1:"
        : "=&c" (d0), "=&D" (d1), "=&S" (d2)
        : "0" (n/4), "g" (n), "1" ((long) to), "2" ((long) from)
        : "memory");
return (to);
}

I am affraid I don't know the rep instruction on x86, so it really
doesn't make sense to me.

I suppose if nothing else works, I can do one byte at a time until the
tail is 32bit alligned, and then do the rest of the transfer as a block
and see if that makes it work, or whether it is broken no matter what
the allignement of the buffer is.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/