mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthias Andree <matthias.andree@gmx.de>
To: Joerg Schilling <schilling@fokus.fraunhofer.de>
Cc: Linux-Kernel mailing list <linux-kernel@vger.kernel.org>,
	cdwrite@other.debian.org
Subject: Request to stop cdrecord's bogus accusations of Linux.
Date: Mon, 30 Jan 2006 18:37:22 +0100	[thread overview]
Message-ID: <20060130173722.GC3973@merlin.emma.line.org> (raw)

Jörg,

with this open letter, I officially request that you stop your
misrepresentations in cdrecord that claim Linux were noncompliant in a
place where it is conforming to POSIX.

I am not speaking on behalf of any other party here, this is purely my
personal opinion that is supposed to make sure both sides play fair.

<ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a05>
(dated 2006-01-29 20:20" states

  "-  Trying to work around a noncompliance (modified interface) present
  on newer Linux kernels that causes cdrecord to be unable to allocate a
  SCSI transfer buffer.

  Newer Linux kernels do not honor a contract from mlockall(MCL_FUTURE)
  after cdrecord turned off euid == 0 from a suid root installation.
  Instead of honoring mlockall(MCL_FUTURE), Linux checks each mmap() and
  compares against getrlimit(RLIMIT_MEMLOCK"

There is no such contract that would promise future allocations to
always succeed after MCL_FUTURE.

POSIX explicitly allows operating systems to fail later allocations if
the limit of mappable memory exceeds a certain limit, quoting the
mlockall() description from IEEE Std 1003.1-2001, 2004 edition:

  "If MCL_FUTURE is specified, and the automatic locking of future
  mappings eventually causes the amount of locked memory to exceed the
| amount of available physical memory or any other
| implementation-defined limit, the behavior is implementation-defined.
| The manner in which the implementation informs the application of
| these situations is also implementation-defined."

Linux is therefore POSIX compliant here. MCL_FUTURE succeeds and the
RLIMIT_MEMLOCK interface that you are whining about is this
"implementation-defined limit", and the implementation-defined behavior
refusing the allocation.

You had been told much earlier in linux-kernel@ that Linux is POSIX
compliant here, yet your document repeats this slander.

You are correct that Linux changed behavior beginning with release
2.6.9, but that change does not make Linux noncompliant with applicable
standards. I suggest to reword the quoted paragraph as

  "Working around a new behavior in Linux since 2.6.9 that causes
   cdrecord to be unable to allocate a SCSI transfer buffer.

   These Linux kernel versions impose a tighter RLIMIT_MEMLOCK limit
   than earlier versions that cause the allocation failure."

-- 
Matthias Andree

             reply	other threads:[~2006-01-30 17:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-30 17:37 Matthias Andree [this message]
2006-01-30 17:47 ` Joerg Schilling
2006-01-30 18:03   ` Matthias Andree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060130173722.GC3973@merlin.emma.line.org \
    --to=matthias.andree@gmx.de \
    --cc=cdwrite@other.debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schilling@fokus.fraunhofer.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®