On Mon, 28 Jan 2008 15:10:34 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Monday 28 January 2008 14:38:57 Alan Cox wrote:
> > > Also worse really fixing it would be a major change to the VFS
> > > because of the way ->read/write are defined :/
> >
> &g
> Also worse really fixing it would be a major change to the VFS
> because of the way ->read/write are defined :/
I don't see a problem there. ->read and ->write update the passed pointer
which is not the real f_pos anyway. Just the copies need fixing.
Alan
-
To unsubscribe
> > No specific spec, just general quality of implementation.
>
> I completely agree. If one thread writes A and another writes B then the
> kernel should record either A or B, not ((A & 0x) | (B &
> 0x))
Agree entirely: the spec doesn't allow for random scribbling in the
signal variant for
free.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Writeback cache on disk in iteself is not bad, it only gets bad if the
> disk is not engineered to save all its dirty cache on power loss,
> using the disk motor as a generator or alternatively a small battery.
> It would be awfully nice to know which brands fail here, if any,
> because writeback
sectors around sector being written during
> powerfail; can ext3 survive that?
generally. Note btw that for added fun there is nothing that guarantees
the blocks around a block on the media are sequentially numbered. The
usually are but you never know.
Alan
-
To unsubscribe from this list: send the
> Andi Kleen wrote:
>> Theodore Tso <[EMAIL PROTECTED]> writes:
>> > Now, there are good reasons for doing periodic checks every N mounts
>> > and after M months. And it has to do with PC class hardware. (Ted's
>> > aphorism: "PC class hardware is cr*p").
>>
>> If these reasons are good ones (som
plying to stable kernels now.
>
> Thanks to George Davis for reporting the problem.
>
> Cc: "George G. Davis" <[EMAIL PROTECTED]>
> Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Its a good fix for now and I do
Linux (for now)
flag to say "don't bother"
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
posix_deadlock_detect()
The failure case for removing this feature is obscure and hard to debug
application hangs for the afflicted programs - not nice for users at all.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 28 Oct 2007 17:38:14 -0600
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 28, 2007 at 09:38:55PM +0000, Alan Cox wrote:
> > > It doesn't require the system to detect it, only mandate what to return
> > > if it does detect it.
> >
> >
nk the resolution was that the EDEADLK stayed.
> What is your suggestion for handling this problem? As it is now, the
> kernel 'detects' deadlock where there is none, which doesn't seem
> allowed by SuSv3 either
Re-read the spec. The EDEADLK doesn't account for threads
> Bzzt. You get a false deadlock with multiple threads like so:
>
> Thread A of task B takes lock 1
> Thread C of task D takes lock 2
> Thread C of task D blocks on lock 1
> Thread E of task B blocks on lock 2
The spec and SYSV certainly ignore threading in this situation and you
know that perfe
> > - EDEADLK behaviour is ABI
>
> Not in any meaningful way.
I've seen SYS5 software that relies on it so we should be careful. Again
see the 2004 discussion where the conclusion was that EDEADLK should stay
>
> > - EDEADLK behaviour is required by SuSv3
>
> What SuSv3 actually says is:
>
>
00017.html
so we need to fix the bugs - the lock usage and the looping. At that
point it merely becomes a performance concern to those who use it, which
is the proper behaviour. If you want a faster non-checking one use
flock(), or add another flag that is a Linux "don't check for deadlock&
> I found Chris's comment about negative block numbers, I'll send a patch
> out for that.
>
> You mentioned back in 99 about racing with ftruncate. Is it sufficient
> to mutex_lock(i_mutex) and down_read(i_alloc_sem)?
One for the fs guys. That code has changed far beyond anything I
understand
ut what occurs when
FIBMAP is passed random block numbers.
FIBMAP has another problem for this general use as well - it takes an int
but the block number can now be bigger for very large files on 32bit.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
th
> Cute feature, but it is (I assume) a Linux-specific extension and is
> something which we'll need to maintain for ever and it invites
Actually it used to work on the old old Linux pipe code.
> unportability to older Linuxes and other OSes and it introduces some risk
> of breakage of existing ap
27;ve spent years changing error values and getting them
right in the past.
There are real things to worry about - sysfs, sysfs, sysfs, ... and all
the other crap which is continually breaking stuff, not spec compliance
corrections that don't break things but move us into compliance with the
em if they
> complain is unlikely to impress them.
And our existing behaviour may well break correctly written
portable applications, and is incorrect as well.
Testing so far says it doesn't break anything, which is no suprise if you
apply about ten braincells to the case under consideration.
On Thu, 27 Sep 2007 07:01:18 -0700
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Sep 2007 14:29:19 +0100
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > The early LFS work that Linux uses favours EFBIG in various places.
> > SuSv3 specifically uses EOVER
therefore
transition to the proper error return code
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/fs/gfs2/ops_file.c
linux-2.6.23rc8-mm1/fs/gfs2/ops_file.c
--- linux.vanilla-2.6.23rc8-mm1/fs/gfs2/ops_
ctory. I don't see that ssh/sftp needs to do that. Instead it can
sillyrename anywhere in the filesystem.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
d use poll() as it is a bit more clear about what
event you get
Then poll stdin and stdout. The kernel will give you back
POLLERR - an error condition
POLLHUP - a hangup
if at the point you poll an error has already occurred. You can do this
with select and the socket error and related stuff buts it
> when a pipe/socket is broken, the process trying to read/write to it
> gets SIGPIPE. Is there a way to detect whether the next read/write will
> trigger a SIGPIPE? select() does not seem helpful here.
select considers the broken pipe an error that needs reporting so it goes
ready. Processes th
> > Anyone can apply the apparmour patch to their tree, they get the
> > choice that way. Nobody is currently prevented from using apparmour
> > if they want to, any such suggestion is pure rubbish.
>
> The exact same argument was made prior to SELinux going upstream.
Its made for every thing be
On Tue, 26 Jun 2007, Graeme Sheppard wrote:
alan wrote:
On Tue, 26 Jun 2007, Graeme Sheppard wrote:
Dear devs,
In a moment of serendipity I thought of a concept which may be
advantageous
if incorporated into the kernel. I was going to offer it to the OIN but
they responded they only
d one.
How do you know it is a new idea?
--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
-
To u
er everything.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.o
s acceptable as magic in a pathname, and the unix spec
even more so. The NetApp approach recognizes two important things
1. Old version access is the oddity not the norm
2. Standards behaviour is important
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdev
t;
[1] http://www.stream.com/
--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
-
To unsubscribe from t
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
On Mon, 18 Jun 2007, H. Peter Anvin wrote:
alan wrote:
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan <[EMAIL PROTECTED]> wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some
On Mon, 18 Jun 2007, Bodo Eggert wrote:
alan <[EMAIL PROTECTED]> wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
(Forked files
ays access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe
> (Vax/VMS System Software Handbook)
> (TOPS-20 User's Manual)
Also Files/11
Basic versioning goes back to at least ITS
Not sure how old doing file versioning and hiding it away with a tool to
go rescue the stuff you blew away by mistake is, but Novell Netware 3
certainly did a good job on t
> http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19&SORT=1211506-KEY&TYPE_FIELD=256&IDB=0&IDOC=1205953&C=10&ELEMENT_SET=IA,WO,TTL-EN&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG&SEARCH_IA=US2005045566&QUERY=%28IN%2fmerkey%29+
>
> The last on
atter how old or
obscure.)
--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
-
To unsubscribe from th
On Fri, 15 Jun 2007, H. Peter Anvin wrote:
alan wrote:
ZFS is the cool new thing in that space. Too bad the license makes it
hard to incorporate it into the kernel. (I am one of those people that
believe that Linux should support EVERY file system, no matter how old
or obscure.)
I have
than root privileges.
--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
-
To unsubscribe from this
> >> honest, even average-level system administrators should not be
> >> writing security policy.
> That explains so much! "SELinux: you're too dumb to use it, so just keep
> your hands in your pockets." :-)
Hardly. And there are helper tools
>
> AppArmor was designed to allow your average sys
> As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> and apply the policy relevant to the program. It could apply different
That's not actually useful for programs which link the same binary to
multiple names because if you don't consider argv[0] as well I can run
/usr/bin/gzi
> Preventive measures are taken to limit only one continuation inode per
> file per chunk. This can be done easily in the chunk allocation
> algorithm for disk space. Although I'm not quite sure what you mean by
How are you handling the allocation in this situation, are you assuming
that a chun
for the rootfs.
>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
This change in behaviour appears to be fine for glibc (except when trying
to find the name of a file from a namespace we are not in, which wouldn't
have come out right before either)
Acked-by: Alan Cox <[EMAIL
On Fri, 20 Apr 2007 01:23:04 +0200
Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> First, when __d_path() hits a lazily unmounted mount point, it tries to
> prepend
> the name of the lazily unmounted dentry to the path name. It gets this wrong,
> and also overwrites the slash that separates the
> As far as I can see, glibc internally looks at /proc/mounts (or else mtab) to
> find out where tmpfs is mounted for opening files there, and to look up
> filesystem information for statfs(), while accessing that path, too. Fstatfs()
> also looks into the same files, but it only matches by filesys
and hack on and may
be possible to configure to be very secure.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ssumption.
>
> Why?
Because the viewing apparatus on the other side of the monitor is not
operating in current directories/contexts.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> don't actually have to care --- if loading an invalid profile can bring down
> the system, then that's no worse than an arbitrary module that crashes the
> machine. Not sure if there will ever be user loadable profiles; at least at
> that point we had to care.
CAP_SYS_RAWIO is needed to do ar
> > That is a fairly significant and sudden change to the existing
> > kernel/user interface.
>
> Well, this is not meant for 2.6.21. I hope it is possible to change it in
> early 2.6.22; otherwise if we can't fix mistakes from the past we are pretty
> doomed.
I don't believe the existing behav
> + * aa_taskattr_access
> + * @name: name of the file to check
> + *
> + * Check if name matches /proc/self/attr/current, with self resolved
> + * to the current pid. This file is the usermode iterface for
> + * changing one's hat.
> + */
> +static inline int aa_taskattr_access(const char *name)
>
> + th.td_id = ntohs(*(u16 *) (blob));
> + th.td_flags = ntohs(*(u16 *) (blob + 2));
> + th.td_lolen = ntohl(*(u32 *) (blob + 8));
Use cpu_to and _to_cpu functions for here so it is clear the intended
direction and endianness.
> +
> +static inline int aa_inbounds(struct aa_ext *e, siz
> +
> + /**
> + * parent can ptrace child when
> + * - parent is unconfined
> + * - parent is in complain mode
> + * - parent and child are confined by the same profile
> + */
Your profiles are name based. That means the same profile in a different
namespace does diffe
closely (ditto all other attribute twiddles)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
on <[EMAIL PROTECTED]>
I don't think this is fit to apply in current form. The hiding of mounts
and mountstats is the wrong approach. The changes to getcwd behaviour
bother me too as we are changing user space behaviour without warning.
The general idea of pushing some of the fai
> For 1K/4K logical sector sizes, who knows. EFI?
> Certainly seems incompatible with the current popular DOS partition format.
Its a bit messier than that. There are two interpretations of "DOS"
partition formats found on 2K sector size magneto opticals. One is that
everything is the same as b
er than 1K or 4K, whatever the sector size is.
That one I'm not worried about - other than "guess how Redmond decide to
make partition tables work" that one is mostly easy (be fun to see how
many controllers simply can't cope with the command formats)
Alan
-
To unsubscrib
> Now, if this disk was copied byte per byte (/bin/dd) to a
> 4096-based disk, and Linux would start using a sector size of
> 4096, then I would suddenly have
The ATA drives I'm aware of report 512 byte sector size, do 512 byte
I/O's but use 4K physical sectors and to get sane performance except t
n btw 8)
I would be interested to know what the disk vendors intend to use as
their strategy when (with ATA) they have a 512 byte write from an older
file system/setup into a 4K block. The case where errors magically appear
in other parts of the fs when such an error occurs are not IMHO too well
On Thu, 01 Mar 2007 14:05:36 -0800
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Alan wrote:
> > A lot of people get confused about -ENOTTY, but it is the return for
> > attempting to use an ioctl on the wrong type of object, so this appears
> > to be quite corr
On Thu, 01 Mar 2007 13:14:32 -0800
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Amit K. Arora wrote:
> > + if (inode->i_op && inode->i_op->fallocate)
> > + ret = inode->i_op->fallocate(inode, offset, len);
> > + else
> > + ret = -ENOTTY;
>
> You can only allocate space
he only one with this
problem (and a workaround) which is SATA capable 8)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
t dangly bits
associated with a sequence of inodes with the same upper bits. More
problematic is losing indirect blocks, and being able to keep some kind
of [inode low bits/block index] would help put stuff back together.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdev
> One interesting counter example is a smaller write than a full page - say 512
> bytes out of 4k.
>
> If we need to do a read-modify-write and it just so happens that 1 of the 7
> sectors we need to read is flaky, will this "look" like a write failure?
The current core kernel code can't handle
> I'm not sure. Turning, for example, the statat(dir_fd, name == NULL)
> error case into fstat(dir_fd) sounds like a way for apps, admittedly
> buggy ones, to be surprised. Maybe libc would be exptected to catch
> the error before performing the shared system call?
At that point would it n
> I think that this is mostly true, but we also need to balance this against
> the
> need for higher levels to get a timely response. In a really large IO, a
> naive
> retry of a very large write could lead to a non-responsive system for a very
> large time...
And losing the I/O could result
true. If you write a sector on a device with
physical sector size larger than logical block size (as allowed by say
ATA7) then it's less clear what happens. I don't know if the drive
firmware implements multiple "tails" in this case.
On a read error it is worth trying the other
Whats the status on this, I was suprised to see something so important
just go dead ?
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
le_path since with
sendfile/sendpath hacking around there didn't seem to be much gain.
I'm even more sceptical of the header buffer stuff as while other OS's do
that as a hack to make TCP packetising work we simply fixed the root
problem with TCP_CORK
Alan
-
To unsubscribe from this list
On Tue, 12 Dec 2006 12:01:25 -0500
Bill Nottingham <[EMAIL PROTECTED]> wrote:
> Jeff Garzik ([EMAIL PROTECTED]) said:
> > It's always been the case that we remove Linux kernel code when the
> > number of users (and more importantly, developers) drops to near-nil.
>
> So, drivers/net/3c501.c?
I
On Maw, 2005-09-06 at 02:48 -0400, Daniel Phillips wrote:
> On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> > do you think it is a bit premature to dismiss something even without
> > ever seeing the code?
>
> You told me you are using a dlm for a single-node application, is there
> a
On Llu, 2005-09-05 at 12:53 -0700, Andrew Morton wrote:
> > - How are they ref counted
> > - What are the cleanup semantics
> > - How do I pass a lock between processes (AF_UNIX sockets wont work now)
> > - How do I poll on a lock coming free.
> > - What are the semantics of lock ownership
>
t;try
lock , do operation and then drop lock" the drivers using O_NDELAY are
very definitely providing trylock semantics.
I am curious why a lock manager uses open to implement its locking
semantics rather than using the locking API (POSIX locks etc) however.
Alan
-
To unsubscribe from this li
On Llu, 2005-09-05 at 02:19 -0700, Andrew Morton wrote:
> > create_lockspace()
> > release_lockspace()
> > lock()
> > unlock()
>
> Neat. I'd be inclined to make them syscalls then. I don't suppose anyone
> is likely to object if we reserve those slots.
If the locks are not file descript
he answer right.
The only thing that is important is we don't end up with each cluster fs
wanting different core VFS interfaces added.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
sa)
>
> - Relative merits of the two offerings
You missed the important one - people actively use it and have been for
some years. Same reason with have NTFS, HPFS, and all the others. On
that alone it makes sense to include.
Alan
-
To unsubscribe from this list: send the line "unsubscr
On Llu, 2005-08-08 at 09:33 -0400, Janak Desai wrote:
>
> [PATCH 1/2] unshare system call: System Call handler function sys_unshare
Given the complexity of the kernel code involved and the obscurity of
the functionality why not just do another clone() in userspace to
unshare the things you want
n' seems to be passing arguments into
> sys_quotactl() which it doesn't understand, etc.
Yep.
> So. I'd prefer to not do further ext3 quota testing until
> Linus gets an update. Alan, is it possible to push this
> along a bit?
Quota is relatively low priority. I can o
> `the class of devices in question' was cryptographic devices, and possibly
> other transactional DSPs. I don't consider audio to be transactional.
> in any case, you can do transactional things with two threads, as long
> as they each have their own fd on the device. Think of the fd as your
>
> I've already run this by Trond so I'm sending this patch without
> further ado. It adds a lock_kernel around a call into NLM code,
> and removes an extraneous (really) lock_kernel in sys_fcntl64.
[EMAIL PROTECTED] is the locking code maintainer if he's not already seen this
-
To unsubscribe f
eople, that's all.
Since HTML email also has a spec can we remove the people who moan about that
too ;)
Alan
--
"MIME, oh mime, how I hate thee. Let me stick pins in you to
count the ways..." -- Ben LaHaise
-
To unsubscribe from this list: send the line "unsu
> For _devices_, though? I don't expect my mouse to work if gpm and xfree
> both try to consume device events from the same filp. Heck, it doesn't
> even work when they try to consume events from the same inode :-) I think
> this is a reasonable restriction for the class of devices in question.
> Sure. But we have to do two syscalls only if ioctl has both in- and out-
> arguments that way. Moreover, we are talking about non-trivial in- arguments.
> How many of these are in hotspots?
There is also a second question. How do you ensure the read is for the right
data when you are sharing a
> Which, BTW, is a wonderful reason for having multiple channels. Instead
> of write(fd, "critical_command", 8); read(fd,); you read from the right fd.
> Opened before you enter the hotspot. Less overhead than ioctl() would
> have...
The ioctl is one syscall, the read/write pair are two. Im n
you see performance-critical use of
> ioctl()?
AGP, video4linux,...
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
> How about sprintf(s + strlen(s), foo)?
Solar Designer said two years ago we should be using snprintf in the kernel.
He was most decidedly right 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
ember why, and people are heard murmering 'You should have tried Linux two
years ago, you had to actually make device files yourself sometimes'
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
> Why are LVM and EVMS(competing LVM project) needed at all?
I prefer to think of it the other way around
> Surely the same can be accomplished with
> * md
> * snapshot blkdev (attached in previous e-mail)
> * giving partitions and blkdevs the ability to grow and shrink
> * giving filesystems th
> On Sun, 20 May 2001, Ingo Oeser wrote:
> > PS: English is neither mine, nor Linus native language. Why do
> >the English natives complain instead of us? ;-)
>
> Because we had some experience with, erm, localized systems and for
> Alan it's most likely
> Now that I'm awake and refreshed, yeah, that's awful. But
> echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck,
> the system can even send back result codes that way.
Only to an English speaker. I suspect Quebec City canadians would prefer a
different command set.
-
To un
efully. If you used perl as your login shell you would
have no problem there.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
You want to kunmap
the page as soon as you can. The kmap/unmap operations are fairly fast but
there is a limited pool of maps.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Umm ignore that my brain is backwards.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
> also needs to be fixed in 2.2. Basically, we are checking for an ext2
> large file, which would be a file > 2GB on systems that don't support
> such. However, we are checking for a file > 8GB which is clearly wrong.
> The ext3 version of the patch is also attached.
Umm..
x>>33
is ch
94 matches
Mail list logo
