Re: Problem with cat

2017-03-15 Thread Grant Edwards 
On 2017-03-15, Sam Liddicott  wrote:
> On 14 March 2017 at 14:44, Grant Edwards  wrote:
>
>> On 2017-03-14, Lauri Kasanen  wrote:
>> > On Mon, 13 Mar 2017 19:24:17 + (UTC)
>> > Grant Edwards  wrote:
>> >
>> >> That paragraph is wrong (or at least misleading). I've checked the
>> >> source code, and 2.6.33 does not update the output file postition (at
>> >> least not the version I downloaded from kernels.org nor the version I
>> >> got from Atmel). Perhaps the author of that man page had a 2.6.33 with
>> >> some 3.0 stuff backported.
>> >
>> > Please report the bug to them. I've found the man-pages project quite
>> > responsive.
>>
>> Done... thanks for reminding me.  Unfortunately, I can't build/test
>> kernels between 2.6.33.7 (sendfile->file broken), and 3.2 (works) to
>> find the exact point where the change that correctly sets the output
>> file position happened.
>
> And as has been said, it may not help if you did; who can know which
> patches have been ported anyway.

I can, and I do.

None of the patches applied to 2.6.33.7 touch the filesystem code.

None of the other kernels I tested with had any patches applied.

-- 
Grant Edwards   grant.b.edwardsYow! I'm also against
  at   BODY-SURFING!!
  gmail.com

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Problem with cat

2017-03-15 Thread Sam Liddicott 
On 14 March 2017 at 14:44, Grant Edwards  wrote:

> On 2017-03-14, Lauri Kasanen  wrote:
> > On Mon, 13 Mar 2017 19:24:17 + (UTC)
> > Grant Edwards  wrote:
> >
> >> That paragraph is wrong (or at least misleading). I've checked the
> >> source code, and 2.6.33 does not update the output file postition (at
> >> least not the version I downloaded from kernels.org nor the version I
> >> got from Atmel). Perhaps the author of that man page had a 2.6.33 with
> >> some 3.0 stuff backported.
> >
> > Please report the bug to them. I've found the man-pages project quite
> > responsive.
>
> Done... thanks for reminding me.  Unfortunately, I can't build/test
> kernels between 2.6.33.7 (sendfile->file broken), and 3.2 (works) to
> find the exact point where the change that correctly sets the output
> file position happened.
>

And as has been said, it may not help if you did; who can know which
patches have been ported anyway.

Sam
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Problem with cat

2017-03-14 Thread Grant Edwards 
On 2017-03-14, Lauri Kasanen  wrote:
> On Mon, 13 Mar 2017 19:24:17 + (UTC)
> Grant Edwards  wrote:
>
>> That paragraph is wrong (or at least misleading). I've checked the
>> source code, and 2.6.33 does not update the output file postition (at
>> least not the version I downloaded from kernels.org nor the version I
>> got from Atmel). Perhaps the author of that man page had a 2.6.33 with
>> some 3.0 stuff backported.
>
> Please report the bug to them. I've found the man-pages project quite
> responsive.

Done... thanks for reminding me.  Unfortunately, I can't build/test
kernels between 2.6.33.7 (sendfile->file broken), and 3.2 (works) to
find the exact point where the change that correctly sets the output
file position happened.

-- 
Grant Edwards   grant.b.edwardsYow! My face is new, my
  at   license is expired, and I'm
  gmail.comunder a doctor's care

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Problem with cat

2017-03-14 Thread Lauri Kasanen 
On Mon, 13 Mar 2017 19:24:17 + (UTC)
Grant Edwards  wrote:

> That paragraph is wrong (or at least misleading). I've checked the
> source code, and 2.6.33 does not update the output file postition (at
> least not the version I downloaded from kernels.org nor the version I
> got from Atmel). Perhaps the author of that man page had a 2.6.33 with
> some 3.0 stuff backported.

Please report the bug to them. I've found the man-pages project quite
responsive.

- Lauri
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Problem with cat

2017-03-13 Thread Grant Edwards 
On 2017-03-13, Grant Edwards <grant.b.edwa...@gmail.com> wrote:

> After upgrading to a new version of busybox (1.25.1), I now have an
> odd problem with 'cat'.  When stdout is a file, it _appears_ to be
> doing a seek to the beginning of the output file between input files.

[...]

> But, strace doesn't show any seeks.  I see that 'cat' is using
> sendfile mutiple times.  According to sendfile(2):
>
>In Linux kernels before 2.6.33, out_fd must refer to a  socket.   Since
>Linux  2.6.33  it can be any file.  If it is a regular file, then send‐
>file() changes the file offset appropriately.
>
> Apparently "change file file offset apprpriatly" means it gets reset
> to zero after every call to sendfile().  I take it this implementation
> of 'cat' works for other people?

Apologies for the noise -- I finally stumbled across
CONFIG_FEATURE_USE_SENDFILE, and disabling that fixes the 'cat'
problem with 2.6.33 kernels.

-- 
Grant Edwards   grant.b.edwardsYow! I smell a RANCID
  at   CORN DOG!
  gmail.com

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Problem with cat

2017-03-13 Thread Grant Edwards 
On 2017-03-13, Grant Edwards <grant.b.edwa...@gmail.com> wrote:

> After upgrading to a new version of busybox (1.25.1), I now have an
> odd problem with 'cat'.  When stdout is a file, it _appears_ to be
> doing a seek to the beginning of the output file between input files.

[...]

> But, strace doesn't show any seeks.  I see that 'cat' is using
> sendfile mutiple times.  According to sendfile(2):
>
>In Linux kernels before 2.6.33, out_fd must refer to a  socket.   Since
>Linux  2.6.33  it can be any file.  If it is a regular file, then send‐
>file() changes the file offset appropriately.
>
> Apparently "change file file offset apprpriatly" means it gets reset
> to zero after every call to sendfile().  I take it this implementation
> of 'cat' works for other people?

That paragraph is wrong (or at least misleading). I've checked the
source code, and 2.6.33 does not update the output file postition (at
least not the version I downloaded from kernels.org nor the version I
got from Atmel). Perhaps the author of that man page had a 2.6.33 with
some 3.0 stuff backported.

The sendfile implementation for 2.6.33 is virtually identical to
2.6.31 (there's one added error-check to make sure an offset is
non-negative).

In 3.x, sendfile clearly updates the output file position.

So, it appears that busybox 1.25.1 requires a 3.0 kernel or newer. :(

Where does one find the kernel-version-dependencies for busybox

What's the latest version of busybox that I _can_ use with 2.6.33?

-- 
Grant Edwards   grant.b.edwardsYow! I put aside my copy
  at   of "BOWLING WORLD" and
  gmail.comthink about GUN CONTROL
   legislation...

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Problem with cat

2017-03-13 Thread Grant Edwards 
On 2017-03-13, Grant Edwards <grant.b.edwa...@gmail.com> wrote:

> After upgrading to a new version of busybox (1.25.1), I now have an
> odd problem with 'cat'.  When stdout is a file, it _appears_ to be
> doing a seek to the beginning of the output file between input files.
[...]
>   # ls -l
>   total 12
>   -rw-r--r--1 root root29 Mar 13 17:44 d1
>   -rw-r--r--1 root root29 Mar 13 17:44 d2
>   -rw-r--r--1 root root29 Mar 13 17:44 d3
>
>   # cat d1 d2 d3
>   Mon Mar 13 17:44:35 UTC 2017
>   Mon Mar 13 17:44:40 UTC 2017
>   Mon Mar 13 17:44:43 UTC 2017
>
>   # cat d1 d2 d3 >foo
>
>   # ls -l
>   total 16
>   -rw-r--r--1 root root29 Mar 13 17:44 d1
>   -rw-r--r--1 root root29 Mar 13 17:44 d2
>   -rw-r--r--1 root root29 Mar 13 17:44 d3
>   -rw-r--r--1 root root29 Mar 13 17:46 foo
>
>   # cat foo
>   Mon Mar 13 17:44:43 UTC 2017

The failure is happening w/ busybox 1.25.1 on an ARM9 running kernel
2.6.33.7.

The same version of busybox on an AMD64 running kernel 4.4.39 works
fine.

The strace output for the read/sendfile operations looks identical
between the two, so it sort of looks like a kernel problem...

-- 
Grant Edwards   grant.b.edwardsYow! I'm not available
  at   for comment..
  gmail.com

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Problem with cat

2017-03-13 Thread Grant Edwards 
After upgrading to a new version of busybox (1.25.1), I now have an
odd problem with 'cat'.  When stdout is a file, it _appears_ to be
doing a seek to the beginning of the output file between input files.

  # ls -l
  total 8
  -rw-r--r--1 root root  1034 Mar 13 17:32 serverRsaCert.pem
  -rw-r--r--1 root root   887 Mar 13 17:32 serverRsaKey.pem

  # cat serverRsaCert.pem serverRsaKey.pem > foo

  # ls -l
  total 12
  -rw-r--r--1 root root  1034 Mar 13 17:38 foo
  -rw-r--r--1 root root  1034 Mar 13 17:32 serverRsaCert.pem
  -rw-r--r--1 root root   887 Mar 13 17:32 serverRsaKey.pem

In the output file, the contents of serverRsaKey.pem are written over
the beginning of the contents of serverRsaCert.pem.

Piping the output of 'cat' to another instance of cat fixes the
problem (presumably because a pipe isn't seekable?).

  # cat serverRsaCert.pem serverRsaKey.pem > foo
  # cat serverRsaCert.pem serverRsaKey.pem | cat > bar
  # ls -l
  total 16
  -rw-r--r--1 root root  1921 Mar 13 17:43 bar
  -rw-r--r--1 root root  1034 Mar 13 17:43 foo
  -rw-r--r--1 root root  1034 Mar 13 17:32 serverRsaCert.pem
  -rw-r--r--1 root root   887 Mar 13 17:32 serverRsaKey.pem

The same thing happens with more than two files:

  # ls -l
  total 12
  -rw-r--r--1 root root29 Mar 13 17:44 d1
  -rw-r--r--1 root root29 Mar 13 17:44 d2
  -rw-r--r--1 root root29 Mar 13 17:44 d3

  # cat d1 d2 d3
  Mon Mar 13 17:44:35 UTC 2017
  Mon Mar 13 17:44:40 UTC 2017
  Mon Mar 13 17:44:43 UTC 2017

  # cat d1 d2 d3 >foo

  # ls -l
  total 16
  -rw-r--r--1 root root29 Mar 13 17:44 d1
  -rw-r--r--1 root root29 Mar 13 17:44 d2
  -rw-r--r--1 root root29 Mar 13 17:44 d3
  -rw-r--r--1 root root29 Mar 13 17:46 foo

  # cat foo
  Mon Mar 13 17:44:43 UTC 2017

But, strace doesn't show any seeks.  I see that 'cat' is using
sendfile mutiple times.  According to sendfile(2):

   In Linux kernels before 2.6.33, out_fd must refer to a  socket.   Since
   Linux  2.6.33  it can be any file.  If it is a regular file, then send‐
   file() changes the file offset appropriately.

Apparently "change file file offset apprpriatly" means it gets reset
to zero after every call to sendfile().  I take it this implementation
of 'cat' works for other people?


  execve("/bin/cat", ["cat", "serverRsaCert.pem", "serverRsaKey.pem"], [/* 13 
vars */]) = 0
  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x400, 
-1, 0) = 0x40007000
  stat("/etc/ld.so.cache", 0xbea37a68)= -1 ENOENT (No such file or 
directory)
  open("/apps/lib/libc.so.0", O_RDONLY)   = -1 ENOENT (No such file or 
directory)
  open("/lib/libc.so.0", O_RDONLY)= 3
  fstat(3, {st_mode=S_IFREG|0755, st_size=331104, ...}) = 0
  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x400, 
-1, 0) = 0x40008000
  read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\320\250\0\0004\0\0\0"..., 4096) 
= 4096
  mmap2(NULL, 385024, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001
  mmap2(0x4001, 324524, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 
0x4001
  mmap2(0x40067000, 5136, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x4f000) = 0x40067000
  mmap2(0x40069000, 16432, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40069000
  close(3)= 0
  munmap(0x40008000, 4096)= 0
  stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=32664, ...}) = 0
  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x400, 
-1, 0) = 0x40008000
  set_tls(0x400084a0, 0x40008b40, 0x40008b48, 0x400084a0, 0x4000ef74) = 0
  mprotect(0xbc000, 4096, PROT_READ)  = 0
  mprotect(0x40067000, 4096, PROT_READ)   = 0
  mprotect(0x4000e000, 4096, PROT_READ)   = 0
  ioctl(0, TCGETS, {B115200 opost isig icanon echo ...}) = 0
  ioctl(1, TCGETS, 0xbea37a1c)= -1 ENOTTY (Inappropriate ioctl for 
device)
  getuid32()  = 0
  open("serverRsaCert.pem", O_RDONLY|O_LARGEFILE) = 3
  sendfile64(1, 3, NULL, 16777216)= 1034
  sendfile64(1, 3, NULL, 16777216)= 0
  close(3)= 0
  open("serverRsaKey.pem", O_RDONLY|O_LARGEFILE) = 3
  sendfile64(1, 3, NULL, 16777216)= 887
  sendfile64(1, 3, NULL, 16777216)= 0
  close(3)= 0
  exit_group(0)   = ?
  +++ exited with 0 +++

-- 
Grant Edwards   grant.b.edwardsYow! !  I'm in a very
  at   clever and adorable INSANE