On Wed, Feb 20, 2008 at 04:04:22PM +, Al Viro wrote:
> It's less about the form of representation (after all, we generate poll
> events when contents of that sucker changes, so one *can* get a consistent
> snapshot of the entire thing) and more about having it self-contained
> when we have name
On Fri, Jan 18, 2008 at 10:36:01AM -0500, Peter Staubach wrote:
> @@ -1025,12 +1027,27 @@ static int fastcall link_path_walk(const
> mntget(save.mnt);
>
> result = __link_path_walk(name, nd);
> - if (result == -ESTALE) {
> + while (result == -ESTALE) {
> + /*
> +
On Tue, Jan 15, 2008 at 09:48:51AM -0500, J. Bruce Fields wrote:
> On Mon, Jan 14, 2008 at 09:28:30PM -0700, Matthew Wilcox wrote:
> > interruptible_sleep_on_locked() is just an open-coded
> > wait_event_interruptible_timeout() with a few assumptions since we know
>
Reduce the spaghetti-like nature of flock_lock_file by making the chunk
of code labelled find_conflict into its own function. Also allocate
memory before taking the kernel lock in preparation for switching to a
normal spinlock.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --gi
interruptible_sleep_on_locked() is just an open-coded
wait_event_interruptible_timeout() with a few assumptions since we know
we hold the BKL. locks_block_on_timeout() is only used in one place, so
it's actually simpler to inline it into its caller.
Signed-off-by: Matthew Wilcox &l
On Mon, Jan 14, 2008 at 03:44:19PM -0500, J. Bruce Fields wrote:
> Thanks! I've queued it up for 2.6.25.
Hi Bruce,
I haven't had as much time to play with de-BKL-ising fs/locks.c as I
would like, so fixing that for 2.6.25 is probably out of the question,
but here are two janitorial patches that
On Tue, Dec 04, 2007 at 05:26:28AM +0100, Nick Piggin wrote:
> +static void copy_to_brd(struct brd_device *brd, const void *src,
> + sector_t sector, size_t n)
> +{
> + struct page *page;
> + void *dst;
> + unsigned int offset = (sector & (PAGE_SECTORS-1)) << SECTOR_
On Fri, Jan 04, 2008 at 03:53:04PM -0500, J. Bruce Fields wrote:
> So, the problem is that fcntl_setlease() does
>
> vfs_setlease()
> fasync_helper()
>
> which the bkl held over both, and you want to preserve that?
>
> But what that BKL is doing is a mystery to me--the very first thi
On Fri, Jan 04, 2008 at 02:47:18PM -0500, J. Bruce Fields wrote:
> > > Then I started to wonder about the current split of functionality between
> > > fcntl_setlease, vfs_setlease and generic_setlease. The check for no
> > > other process having this file open should be common to all filesystems.
On Fri, Jan 04, 2008 at 01:55:36PM -0500, david m. richter wrote:
> fwiw, i've done some work on extending the lease subsystem to help
> support the full range of requirements for NFSv4 file and directory
> delegations (e.g., breaking a lease when unlinking a file) and we ended up
> actual
Hi Bruce,
The current implementation of vfs_setlease/generic_setlease/etc is a
bit quirky. I've been thinking it over for the past couple of days,
and I think we need to refactor it to work sensibly.
As you may have noticed, I've been mulling over getting rid of the
BKL in fs/locks.c and the le
On Sun, Dec 30, 2007 at 01:05:10PM +, Christoph Hellwig wrote:
> If people are really having any kind of scalability problems with this
> still it should be quite trivial to make the file_lock_list and
> blocked_list aswel as the new file_lock_lock per-superblock as file
> and thus locks never
On Sun, Dec 30, 2007 at 08:36:44PM +1100, Stephen Rothwell wrote:
> We should probably do some performance testing on this because the last
> time we tried the impact was quite noticeable. You should ping Tridge as
> he has some good lock testing setups. And he cares if we slow him down :-)
Last
I've been promising to do this for about seven years now.
It seems to work well enough, but I haven't run any serious stress
tests on it. This implementation uses one spinlock to protect both lock
lists and all the i_flock chains. It doesn't seem worth splitting up
the locking any further.
I h
On Thu, Dec 06, 2007 at 10:34:26AM -0700, Matthew Wilcox wrote:
> I've done a more thorough review of Liam's work and come up with a few
> more fixes (which I'll publish later today)
I've put up a git tree for this work; see
http://git.kernel.org/?p=linux/kernel/git/w
On Mon, Nov 05, 2007 at 07:58:38AM +0300, Al Boldi wrote:
> Any ideas?
How about tcpdumping and seeing what requests are flowing across the
wire? You might be able to figure out what's being done differently.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we u
On Sun, Oct 28, 2007 at 09:38:55PM +, Alan Cox wrote:
> > It doesn't require the system to detect it, only mandate what to return
> > if it does detect it.
>
> We should be detecting at least the obvious case.
What is the obvious case? A task that has never called clone()?
> If SYSV only sp
On Sun, Oct 28, 2007 at 11:55:52PM +0100, Jiri Kosina wrote:
> On Sun, 28 Oct 2007, Matthew Wilcox wrote:
>
> > 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
On Sun, Oct 28, 2007 at 10:48:33PM +, Alan Cox wrote:
> > 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
On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote:
> > You can't fix the false EDEADLK detection without solving the halting
> > problem. Best of luck with that.
>
> I can see that it would be difficult to do efficiently, but basically,
> this boils down to finding a circular path i
On Sun, Oct 28, 2007 at 06:40:52PM +, Alan Cox wrote:
> NAK. This is an ABI change. It was also comprehensively rejected before
> because
>
> - EDEADLK behaviour is ABI
Not in any meaningful way.
> - EDEADLK behaviour is required by SuSv3
What SuSv3 actually says is:
If the system
On Sun, Oct 28, 2007 at 01:43:21PM -0400, J. Bruce Fields wrote:
> We currently attempt to return -EDEALK to blocking fcntl() file locking
> requests that would create a cycle in the graph of tasks waiting on
> locks.
>
> This is inefficient: in the general case it requires us determining
> whethe
On Fri, Oct 05, 2007 at 08:48:53AM +0200, Jens Axboe wrote:
> I'd like to second Davids emails here, this is a serious problem. Having
> a reproducible test case lowers the barrier for getting the problem
> fixed by orders of magnitude. It's the difference between the problem
> getting fixed in a d
On Tue, Oct 02, 2007 at 08:00:26PM +0200, Jan Engelhardt wrote:
> Add %S_IWUGO bit for files on ISO-9660 filesystems without RockRidge
Looks to me like you've added S_IWUSR, not S_IWUGO.
> - popt->mode = S_IRUGO | S_IXUGO; /*
> + popt->mode = S_IRUGO | S_IWUSR | S_IXUGO;
> - i
On Thu, Oct 04, 2007 at 01:55:37PM -0700, David Miller wrote:
> Anything, I do mean anything, can be simulated using small test
> programs. Pointing at a big fancy machine with lots of storage
> and disk is a passive aggressive way to avoid the real issues,
> in that nobody is putting forth the ef
On Thu, Oct 04, 2007 at 01:48:34PM -0700, David Miller wrote:
> There comes a point where it is the reporter's responsibility to help
> the developer come up with a publishable test case the developer can
> use to work on fixing the problem and help ensure it stays fixed.
That's a lot of effort.
On Thu, Oct 04, 2007 at 10:49:52AM -0700, Christoph Lameter wrote:
> I was not aware of that. Would it be possible for you to summarize all the
> test data that you have right now about SLUB vs. SLAB with the patches
> listed? Exactly what kernel version and what version of the per cpu
> patche
On Thu, Oct 04, 2007 at 10:38:15AM -0700, Christoph Lameter wrote:
> On Thu, 4 Oct 2007, Matthew Wilcox wrote:
>
> > So, on "a well-known OLTP benchmark which prohibits publishing absolute
> > numbers" and on an x86-64 system (I don't think exactly which mode
On Mon, Oct 01, 2007 at 01:50:44PM -0700, Christoph Lameter wrote:
> The problem is with the weird way of Intel testing and communication.
> Every 3-6 month or so they will tell you the system is X% up or down on
> arch Y (and they wont give you details because its somehow secret). And
> then th
On Thu, Sep 27, 2007 at 07:19:27PM -0400, Theodore Tso wrote:
> Would you accept a patch which causes the deprecated sysfs
> files/directories to disappear, even if CONFIG_SYS_DEPRECATED is
> defined, via a boot-time parameter?
How about a mount option? That way people can test without a reboot:
On Thu, Sep 27, 2007 at 02:37:42PM -0400, Theodore Tso wrote:
> I'm reminded of Rusty's 2003 OLS Keynote, where he points out that
> what's important is not making an interface easy to use, but _hard_
> _to_ _misuse_. That fact that sysfs is all laid out in a directory,
> but for which some direct
On Mon, Sep 24, 2007 at 03:06:06PM +0200, Miklos Szeredi wrote:
> A file isn't deleted while there are still links or open files
> refering to it. So getting the attributes for a file with nlink==0 is
> perfectly valid while the file is still open.
Is it? Why not just pretend that the attributes
On Mon, Sep 24, 2007 at 02:48:08PM +0200, Miklos Szeredi wrote:
> > and if that means adding silly rename support so be it.
>
> That's what is done currently.
>
> But it's has various dawbacks, like rmdir doesn't work if there are
> open files within an otherwise empty directory.
>
> I'd happily
On Mon, Aug 20, 2007 at 04:22:04PM +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Mon, 2007-08-20 at 09:18 -0400, Chris Snook wrote:
>
> > > How's about we just remove that printk? Do
> > >
> > > #define J_ASSERT(e) BUG_ON(e)?
ITYM #define J_ASSERT(e) BUG_ON(!e)
> It did. The original J_ASSER
On Mon, Jul 16, 2007 at 09:28:08PM +0300, Al Boldi wrote:
> Well, conceptually it sounds like a piece of cake, technically your guess is
> as good as mine. IIRC, akpm once mentioned something like this.
How much have you looked at the VFS? There's nothing journalling-related
in the VFS right no
On Mon, Jul 16, 2007 at 08:40:00PM +0300, Al Boldi wrote:
> XFS surely rocks, but it's missing one critical component: data=ordered
> And that's one component that's just too critical to overlook for an
> enterprise environment that is built on data-integrity over performance.
>
> So that's the s
On Thu, Jul 05, 2007 at 11:30:20PM +0200, Karel Zak wrote:
> > > > The package build system is now based on autotools. The build system
> > > > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > > > SUID_LDFLAGS). For more details see the README file
> > >
> > > And this i
On Tue, Jun 19, 2007 at 04:34:42PM -0400, John Stoffel wrote:
> > "Jack" == Jack Stone <[EMAIL PROTECTED]> writes:
>
> Jack> The whole idea of the file system is that it wouldn't return the
> Jack> file in the file listing. The user would have to know that the
> Jack> file system was versionin
On Mon, Jun 04, 2007 at 09:56:07AM -0700, Bryan Henderson wrote:
> Programs that assume a full transfer are fairly common, but are
> universally regarded as either broken or just lazy, and when it does cause
> a problem, it is far more common to fix the application than the kernel.
Linus has exp
On Fri, Jun 01, 2007 at 12:44:16PM -0400, J. Bruce Fields wrote:
> The only problem I'm aware of is that leases aren't broken on rename,
> link, and unlink. This is kind of tricky to fix. David Richter (cc'd)
> and I sketched out a few different approaches, and I think he has some
> patches imple
On Mon, Apr 16, 2007 at 06:11:30PM +0200, Andreas Gruenbacher wrote:
> +static inline int
> +nfsd_do_create(struct inode *dir, struct dentry *child, struct vfsmount *mnt,
> +int mode)
> +{
> + struct nameidata nd = {
> + .dentry = child,
> + .mnt = mnt,
> +
On Sun, Apr 08, 2007 at 09:16:59PM -0700, [EMAIL PROTECTED] wrote:
> REISER4 FOR INCLUSION IN THE LINUX KERNEL.
Fuck off. Cheerleading like this only hurts your cause.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More maj
On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote:
> the problem with the people who say they want forced umount is.. that
> most of the time they either want
> 1) get rid of the namespace entry
> or
> 2) want to stop any and all IO to a certain device/partition
There is a third co
On Fri, Mar 16, 2007 at 05:17:04PM +0100, Heiko Carstens wrote:
> > +asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
>
> e.g.
>
> asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len, int mode)
>
> would work even on s390 ;)
How about:
asmlinkage long sys_
On Sat, Mar 17, 2007 at 08:59:05PM +1100, Paul Mackerras wrote:
> ... but wouldn't work on 32-bit powerpc. :( We would end up with a
> pad argument between fd and offset, giving 7 arguments in all
> (counting the loff_t's as 2), but we only support 6.
Ditto mips and parisc.
-
To unsubscribe from
On Tue, Mar 06, 2007 at 06:43:34PM +0100, Roel Bindels wrote:
> Ok, but don't you guys have some fact I can build a case with?? I don't
> think that my college's will take me serious if I come with this store,
> even it is true ;)
You are crossposting far too widely to some wildly inappropriate li
On Thu, Feb 08, 2007 at 11:48:16AM -0500, John Muir wrote:
> The attached test program creates a file, and then some hard links to
> that file (file0 - fileN).
> The test program then attempts to rename(fileN, file) for every hard
> link created.
>
> My expectation is that the hard links file0 - f
On Wed, Jan 10, 2007 at 09:38:11AM -0800, Bryan Henderson wrote:
> >Other people are of the opinion that the invention of the symbolic link
> >was a huge mistake.
>
> I guess I haven't heard that one. What is the argument that we were
> better off without symbolic links?
I suppose http://www.cs
On Tue, Jan 09, 2007 at 03:43:14PM -0800, Bryan Henderson wrote:
> >but you can get a large number of >1 linked
> >files, when you copy full directories with "cp -rl". Which I do a lot
> >when developing. I've done that a few times with the Linux tree.
>
> Can you shed some light on how you use t
On Sat, Jan 06, 2007 at 10:58:31PM +0300, Alexey Dobriyan wrote:
> Nor me nor my box is going to act as NFS server, so ifdef all
> exporting code.
> @@ -916,7 +918,9 @@ static int ext2_fill_super(struct super_
>* set up enough so that it can read an inode
>*/
> sb->s_op = &ex
On Fri, Jan 05, 2007 at 02:10:06PM -0500, Erez Zadok wrote:
> Ah, ok. So why not put an ASSERT in there, or at least a comment, to make
> the code clearer. As it stands, anyone looking at the code in the future
> can easily rediscover this "bug" that dereferences a null ptr.
Because anyone pokin
On Fri, Jan 05, 2007 at 12:11:17PM -0500, Shaya Potter wrote:
> I guess the question is, why shouldn't a dentry object know what
> vfsmount it belongs to is? Can it belong to multiple vfsmount objects?
> (Again, probably showing my igornance here).
If you have the same tree mounted in two places,
On Wed, Jan 03, 2007 at 01:33:31PM +0100, Miklos Szeredi wrote:
> High probability is all you have. Cosmic radiation hitting your
> computer will more likly cause problems, than colliding 64bit inode
> numbers ;)
Some of us have machines designed to cope with cosmic rays, and would be
unimpressed
On Wed, Dec 20, 2006 at 01:26:56PM +0100, Sergio Paracuellos wrote:
> I am trying to compile a module for kernel 2.6.18-1 that uses the 'inode
> struct' but the compiler tell me inode struct hasn't a member called
> "i_blksize". I don't have that problem in kernel 2.6.16. What happend
> with i_blks
On Sun, Dec 17, 2006 at 11:07:27AM -0800, Ulrich Drepper wrote:
> And how often do the scripts which are in everyday use require such a
> command? And the same for the other programs.
I know that the rsync load is a major factor on kernel.org right now.
With all the git trees (particularly the o
On Thu, Dec 14, 2006 at 03:00:41PM -0600, Rob Ross wrote:
> I don't think that I understand what you're saying here. The openg()
> call does not perform file open (not that that is necessarily even a
> first-class FS operation), it simply does the lookup.
>
> When we were naming these calls, fro
On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote:
> Considering that filesystems like GFS and OCFS allow clients DIRECT
> ACCESS to the block device itself (which no amount of authentication
> will fix, unless it is in the disks themselves), the risk of passing a
> file handle around
On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote:
> Permission checks are done on the path_to_handle(), so in reality
> only root or CAP_SYS_ADMIN users can currently use the
> open_by_handle interface because of this lack of checking. Given
> that our current users of this interface n
On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
> David Chinner wrote:
> >Does anyone here know about the XFS libhandle API? This has been
> >around for years and it does _exactly_ what these proposed syscalls
> >are supposed to do (and more).
>
> Thanks for pointing these out Dave. Thes
On Wed, Dec 06, 2006 at 09:04:00AM -0600, Rob Ross wrote:
> The openg() solution has the following advantages to what you propose.
> First, it places the burden of the communication of the file handle on
> the application process, not the file system. That means less work for
> the file system.
On Tue, Dec 05, 2006 at 06:09:03PM +0100, Latchesar Ionkov wrote:
> It could be wasteful, but it could (most likely) also be useful. Name
> resolution is not that expensive on either side of the network. The
> latency introduced by the single-name lookups is :)
*is* latency the problem here? Last
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
> I think that the main problem is that all these file systems resove a
> path name, one directory at a time bringing the server to its knees by
> the huge amount of requests. I would like to see what the performance
> is if you a) c
On Tue, Dec 05, 2006 at 10:07:48AM +, Christoph Hellwig wrote:
> The filehandle idiocy on the other hand is way of into crackpipe land.
Right, and it needs to be discarded. Of course, there was a real
problem that it addressed, so we need to come up with an acceptable
alternative.
The scenar
On Wed, Nov 29, 2006 at 05:23:13AM -0700, Matthew Wilcox wrote:
> On Wed, Nov 29, 2006 at 09:04:50AM +, Christoph Hellwig wrote:
> > - openg/sutoc
> >
> > No way. We already have a very nice file descriptor abstraction.
> > You can pass file descriptors
On Wed, Nov 29, 2006 at 09:04:50AM +, Christoph Hellwig wrote:
> - openg/sutoc
>
> No way. We already have a very nice file descriptor abstraction.
> You can pass file descriptors over unix sockets just fine.
Yes, but it behaves like dup(). Gary replied to me off-list (which I
On Mon, Nov 27, 2006 at 09:34:05PM -0700, Gary Grider wrote:
> >Things like
> >openg() - on process opens a file and gets a key that is passed to
> >lots of processes which
> >use the key to get a handle (great for thousands of processes opening a
> >file)
I don't understand how this leads to a
On Fri, Nov 17, 2006 at 08:43:00AM -0500, Jeff Layton wrote:
> 2) this scheme would effectively leak inode addresses into userspace.
> I'm not sure if that would be exploitable, but it's probably best not to
> do it. The patch adds a static unsigned int that is initialized to a
> random value at bo
On Fri, Nov 17, 2006 at 08:43:00AM -0500, Jeff Layton wrote:
> +/* convert an inode address into an unsigned int and xor it with a random
> value
> + * determined at boot time */
> +static inline unsigned int inode_to_uint (struct inode *inode)
> +{
> + return unsigned long) (inode - (stru
On Thu, Nov 16, 2006 at 10:21:32PM +0100, Majkls wrote:
> Hello,
> I would like to solve this bug. Have anybody some backtrace or some
> working exploit?
Sure you have the right CVE? That bug seems to have been fixed long
ago:
http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=2ccb48ebb4de1
journal_commit_transaction() is still 650+ lines long and contains 16
local variables. By moving phase 3 into its own function, we reduce
its length by 150+ lines and reduce it to 5 local variables.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
commit.c
On Fri, Aug 19, 2005 at 08:38:34PM +0100, Al Viro wrote:
> FWIW, I'd rather take page_symlink(), page_symlink_inode_operations,
> page_put_link(), page_follow_link_light(), page_readlink(), page_getlink(),
> generic_readlink() and vfs_readlink() to the same place where these guys
> would live. The
On Fri, Apr 15, 2005 at 10:03:05PM +1000, Herbert Xu wrote:
> I suppose it could be smart and stay quiet about
>
> val < 0 || val > BOUND
>
> However, gcc is slow enough as it is without adding unnecessary
> smarts like this.
It only warns with -W on, not with -Wall, so I see no compelling
reaso
On Fri, Apr 15, 2005 at 09:21:50AM +0100, Christoph Hellwig wrote:
> On Fri, Apr 15, 2005 at 02:31:00AM +0100, Matthew Wilcox wrote:
> > On Fri, Apr 15, 2005 at 03:07:42AM +0200, Jesper Juhl wrote:
> > > 'arg' is unsigned so it can never be less than zero, so testing
On Fri, Apr 15, 2005 at 03:07:42AM +0200, Jesper Juhl wrote:
> 'arg' is unsigned so it can never be less than zero, so testing for that
> is pointless and also generates a warning when building with gcc -W. This
> patch eliminates the pointless check.
Didn't Linus already reject this one 6 month
On Mon, Mar 21, 2005 at 01:33:55PM -0800, Bryan Henderson wrote:
> It looks to me like you're running into the fundamental limitation that
> the CPU doesn't notify Linux every time you store into a memory location.
> It does, though, set the dirty flag in the page table, and Linux
> eventually i
This problem came up with the systemimager program which uses rsync to
install files from a master server to many clients. Red Hat has a system
user with uid 2^32-1 which causes lastlog to grow to 1.2GB in size.
rsync does understand the concept of sparse files (with the -S flag), but
it has to r
On Fri, Feb 04, 2005 at 03:58:04PM +0530, Anirban Mukherjee wrote:
> I am doing a project on Ext2fs and Ext3fs and I require some materials on
> the physical structure of Ext2fs.It would be very helpful if someone sends
> me some information(or links where to find it) along with some general
> stuf
Got this report about 2.6.11-rc3. Is this the correct solution?
- Forwarded message from Joel Soete <[EMAIL PROTECTED]> -
A short analyse, it seems that's because NFSD was builtin while EXPORTFS
was a module in my previous config file. Imho EXPORTFS would be build as
NFSD?
Is the follo
On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
I think the below loop would be clearer as a for loop ...
err = 0;
for (nr = 0; nr < nr_pages; nr++, start++) {
if (start == lp_idx) {
pages[nr] = locked_page;
On Fri, Jan 28, 2005 at 02:53:41PM -0800, Bryan Henderson wrote:
> >Just putting up my hand to say "yeah, us too" - we could also make
> >use of that functionality, so we can grok existing XFS filesystems
> >that have blocksizes larger than the page size.
>
> IBM Storage Tank has block size > page
Port Andreas Dilger's and Jan Kara's patch for ext3 to ext2.
Also some whitespace changes to get ext2/ext3 closer in sync.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Index: fs/ext2/balloc.c
===
RCS file: /v
On Thu, Jan 13, 2005 at 01:15:06PM +0100, Jan Kara wrote:
> Attached patch removes unnecessary division and modulo from ext3 code
> paths. It reduces (according to oprofile) the CPU usage measurably under
> a dbench load (see description of the patch for the numbers).
I thought I'd apply Jan & A
On Fri, Jun 15, 2001 at 01:10:00AM -0400, Alexander Viro wrote:
> +static inline void write_super(struct super_block *sb)
> +{
> + lock_super(sb);
> + if (sb->s_root && sb->s_dirt)
When I first looked at this, I thought it was a typo. I don't think we
On Fri, Jun 08, 2001 at 02:04:16PM -0400, Alexander Viro wrote:
> the only
> areas in VFS that still rely on BKL are locks.c, dquot.c and super.c. The
> latter is fixed in the patches I'm feeding to Linus (OK, the pieces I'm
> feeding to Linus make shifting the BKL down to method calls trivial). O
On Tue, May 22, 2001 at 04:31:37PM +0100, Alan Cox wrote:
> > `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
On Tue, May 22, 2001 at 08:49:04AM +0100, Alan Cox wrote:
> > 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
On Tue, May 22, 2001 at 02:22:34AM +0200, Ingo Oeser wrote:
> ioctl has actually 4 semantics:
>
> command only
> command + read
> command + write
> command + rw-transaction
>
> Separating these would be a first step. And yes, I consider each
> of them useful.
>
> command only: reset drive
echo
On Mon, May 21, 2001 at 06:13:18PM -0700, Linus Torvalds wrote:
> Nope. You can (and people do, quite often) share filps. So you can't
> associate state with it.
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, i
On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
> Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
No.
$ ls -l arch/*/kernel/ioctl32*.c
-rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c
-rw-r--r--1 willywilly 109475 M
On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
> The transaction(2) syscall can be just as easily abused as ioctl(2) in
> this respect.
But read() and write() cannot.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe lin
On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
> Al, if you really want to kill ioctl(2), then perhaps you should
> implement a transaction(2) syscall. Something like:
> int transaction (int fd, void *rbuf, size_t rlen,
>void *wbuf, size_t wlen);
>
> Of cou
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
> clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
> unopened descriptors. I.e. no IO until you open it (turning the thing into
> opened one), but we can do lookups (move to child), we can clone and
> kill them an
On Sat, May 19, 2001 at 05:25:22PM +0100, Alan Cox wrote:
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different command set.
Should we support `pas387' as well as `no387' as a kernel boot parameter
then? Face it, a sysadmin has to know the limited subset of eng
nyway, here's the test program (I checked what was going on via
/proc/locks, you can too).
/* lock-test.c Copyright (c) Matthew Wilcox, Hewlett-Packard. GPL License */
#define _GNU_SOURCE
#include
#include
#include
#define F_SETLK_NP 15
int main(int argc, char **argv) {
struct fl
On Fri, May 04, 2001 at 09:35:33AM -0700, Peter J. Braam wrote:
> For cluster and distributed file systems we actually need a somewhat
> different approach to locking. The best thing to have would be for the FS
> to know that a lock will be needed and for what operation at lookup time.
For locki
On Fri, May 04, 2001 at 01:33:44PM +0200, Trond Myklebust wrote:
> ??? It'll be a completely useless form of lock if programs can end up
> blocking forever on a set of (from their perspective) valid
> operations.
Umm.. that's your opinion. I don't see how `making them mandatory' would
make this
On Thu, May 03, 2001 at 02:10:48PM +0200, Trond Myklebust wrote:
> >>>>> " " == Matthew Wilcox <[EMAIL PROTECTED]> writes:
>
> > I'll get to it this weekend then. Should be a relatively
> > simple patch. Are there any other se
On Thu, May 03, 2001 at 01:28:33PM +0200, Andi Kleen wrote:
> Just don't forget to add a per user ulimit for it and probably an admin
> tool like ipcs.
It'll use the same limit as the other locks do.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line
On Thu, May 03, 2001 at 12:19:31AM -0700, Jeremy Allison wrote:
> > I want to add another byte-range lock, which looks and smells like a
> > POSIX fcntl lock except that it is not removed by closing any fd which
> > happens to be open on this file.
>
> If you do this I'll be eternally in your deb
On Wed, May 02, 2001 at 04:49:30PM +0200, Andi Kleen wrote:
> On Mon, Apr 30, 2001 at 12:39:23PM -0600, Matthew Wilcox wrote:
> > * All filesystems will fill in their ->lock method.
>
> Why when a common stub should work for 90% of them? Please keep
> global search-a
1 - 100 of 127 matches
Mail list logo
