On Wed, 9 Feb 2005 07:04:22 +0100
"Jurzitza, Dieter" <[EMAIL PROTECTED]> wrote:
> seing the communication between Jurij and Dave I took a glance into the
> 2.4.29 - tree and found the identical code segment as discussed below. This
> tells me that 2.4.X is supposed to suffer from the same issues
onday, February 07, 2005 8:58 PM
To: [EMAIL PROTECTED]
Cc: sparclinux@vger.kernel.org
Subject: Re: Hang in SIOCGIFCONF ioctl handler
On Mon, 7 Feb 2005 13:21:16 -0500 (EST)
Jurij Smakov <[EMAIL PROTECTED]> wrote:
> On an unrelated note, during my exploration I came across the function
> c
On Mon, 7 Feb 2005, David S. Miller wrote:
Yep, and notice that the "extra bit" is (1 << 32), or the first bit
in the upper 32-bits of the 64-bit kernel pointer. In short, we get
garbage from the upper 32-bits of the stack pointer, and need to
mask it out for 32-bit tasks. The fix is obvious, try
On Mon, 7 Feb 2005 22:34:44 -0500 (EST)
Jurij Smakov <[EMAIL PROTECTED]> wrote:
> dev_ifconf[518]: i=0 ifr=0001efffacf8 ifr32=efffd898
>
> alloc_size is the amount allocated by compat_alloc_user_space(). The only
> "strange" thing I can notice is the ifr address. On a few previous ca
On Mon, 7 Feb 2005, David S. Miller wrote:
On Mon, 7 Feb 2005 13:21:16 -0500 (EST)
Jurij Smakov <[EMAIL PROTECTED]> wrote:
510 size_t len =((ifc32.ifc_len / sizeof (struct ifreq32)) + 1)
*
511 sizeof (struct ifreq);
512 uifc = compat_alloc_us
On Mon, 7 Feb 2005 13:21:16 -0500 (EST)
Jurij Smakov <[EMAIL PROTECTED]> wrote:
> On an unrelated note, during my exploration I came across the function
> copy_in_user_fixup in arch/sparc64/lib/user_fixup.c. In this function (and
> in other functions in that file) copying is done using a loop li
On Mon, 7 Feb 2005 13:21:16 -0500 (EST)
Jurij Smakov <[EMAIL PROTECTED]> wrote:
> 510 size_t len =((ifc32.ifc_len / sizeof (struct ifreq32)) +
> 1) *
> 511 sizeof (struct ifreq);
> 512 uifc = compat_alloc_user_space(sizeof(struct ifconf) +
