> > Is there any reason they couldn't just be merged to mainline?
> >
> > I think it's a useful facility.
>
> ummm, now why did we made that decision... I think we decided that
> it's the sort of thing which one person can run once per few months
> and that will deliver its full value. I can mai
I think you may be misinterpreting the word "poor" here.
Many people in this thread consider a security solution "poor" because it's
not "complete" or "perfect": it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to b
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; [EMAIL PRO
> It's not about default (for which backward compatibility is most
> important and this patch is perfectly fine), but user explicitly asks
> for "sharecache". In this case if for any reason the cache cannot be
> shared, I am not sure if he should get an error back.
>
> I for one agree with Ian and
> On Fri, 2007-08-31 at 11:47 -0700, Hua Zhong wrote:
> > This patch fixes the problem for me, thanks.
> >
> > Is this patch changing the behavior of "sharecache" to
> > "try-to-share-cache-if-possible", or adding a third behavior? If the
> >
This patch fixes the problem for me, thanks.
Is this patch changing the behavior of "sharecache" to
"try-to-share-cache-if-possible", or adding a third behavior? If the user
explicitly asks for "-o sharecache", does he get an error back if the mount
options mismatch?
> The best I can do given th
Trond,
> So you are saying that it is acceptable for the kernel to decide
> unilaterally to override mount options? Why aren't we doing that for
> any other filesystem than NFS?
I think there are two reasons.
First, I have no problem with the new behavior if it didn't cause a
regression. I am no
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > No. Solaris defaults to breaking cache consistency.
>
> If so, and since that's obviously what people _expect_ to happen, why
> not make that the default, with the "consistent" behaviour being the
> one that needs an explicit option.
>
> Just
Hi Linus,
> Hua - that said, I don't actually see why the commit you bisected to
> has anything to do with the issue being discussed. Can you double-check
> that it's literally that particular commit that breaks for you (you could
> try just reverting that commit).
I will double check that tomorr
> How is the NFS client to know that these directories are disjoint, or
> that no-one will ever create a hard link from one directory to another?
> To my knowledge, the only way to ensure this is to put them on
> different disk partitions.
>
> I don't know if all Unix systems have this issue, but
> On Thu, 2007-08-30 at 15:47 -0700, Hua Zhong wrote:
> > >
> > > Which is better than having it fail silently, or giving you a mount
> > > with the wrong mount options.
> >
> > Well, it depends on how you define "better".
>
> "be
Hi Trond,
> On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > I am re-sending this after help from Ian and git-bisect. To me it's a
> > show-stopper: I cannot find an acceptable workaround that I can
> > implement. The problem: upgrading to 2.6.23-rc4 from 2.6.22
OTECTED]>
:04 04 675c84bd8b2c50744018becaa0db4aeca19b8f9f
105fbd3cb3fa5e3019836b4b5268125d0181a72d M fs
:04 04 0138796e0806b4ebd1cc3850ed4e8c7ab24d2d41
2fec08debe51c20423a88b1a0d4281c683ba5daf M include
-Original Message-
From: Hua Zhong [mailto:[EMAIL PROTECTED]
Sent: Wednes
ocent. It's
something else.
It will still take me about 10 reboots to bisect. If anyone has a patch for
me to try, I'll give it a shot tomorrow.
> -Original Message-
> From: Ian Kent [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 29, 2007 8:00 PM
> To: Hua Zhong
Hi,
I am wondering if this is a known issue, but I just built the current git
and several autofs mounts mysteriously disappeared. Restarting autofs could
fix some, but then lose others. 2.6.22 was fine.
Is there anything I could check other than bisect? (It may take some time
for me to get to it)
> > And, from a standpoint of ONGOING, long-term innovation: what matters
> > is that brilliant, new ideas get rewarded one way or another.
>
> and in this case, the reward is that the idea got used and credit was
> given
You mean, when Ingo announced CFS he mentioned Con's name?
I really do
> Did Ingo have the obligation to improve Con's work? Definitely not.
> Did Con have a right to get Ingo's improvements or
> suggestions? Definitely not.
Yes, and that's where the inequality is.
Unless the maintainer does a really bad job or pisses off Linus,
anyone who wants to merge his code in
The idea has not died and some NAS/file server vendors have already been
doing this for some time. (I am not sure but is WAFS the same thing?)
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Linus Torvalds
> Sent: Friday, April 27, 2007
> In STR, 3W is quite realistic. The CPU is off, all (or most - up to you)
> the devices are off, but the motherboard and memory is powered.
>
> > And even 3W would still be a waste of energy.
>
> .. but if the alternative is a feature that just isn't worth it, and
> likely to not only have its o
> This whole notion that "kernel lines of code" is somehow different is a
> stupid and idiotic _disease_ that is spread by microkernel people and
> people who have been brainwashed by them.
I think a lot of people are tired of this argument, but I am glad you speak
up (as you did last year wrt s2r
> The other problem besides the inability to handle IO errors is that
> mmap()+msync() is synchronous. You need to go async to keep
> the pipelines full.
msync(addr, len, MS_ASYNC); doesn't do what you want?
> Now if someone wants to implement an aio version of msync and
> mlock, that might do
> > Here is a simple patch that does it.
>
> Looks more likely to work than Ken's - which I didn't try,
> but I couldn't see what magic prevented it from just going BUG.
>
> But I have to say, having seen the ensuing requests for this
> to impose the same constraints as other implementations of
flag so we could check O_DIRECT
support at a much earlier stage. Comments on how to fix it?
Signed-off-by: Hua Zhong <[EMAIL PROTECTED]>
diff --git a/fs/open.c b/fs/open.c
index c989fb4..c03285f 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -708,11 +708,13 @@ static struct file *__dentry_open(
> --- Hua Zhong <[EMAIL PROTECTED]> wrote:
>
> > > Any strong reason why not? x has some value that does not
> > > make sense and can create only problems.
> >
> > By the same logic, you should memset the buffer to zero
> before freeing it too.
> Any strong reason why not? x has some value that does not
> make sense and can create only problems.
By the same logic, you should memset the buffer to zero before freeing it too.
> And as I explained, it can result in longer code too. So, why
> keep this value around. Why not re-initialize i
> I see that as a good argument _not_ to allow O_DIRECT on
> tmpfs, which inevitably impacts cache, even if O_DIRECT were
> requested.
>
> But I'd also expect any app requesting O_DIRECT in that way,
> as a caring citizen, to fall back to going without O_DIRECT
> when it's not supported.
Acco
I am wondering if we should define __likely/__unlikely macros no matter whether
CONFIG_LIKELY_PROFILE is defined, like the following. This way people can always
use the raw macros in case the debugging version causes problems.
Signed-off-by: Hua Zhong <[EMAIL PROTECTED]>
--- linux-2.6/i
I'd suggest putting a Documentation/GPL-Symbols to explain this.
Then in the "tainted" message, have a pointer to that documentation.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Preece
> Sent: Thursday, December 14, 2006 11:43 AM
> To: C
> I think allowing binary hardware drivers in userspace hurts
> our ability to leverage companies to release hardware specs.
If filesystems can be in user space, why can't drivers be in user space? On
what *technical* ground?
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
> On Thu, Nov 30, 2006 at 10:00:35PM -0800, Hua Zhong wrote:
>
> > I am curious, what's the point?
>
> Email addresses are for contacting people.
Do you go back and change all the signed-off lines too when people change jobs?
> > These email addresses serve a &q
I am curious, what's the point?
These email addresses serve a "historical" purpose: they tell when the
contribution was made, what the author's email addresses
were at that point.
It's not MAINTAINERS. If people want to contact someone, go find the latest
address there.
> -Original Messag
>takelock domainxxx lock1
>do sutff
>droplock domainxxx lock1
>
> When someone kills the shell, the lock is leaked, becuase droplock isn't
> called.
Why not open the lock resource (or the lock space) instead of
individual locks as file? It then looks like this:
open lock
I just started looking at gfs. To understand it you'd need to look at it
from the entire cluster solution point of view.
This is a good document from David. It's not about GFS in particular but
about the architecture of the cluster.
http://people.redhat.com/~teigland/sca.pdf
Hua
> -Origina
> Even with a GPL'd Linux Bitkeeper I'll bet half of the existing Linux
> paying customers will continue to use a paid version.
By what? How much do you plan to put down to pay Larry in case you lose your
bet?
Hua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
> int bt_sock_unregister(int proto)
> {
> - if (proto >= BT_MAX_PROTO)
> + if (proto < 0 || proto >= BT_MAX_PROTO)
> return -EINVAL;
Just curious: would it be better to say
if ((unsigned int)proto >= BT_MAX_PTORO)
?
Is it faster too?
Hua
-
To unsubscribe from this list
> -fixup or -fixes maybe. x.y is OK too. :)
How about Service Pack?
:joke:
I could never understand why we have confused users in the naming in 2.6
serials and are trying to confuse them even more..
Hua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
> You cannot have it both ways. Either the kernel needs
> testers, or it is "stable". See how these are opposites?
I think one of the fundamental problems is "either the kernel needs more
features, or it needs stablization". You cannot have it both ways. With the
current model, the kernel deve
> In other words, I'm really talking about something different
> from what you seem to envision.
Indeed. What I have in mind (and suggested in the past) is that we have a
real 2.6 stable release maintainer. The only difference is that he starts
from a random 2.6.x release he picks, and releases
> it's a no-brainer.
Alan Cox once said he would like to do it:
> On Mer, 2004-10-27 at 19:37, Hua Zhong wrote:
> When I said "nobody", I really meant "top kernel developers". I have
not
> seen anyone step up and say "I'll volunteer to maintain
> And the reason it does _not_ work is that all the people we
> want testing sure as _hell_ won't be testing -rc versions.
At least they still test "real" releases..
So instead of making sure rc is really "release-candidate", we want to trick
people to test -pre as "real release", soon people wi
> I actually second Matt's request; -RCs à la 2.4.
>
> Then your above becomes:
> 2.6.x-rc: bugfixes only
> 2.6.x-pre: bugfixes and features
>
> And then that doesn't confuse end users either.
I'll jump in and third this. It looks the "honest" way. I know Linus is
always talking about "open sour
> Linus has never worked on Unix in any form, and most of the
> other kernel hackers hasn't either. Ever.
Huh? I believe they have used Unix, as in the BitKeeper case. In neither
case they get access to the source code of the software they use, to make
the comparison equal.
Whether they used a *
-> From Alan Cox <[EMAIL PROTECTED]> :
> > (a) It does less, namely will not kill processes with uid 0.
> > Ted, any objections?
>
> That breaks the security guarantee. Suppose I use a setuid app to confuse
> you into doing something ?
a setuid app only changes euid, doesn't it?
-
To unsubsc
-> From "H. Peter Anvin" <[EMAIL PROTECTED]> :
> When I got Pac*Smell DSL, the installer guy (who seemed to be a
> relatively clueful type) said "and [the contract] says you're not
> allowed to run a server... but who'd know?"
..and please define "server". Does it mean that you can not run any p
-> From Kurt Maxwell Weber <[EMAIL PROTECTED]> :
>
> You can choose to work somewhere else, or choose to enter a different field.
There are a lot of people who don't know how to use Linux/Unix. Windows is
much easier for them and has more applications. They practically have no
other choice i
Is Graphics really in the Windows kernel? I think GDI.EXE runs in user mode.
> >Olaf Hering wrote:
> >> kde.o. 2.5?
> >
> >Good idea! Graphics needs to be in the kernel to be fast. Windows
> >proved that.
>
> thought SGI proved that :-)
>
> Martin
> --
>
Is this (printing out versions. etc) really a big deal so we should add stuff
like "/proc/xxx", KERN_ to make things more complicated? It sounds to me
like to make the kernel "smaller" we'd actually end up with adding more code
and complexity to it. And quite frankly, if people don't rea
> Do linux even support the sticky bit (t) I can't see a reason to use it, why would I
>want the file to be stored in the swap ??
For files I think it was used in days when there was no VM, so that you could
hint the system to put frequently used executables always in memory (like vi,
sh, et
> So really you want an outside GUI tool that lets you reconfigure build and
> install kernels. Yeah I'd agree with that. Someone just needs to write the
> killer gnome/kde config tool. I've got C code for parsing/loading config.in
> files and deducing the dependancy constraints if anyone ever wa
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
> Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
>
Hua Zhong
C
t;x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
>
Hua Zhong
Central Research Facilities Department of Computer Sc
All comments/praise/criticism are welcome. Thanks.
--------
Hua Zhong
Central Research Facilities Department of Computer Science
Columbia University New York, NY 10027
Email: [EMAIL PROTECTED] ht
52 matches
Mail list logo