On 31/12/2018 15:03, Joseph Myers wrote:
> On Fri, 28 Dec 2018, Adhemerval Zanella wrote:
>
Currently we only have nios2 and csky (unfortunately). But since generic
definition for off_t and off64_t still assumes non-LFS support, all new
32-bits ports potentially might carry
On Fri, 28 Dec 2018, Adhemerval Zanella wrote:
> >> Currently we only have nios2 and csky (unfortunately). But since generic
> >> definition for off_t and off64_t still assumes non-LFS support, all new
> >> 32-bits ports potentially might carry the issue.
> >
> > For csky, we could still
On Sat, 29 Dec 2018 at 16:49, Andy Lutomirski wrote:
> > Could you use a prctl to set whether you were running in 32 or 64 bit
> > mode? Or do you change which kind of task you're emulating too often
> > to make this a good idea?
QEMU's linux-user mode always only runs the single process,
which
> On Dec 28, 2018, at 6:54 PM, Matthew Wilcox wrote:
>
>> On Sat, Dec 29, 2018 at 12:12:27AM +, Peter Maydell wrote:
>> On Fri, 28 Dec 2018 at 23:16, Andreas Dilger wrot
>>> On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote:
The problem is that there is no 32-bit API in some cases
On Sat, Dec 29, 2018 at 03:37:21AM +0100, Dominique Martinet wrote:
> > Are there going to be cases where a process or a thread will sometimes
> > want the 64-bit interface, and sometimes want the 32-bit interface?
> > Or is it always going to be one or the other? I wonder if we could
> > simply
Theodore Y. Ts'o wrote on Fri, Dec 28, 2018:
> > The problem is that there is no 32-bit API in some cases
> > (unless I have misunderstood the kernel code) -- not all
> > host architectures implement compat syscalls or allow them
> > to be called from 64-bit processes or implement all the older
>
On Fri, Dec 28, 2018 at 11:18:18AM +, Peter Maydell wrote:
> In general inodes and offsets start from 0 and work up --
> so almost all of the time they don't actually overflow.
> The problem with ext4 directory hash "offsets" is that they
> overflow all the time and immediately, so instead of
On Sat, Dec 29, 2018 at 12:12:27AM +, Peter Maydell wrote:
> On Fri, 28 Dec 2018 at 23:16, Andreas Dilger wrot
> > On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote:
> > > The problem is that there is no 32-bit API in some cases
> > > (unless I have misunderstood the kernel code) -- not all
>
On Fri, 28 Dec 2018 at 23:16, Andreas Dilger wrot
> On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote:
> > The problem is that there is no 32-bit API in some cases
> > (unless I have misunderstood the kernel code) -- not all
> > host architectures implement compat syscalls or allow them
> > to be
On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote:
>
> On Fri, 28 Dec 2018 at 00:23, Andreas Dilger wrote:
>> On Dec 27, 2018, at 10:41 AM, Peter Maydell wrote:
>>> As you note, this causes breakage for userspace programs which
>>> need to implement an API/ABI with 32-bit offset but which only
[sending again, slightly edited, due to email client issues]
On Thu, Dec 27, 2018 at 9:25 AM Florian Weimer wrote:
>
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field
On 28/12/2018 10:01, Florian Weimer wrote:
> * Florian Weimer:
>
>> * Adhemerval Zanella:
>>
>>> On 27/12/2018 16:09, Florian Weimer wrote:
* Adhemerval Zanella:
> Also for glibc standpoint, although reverting it back to use getdents
> syscall for non-LFS mode might fix this
On 27/12/2018 16:09, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> Also for glibc standpoint, although reverting it back to use getdents
>> syscall for non-LFS mode might fix this issue for architectures that
>> provides non-LFS getdents syscall it won't be a fix for architectures
>>
* Adhemerval Zanella:
> On 27/12/2018 16:09, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> Also for glibc standpoint, although reverting it back to use getdents
>>> syscall for non-LFS mode might fix this issue for architectures that
>>> provides non-LFS getdents syscall it won't be a
* Florian Weimer:
> * Adhemerval Zanella:
>
>> On 27/12/2018 16:09, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
Also for glibc standpoint, although reverting it back to use getdents
syscall for non-LFS mode might fix this issue for architectures that
provides non-LFS
On Fri, 28 Dec 2018 at 00:23, Andreas Dilger wrote:
> On Dec 27, 2018, at 10:41 AM, Peter Maydell wrote:
> > As you note, this causes breakage for userspace programs which
> > need to implement an API/ABI with 32-bit offset but which only
> > have access to the kernel's 64-bit offset API/ABI.
>
* Dmitry V. Levin:
> On Thu, Dec 27, 2018 at 06:18:19PM +0100, Florian Weimer wrote:
>> We have a bit of an interesting problem with respect to the d_off
>> field in struct dirent.
>>
>> When running a 64-bit kernel on certain file systems, notably ext4,
>> this field uses the full 63 bits even
On Dec 27, 2018, at 10:41 AM, Peter Maydell wrote:
>
> On Thu, 27 Dec 2018 at 17:19, Florian Weimer wrote:
>> We have a bit of an interesting problem with respect to the d_off
>> field in struct dirent.
>>
>> When running a 64-bit kernel on certain file systems, notably ext4,
>> this field
On Thu, Dec 27, 2018 at 06:18:19PM +0100, Florian Weimer wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories
* Adhemerval Zanella:
> Also for glibc standpoint, although reverting it back to use getdents
> syscall for non-LFS mode might fix this issue for architectures that
> provides non-LFS getdents syscall it won't be a fix for architectures
> that still provides off_t different than off64_t *and*
On 27/12/2018 15:18, Florian Weimer wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output,
* Andy Lutomirski:
>> On Dec 27, 2018, at 10:18 AM, Florian Weimer wrote:
>>
>> We have a bit of an interesting problem with respect to the d_off
>> field in struct dirent.
>>
>> When running a 64-bit kernel on certain file systems, notably ext4,
>> this field uses the full 63 bits even for
On Thu, 27 Dec 2018 at 17:19, Florian Weimer wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
>
> On Dec 27, 2018, at 10:18 AM, Florian Weimer wrote:
>
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace
We have a bit of an interesting problem with respect to the d_off
field in struct dirent.
When running a 64-bit kernel on certain file systems, notably ext4,
this field uses the full 63 bits even for small directories (strace -v
output, wrapped here for readability):
getdents(3, [
25 matches
Mail list logo
