RE: [RFC PATCH 0/8]: uninline & uninline
> > 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 maintain it in -mm and > we're happy - no need to add it to mainline. No strong feelings > either way really. Apparently nobody has been doing it for a while. :-) Last time I did it it was around the submission time and I actually patched it into mainline kernel to do so. Not particularly hard to do, but sitting in mm-only does make it a bit harder, and there are the vdso problem you just mentioned that one has to fix for himself if it exists in mainline. > It does have the downside that the kernel explodes if someone adds > unlikely or likely to the vdso code and I need to occasionally hunt > down new additions and revert them in that patch. That makes it a > bit of a maintenance burden. Is it possible to catch this automatically, like, by re-defining likely/unlikely to the raw form in specific file(s)? Hua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 0/8]: uninline uninline
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 maintain it in -mm and we're happy - no need to add it to mainline. No strong feelings either way really. Apparently nobody has been doing it for a while. :-) Last time I did it it was around the submission time and I actually patched it into mainline kernel to do so. Not particularly hard to do, but sitting in mm-only does make it a bit harder, and there are the vdso problem you just mentioned that one has to fix for himself if it exists in mainline. It does have the downside that the kernel explodes if someone adds unlikely or likely to the vdso code and I need to occasionally hunt down new additions and revert them in that patch. That makes it a bit of a maintenance burden. Is it possible to catch this automatically, like, by re-defining likely/unlikely to the raw form in specific file(s)? Hua -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux Security *Module* Framework (Was: LSM conversion to static interface)
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 be used, or XYZ may be too expensive to be worth implementing, or they just are rare enough to be ignored. Heck, all security solutions could be broke given physical access. Implementing a security solution has a cost. Bypassing it also has a cost. Sometimes it's economy, not technique, decides whether a particular security solution is a good one. Locks are a good example for this. It has a low cost/effect ratio, and very easy to use. Is it 100% safe? Definitely not. People lock their bikes to a tree when they enter a supermarket because it's reasonably safe. But leaving their bikes like that over a few nights on a downtown street? Probably not a good idea. Don't assume all people are idiots who do not know that (ok, some people are, so the lock's manual states "it can be bypassed by a skilled thief"). But what tapes are good for? I don't know what kind of value it adds to the discussion. > -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 PROTECTED]; > Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia; > Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi > Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to > static interface) > > Hi! > > > > > The idea that poor security is worse than no security is > fallacious, > > > > and not backed up by common experience. > > > > > > There is a ton of evidence both in computing and outside of it > which > > > shows that poor security can be very much worse than no security at > all. > > > > (So, I take it that you *don't* lock your bike up, as poor security > is > > worse than none?) > > I do lock my bike with combination lock I found somewhere and cracked > in five minutes... sometimes. > > But do you suggest that I use paper tape to 'lock' my bike to > streetlight? You just said that poor security is better than none, > right? > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux Security *Module* Framework (Was: LSM conversion to static interface)
> -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 PROTECTED]; > Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia; > Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi > Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to > static interface) > > Hi! > > > > > The idea that poor security is worse than no security is > fallacious, > > > > and not backed up by common experience. > > > > > > There is a ton of evidence both in computing and outside of it > which > > > shows that poor security can be very much worse than no security at > all. > > > > (So, I take it that you *don't* lock your bike up, as poor security > is > > worse than none?) > > I do lock my bike with combination lock I found somewhere and cracked > in five minutes... sometimes. > > But do you suggest that I use paper tape to 'lock' my bike to > streetlight? You just said that poor security is better than none, > right? > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux Security *Module* Framework (Was: LSM conversion to static interface)
-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 PROTECTED]; Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia; Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static interface) Hi! The idea that poor security is worse than no security is fallacious, and not backed up by common experience. There is a ton of evidence both in computing and outside of it which shows that poor security can be very much worse than no security at all. (So, I take it that you *don't* lock your bike up, as poor security is worse than none?) I do lock my bike with combination lock I found somewhere and cracked in five minutes... sometimes. But do you suggest that I use paper tape to 'lock' my bike to streetlight? You just said that poor security is better than none, right? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux Security *Module* Framework (Was: LSM conversion to static interface)
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 be used, or XYZ may be too expensive to be worth implementing, or they just are rare enough to be ignored. Heck, all security solutions could be broke given physical access. Implementing a security solution has a cost. Bypassing it also has a cost. Sometimes it's economy, not technique, decides whether a particular security solution is a good one. Locks are a good example for this. It has a low cost/effect ratio, and very easy to use. Is it 100% safe? Definitely not. People lock their bikes to a tree when they enter a supermarket because it's reasonably safe. But leaving their bikes like that over a few nights on a downtown street? Probably not a good idea. Don't assume all people are idiots who do not know that (ok, some people are, so the lock's manual states it can be bypassed by a skilled thief). But what tapes are good for? I don't know what kind of value it adds to the discussion. -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 PROTECTED]; Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia; Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static interface) Hi! The idea that poor security is worse than no security is fallacious, and not backed up by common experience. There is a ton of evidence both in computing and outside of it which shows that poor security can be very much worse than no security at all. (So, I take it that you *don't* lock your bike up, as poor security is worse than none?) I do lock my bike with combination lock I found somewhere and cracked in five minutes... sometimes. But do you suggest that I use paper tape to 'lock' my bike to streetlight? You just said that poor security is better than none, right? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
> 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 Linus that changing default to > nosharecache might be the best thing to do, but since I am now able to > use the latest kernel, I am very happy already. Actually, I think just fine-tuning it a bit may be better: 1. make 'nosharecache' as default 2. apply the algorithm in this patch to 'nosharecache': if the fsid and mount options are the same, then share cache This way the default behavior does not change, but both algorithms have pitfalls, and we choose from: 1. if user specifies "sharecache", he may end up with nosharecache if mount options are different And 2. if user specifies "nosharecache", he may end up with sharecache if mount options are the same I'd think 2 is better (least surprise). I cannot think of a case where 2 is actually a bad thing. Comments? > Thanks a lot for your attention to my problem. :-) > > > Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
> 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 > > user explicitly asks for "-o sharecache", does he get an error back > > if the mount options mismatch? > > There has never been a 'sharecache' flag as far as the kernel is > concerned. The default behaviour has always been to share. 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 Linus that changing default to nosharecache might be the best thing to do, but since I am now able to use the latest kernel, I am very happy already. Thanks a lot for your attention to my problem. :-) > Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 the constraints appears to be to have the > kernel first look for a superblock that matches both the fsid and the > user-specified mount options, and then spawn off a new superblock if > that search fails. The attached patch does just that. > > Note that this is not the same as specifying nosharecache everywhere > since nosharecache will never attempt to match an existing superblock. > > Finally, for the record: I still feel very uncomfortable about not > being able to report the state of the client setup back to the sysadmin. > AFAIK, the only way to do so is to stat the mountpoints, and compare > the device ids. > > Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 the constraints appears to be to have the kernel first look for a superblock that matches both the fsid and the user-specified mount options, and then spawn off a new superblock if that search fails. The attached patch does just that. Note that this is not the same as specifying nosharecache everywhere since nosharecache will never attempt to match an existing superblock. Finally, for the record: I still feel very uncomfortable about not being able to report the state of the client setup back to the sysadmin. AFAIK, the only way to do so is to stat the mountpoints, and compare the device ids. Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 user explicitly asks for -o sharecache, does he get an error back if the mount options mismatch? There has never been a 'sharecache' flag as far as the kernel is concerned. The default behaviour has always been to share. 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 Linus that changing default to nosharecache might be the best thing to do, but since I am now able to use the latest kernel, I am very happy already. Thanks a lot for your attention to my problem. :-) Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 Linus that changing default to nosharecache might be the best thing to do, but since I am now able to use the latest kernel, I am very happy already. Actually, I think just fine-tuning it a bit may be better: 1. make 'nosharecache' as default 2. apply the algorithm in this patch to 'nosharecache': if the fsid and mount options are the same, then share cache This way the default behavior does not change, but both algorithms have pitfalls, and we choose from: 1. if user specifies sharecache, he may end up with nosharecache if mount options are different And 2. if user specifies nosharecache, he may end up with sharecache if mount options are the same I'd think 2 is better (least surprise). I cannot think of a case where 2 is actually a bad thing. Comments? Thanks a lot for your attention to my problem. :-) Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 not sure about the history of other filesystems, but NFS has had the old behavior for ages, and people get used to it. Second, NFS is actually special as this particular setup is very common and you'll get into this situation far too easily, as from the server you could export two directories within a filesystem as if they were two filesystems. Very few people actually want to mount the same local filesystem multiple times, but under NFS this is the norm. Last but not the least, NFS is often controlled by central corporate policies (autofs/nis), and has to work with various clients. For example, it's not possible to add "nosharecache" to auto.auto as almost nobody understands it, unless you upgrade all the clients. > Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
> 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 out of curiosity - Hua, is this NFSv2? Especially there, cache > "consistency" is largely a joke anyway, so defaulting to some annoying > careful mode is doubly ridiculous. It's v3 as can be seen from the autofs maps I posted. These directories are used mostly as read-only and get pulled in via our build system. We do not actually write to them often, if at all. I don't think this setup is uncommon, and I am worried that once people start using the latest kernel their systems will mysteriously break. > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 tomorrow. Thanks. :-) I'm happy I'll still be able to test the latest kernels on my work desktop. > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
> 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 I have been told > that Solaris at least has it. Does Solaris enforces this "mount with same options" as default? > > "working" as in "I can mount the directory and do my work". And there > > has never been any problems as far as I know. > > That is too narrow a definition: the minimum should be "everyone can > mount their directories and do their work". Your particular setup may > be safe, but that is why we have overrides: the default should be for the > kernel to be conservative, and to _tell_ users what it thinks is wrong. Every engineer in our organization mounts it too. No problem until now. It's not very conservative to suddenly change default behavior and break autofs mounts. There is not even one kernel message that "_tells_ user why it thinks it's wrong". It just silently fails. > Your choice. No. I have no other choice as I explained before. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
> 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". > > "better" as in: "I now have a chance to notice, when my 'read-only > mount' is actually 'read-write'". > > > In this particular scenario, the maps read as follows: > > > > tools > > - > fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,n > fsve > > rs=3,actimeo=600 fs1.domain.com:/a/tools > > share > > - > fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,n > fsve > > rs=3 fs1.domain.com:/a/share > > > > The only difference is in the actimeo (I don't even know what it > > means). Is this enough to fail a mount? > > Yes. The default values for acregmin, acregmax, acdirmin, acdirmax are > not 600. If /a/tools and /a/share are on the same filesystem on the > server, then the NFS client should warn you that you are about to do > something that may result in cache coherency problems instead of > silently allowing it, and then leaving you to debug the coherency issue. There are two disjoint directories. I am wondering why there would be cache coherency issues in this case? Is this Linus nfs implementation specific or all other Unix systems all have the same issue? > If you know what you are doing, then there is an option which allows > you to override the default behaviour. > > > More importantly, it is a regression. My understanding is that unless > > absolutely necessary we do not introduce a "feature" that breaks > > working setups. > > Your turn to define what you mean by "working"? In my book that means > "a setup that doesn't include unexpected or unintended behaviour". "working" as in "I can mount the directory and do my work". And there has never been any problems as far as I know. > Not being able to notice cache coherency failures on a file that is > mounted in two different places with two different sets of mount > options counts as "unexpected behaviour". > > Not being able to notice that your mount options have been overridden > by the kernel also counts as "unexpected behaviour". Fine. These are all very nice theories, but I just want to report this regression and hope it won't cause any big problems for any users out there. In the mean time, I am returning to 2.6.22. > Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 causes > > several autofs mounts to fail silently - they just not appear when > > they should. > > I believe it's caused by the NFS change that forces multiple mounts > > from different directories under the same server side filesystem to have > > the same mount options by default, otherwise it returns EBUSY. > > > > For example, if server has a filesystem /a, and it exports /a/x and /a/y > > (maybe with rw or ro), and a client must mount /a/x and /a/y with the > > same mount options now. > > 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". In this particular scenario, the maps read as follows: tools -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve rs=3,actimeo=600 fs1.domain.com:/a/tools share -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve rs=3 fs1.domain.com:/a/share The only difference is in the actimeo (I don't even know what it means). Is this enough to fail a mount? More importantly, it is a regression. My understanding is that unless absolutely necessary we do not introduce a "feature" that breaks working setups. > If you need to mount the same filesystem with incompatible mount > options on the same client, then there is a new mount option "nosharecache", > which enables it. Unfortunately, as I said, I don't control the auto.auto nis map. > The new option is there in order to make it damned clear to sysadmins > that this is a dangerous thing to do: mounts which don't share the same > superblock also don't share the same data and attribute caches. Any > file or directory which appears in both mounts had better only be used by > one application at a time or be using an appropriate locking scheme. I guess the question is what should be the default. I'll convey this to our system admin (fortunately we are not a very big company), but I am just not 100% sure this is a well-thought change because I believe many people will be impacted once 2.6.23 is out. Shouldn't we give some time to user to fix their config before we enforce this, by like some kernel warnings? Thanks. > Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
recent nfs change causes autofs regression
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 causes several autofs mounts to fail silently - they just not appear when they should. I believe it's caused by the NFS change that forces multiple mounts from different directories under the same server side filesystem to have the same mount options by default, otherwise it returns EBUSY. For example, if server has a filesystem /a, and it exports /a/x and /a/y (maybe with rw or ro), and a client must mount /a/x and /a/y with the same mount options now. Since in my setup they are managed by autofs, and the autofs map is managed by nis, there is no way I could easily workaround it.. If we have to live with this regression, I want to hear some suggestions about how to fix them realistically. Thanks. By the way, I am not sure if I did the bisect right, but FWIW, git-bisect says: c98451bdb2f3e6d6cc1e03adad641e9497512b49 is first bad commit commit c98451bdb2f3e6d6cc1e03adad641e9497512b49 Author: Frank van Maarseveen <[EMAIL PROTECTED]> Date: Mon Jul 9 22:25:29 2007 +0200 NLM: fix source address of callback to client Use the destination address of the original NLM request as the source address in callbacks to the client. Signed-off-by: Frank van Maarseveen <[EMAIL PROTECTED]> Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> :04 04 675c84bd8b2c50744018becaa0db4aeca19b8f9f 105fbd3cb3fa5e3019836b4b5268125d0181a72d M fs :04 04 0138796e0806b4ebd1cc3850ed4e8c7ab24d2d41 2fec08debe51c20423a88b1a0d4281c683ba5daf M include -Original Message----- From: Hua Zhong [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 1:59 PM To: 'Linux Kernel Mailing List' Subject: regression of autofs for current git? 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) Thanks for your help. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
recent nfs change causes autofs regression
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 causes several autofs mounts to fail silently - they just not appear when they should. I believe it's caused by the NFS change that forces multiple mounts from different directories under the same server side filesystem to have the same mount options by default, otherwise it returns EBUSY. For example, if server has a filesystem /a, and it exports /a/x and /a/y (maybe with rw or ro), and a client must mount /a/x and /a/y with the same mount options now. Since in my setup they are managed by autofs, and the autofs map is managed by nis, there is no way I could easily workaround it.. If we have to live with this regression, I want to hear some suggestions about how to fix them realistically. Thanks. By the way, I am not sure if I did the bisect right, but FWIW, git-bisect says: c98451bdb2f3e6d6cc1e03adad641e9497512b49 is first bad commit commit c98451bdb2f3e6d6cc1e03adad641e9497512b49 Author: Frank van Maarseveen [EMAIL PROTECTED] Date: Mon Jul 9 22:25:29 2007 +0200 NLM: fix source address of callback to client Use the destination address of the original NLM request as the source address in callbacks to the client. Signed-off-by: Frank van Maarseveen [EMAIL PROTECTED] Signed-off-by: Trond Myklebust [EMAIL PROTECTED] :04 04 675c84bd8b2c50744018becaa0db4aeca19b8f9f 105fbd3cb3fa5e3019836b4b5268125d0181a72d M fs :04 04 0138796e0806b4ebd1cc3850ed4e8c7ab24d2d41 2fec08debe51c20423a88b1a0d4281c683ba5daf M include -Original Message- From: Hua Zhong [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 29, 2007 1:59 PM To: 'Linux Kernel Mailing List' Subject: regression of autofs for current git? 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) Thanks for your help. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 causes several autofs mounts to fail silently - they just not appear when they should. I believe it's caused by the NFS change that forces multiple mounts from different directories under the same server side filesystem to have the same mount options by default, otherwise it returns EBUSY. For example, if server has a filesystem /a, and it exports /a/x and /a/y (maybe with rw or ro), and a client must mount /a/x and /a/y with the same mount options now. 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. In this particular scenario, the maps read as follows: tools -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve rs=3,actimeo=600 fs1.domain.com:/a/tools share -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve rs=3 fs1.domain.com:/a/share The only difference is in the actimeo (I don't even know what it means). Is this enough to fail a mount? More importantly, it is a regression. My understanding is that unless absolutely necessary we do not introduce a feature that breaks working setups. If you need to mount the same filesystem with incompatible mount options on the same client, then there is a new mount option nosharecache, which enables it. Unfortunately, as I said, I don't control the auto.auto nis map. The new option is there in order to make it damned clear to sysadmins that this is a dangerous thing to do: mounts which don't share the same superblock also don't share the same data and attribute caches. Any file or directory which appears in both mounts had better only be used by one application at a time or be using an appropriate locking scheme. I guess the question is what should be the default. I'll convey this to our system admin (fortunately we are not a very big company), but I am just not 100% sure this is a well-thought change because I believe many people will be impacted once 2.6.23 is out. Shouldn't we give some time to user to fix their config before we enforce this, by like some kernel warnings? Thanks. Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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. better as in: I now have a chance to notice, when my 'read-only mount' is actually 'read-write'. In this particular scenario, the maps read as follows: tools - fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,n fsve rs=3,actimeo=600 fs1.domain.com:/a/tools share - fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,n fsve rs=3 fs1.domain.com:/a/share The only difference is in the actimeo (I don't even know what it means). Is this enough to fail a mount? Yes. The default values for acregmin, acregmax, acdirmin, acdirmax are not 600. If /a/tools and /a/share are on the same filesystem on the server, then the NFS client should warn you that you are about to do something that may result in cache coherency problems instead of silently allowing it, and then leaving you to debug the coherency issue. There are two disjoint directories. I am wondering why there would be cache coherency issues in this case? Is this Linus nfs implementation specific or all other Unix systems all have the same issue? If you know what you are doing, then there is an option which allows you to override the default behaviour. More importantly, it is a regression. My understanding is that unless absolutely necessary we do not introduce a feature that breaks working setups. Your turn to define what you mean by working? In my book that means a setup that doesn't include unexpected or unintended behaviour. working as in I can mount the directory and do my work. And there has never been any problems as far as I know. Not being able to notice cache coherency failures on a file that is mounted in two different places with two different sets of mount options counts as unexpected behaviour. Not being able to notice that your mount options have been overridden by the kernel also counts as unexpected behaviour. Fine. These are all very nice theories, but I just want to report this regression and hope it won't cause any big problems for any users out there. In the mean time, I am returning to 2.6.22. Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 I have been told that Solaris at least has it. Does Solaris enforces this mount with same options as default? working as in I can mount the directory and do my work. And there has never been any problems as far as I know. That is too narrow a definition: the minimum should be everyone can mount their directories and do their work. Your particular setup may be safe, but that is why we have overrides: the default should be for the kernel to be conservative, and to _tell_ users what it thinks is wrong. Every engineer in our organization mounts it too. No problem until now. It's not very conservative to suddenly change default behavior and break autofs mounts. There is not even one kernel message that _tells_ user why it thinks it's wrong. It just silently fails. Your choice. No. I have no other choice as I explained before. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 tomorrow. Thanks. :-) I'm happy I'll still be able to test the latest kernels on my work desktop. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 out of curiosity - Hua, is this NFSv2? Especially there, cache consistency is largely a joke anyway, so defaulting to some annoying careful mode is doubly ridiculous. It's v3 as can be seen from the autofs maps I posted. These directories are used mostly as read-only and get pulled in via our build system. We do not actually write to them often, if at all. I don't think this setup is uncommon, and I am worried that once people start using the latest kernel their systems will mysteriously break. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: recent nfs change causes autofs regression
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 not sure about the history of other filesystems, but NFS has had the old behavior for ages, and people get used to it. Second, NFS is actually special as this particular setup is very common and you'll get into this situation far too easily, as from the server you could export two directories within a filesystem as if they were two filesystems. Very few people actually want to mount the same local filesystem multiple times, but under NFS this is the norm. Last but not the least, NFS is often controlled by central corporate policies (autofs/nis), and has to work with various clients. For example, it's not possible to add nosharecache to auto.auto as almost nobody understands it, unless you upgrade all the clients. Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: regression of autofs for current git?
I am in the process of bisecting now. It takes a while but the bad commit is between 2.6.22 and 13f9966b3ba5b45f47f2ea0eb0a90afceedfbb1f (June 28). I'll continue tomorrow. My system is FC4. autofs-4.1.4-26 nfs-utils-1.0.7-13.FC4 By the way, the particular autofs commit Andrian sent is innocent. 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 > Cc: 'Linux Kernel Mailing List'; [EMAIL PROTECTED]; Adrian Bunk > Subject: Re: regression of autofs for current git? > > On Thu, 2007-08-30 at 00:47 +0200, Adrian Bunk wrote: > > On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote: > > > > > Hi, > > > > Hi Hua, > > > > > 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) > > > > the commit below is the only autofs4 patch that went into the git > tree > > since 2.6.22. > > > > Does reverting it fix your problems? > > Maybe but there is an NFS change that appears to be in the current > 2.6.23-rc kernel and doesn't seem to be in 2.6.22 that is known to > break > some autofs maps and also breaks amd. > > I can't seem to locate the commit just now. > In the meantime what version of user space autofs and nfs-utils are you > running? > And can you post your autofs maps please? > > Ian > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression of autofs for current git?
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) Thanks for your help. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
regression of autofs for current git?
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) Thanks for your help. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: regression of autofs for current git?
I am in the process of bisecting now. It takes a while but the bad commit is between 2.6.22 and 13f9966b3ba5b45f47f2ea0eb0a90afceedfbb1f (June 28). I'll continue tomorrow. My system is FC4. autofs-4.1.4-26 nfs-utils-1.0.7-13.FC4 By the way, the particular autofs commit Andrian sent is innocent. 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 Cc: 'Linux Kernel Mailing List'; [EMAIL PROTECTED]; Adrian Bunk Subject: Re: regression of autofs for current git? On Thu, 2007-08-30 at 00:47 +0200, Adrian Bunk wrote: On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote: Hi, Hi Hua, 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) the commit below is the only autofs4 patch that went into the git tree since 2.6.22. Does reverting it fix your problems? Maybe but there is an NFS change that appears to be in the current 2.6.23-rc kernel and doesn't seem to be in 2.6.22 that is known to break some autofs maps and also breaks amd. I can't seem to locate the commit just now. In the meantime what version of user space autofs and nfs-utils are you running? And can you post your autofs maps please? Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
> > 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 doubt that is the best reward for a developer. > > Because if you don't, the people with the 'different' ideas walk away, > > you end up with only those who 'fit' the culture, and there goes innovation. > > yet at the same time if people walk away just because their code didn't > get used, even though their problem got solved, should we merge "worse" > code just to prevent that ? That's almost blackmail, and also just > stupid. > > (not suggesting that SD in this case was better or worse, just trying > to make a general point) If it is a general point, sure, but it's hardly 1/10 of what happened here. And note I don't agree with Con's decision either - I wish he'd be back, but the reason I jumped in was to show some understanding, as I see some comments in the thread that were not doing so. When you said "it does not matter whose code got merged", I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). Con has been working on scheduler (fair or not) for years, and nothing got merged. Yet CFS got merged in a blink despite the fact that the competition just began to show. Have we given SD a fair chance? No. Ingo has a unique position that nobody else could challenge. Note I have said that he earned it through hard work and talent, so that's not the problem. The problem is how he could have handled it better, not "grab the food right under other's nose" blatantly. I don't think merging CFS was a wrong decision. The problem was how this decision was made. And I think Linus made some rather unfair comments about Con's personality, and I don't think deeply that was the reason he merged Ingo's code. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1
> 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 into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. > There are no such rights in this open source > development framework (TM). > > What Ingo did, I think, was what he wanted and he has the right to do > that. I think it's the maintainer's privilege, not right. > in the open source world, that which is superior (i.e. code, function, > not person) has the right to exist and the inferior to die away. I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1
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 into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I think it's the maintainer's privilege, not right. in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 doubt that is the best reward for a developer. Because if you don't, the people with the 'different' ideas walk away, you end up with only those who 'fit' the culture, and there goes innovation. yet at the same time if people walk away just because their code didn't get used, even though their problem got solved, should we merge worse code just to prevent that ? That's almost blackmail, and also just stupid. (not suggesting that SD in this case was better or worse, just trying to make a general point) If it is a general point, sure, but it's hardly 1/10 of what happened here. And note I don't agree with Con's decision either - I wish he'd be back, but the reason I jumped in was to show some understanding, as I see some comments in the thread that were not doing so. When you said it does not matter whose code got merged, I have to disagree. Sure, for the Linux community as a whole, for Linux itself, it may not matter, but for the individuals involved, it does. And I think benefits of individuals are as important as benefits of the community (or the nation). Con has been working on scheduler (fair or not) for years, and nothing got merged. Yet CFS got merged in a blink despite the fact that the competition just began to show. Have we given SD a fair chance? No. Ingo has a unique position that nobody else could challenge. Note I have said that he earned it through hard work and talent, so that's not the problem. The problem is how he could have handled it better, not grab the food right under other's nose blatantly. I don't think merging CFS was a wrong decision. The problem was how this decision was made. And I think Linus made some rather unfair comments about Con's personality, and I don't think deeply that was the reason he merged Ingo's code. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
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 12:51 PM > To: Andreas Dilger > Cc: Marat Buharov; Andrew Morton; Mike Galbraith; LKML; Jens Axboe; > [EMAIL PROTECTED]; Alex Tomas > Subject: Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose > when FS is under heavy write load (massive starvation) > > > > On Fri, 27 Apr 2007, Andreas Dilger wrote: > > > > It's true that this is a "feature" of ext3 with data=ordered (the > default), > > but I suspect the same thing is now true in reiserfs too. > > Oh, well.. Journalling sucks. > > I was actually _really_ hoping that somebody would come along and tell > everybody that this whole journal-logging is stupid, and that it's just > better to not ever re-write blocks on disk, but instead write to new > blocks with version numbers (and not re-use old blocks until new > versions > are stable on disk). > > There was even somebody who did something like that for a PhD thesis, I > forget the details (and it apparently died when the thesis was > presumably > accepted ;). > > Linus > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ext3][kernels = 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
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 12:51 PM To: Andreas Dilger Cc: Marat Buharov; Andrew Morton; Mike Galbraith; LKML; Jens Axboe; [EMAIL PROTECTED]; Alex Tomas Subject: Re: [ext3][kernels = 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation) On Fri, 27 Apr 2007, Andreas Dilger wrote: It's true that this is a feature of ext3 with data=ordered (the default), but I suspect the same thing is now true in reiserfs too. Oh, well.. Journalling sucks. I was actually _really_ hoping that somebody would come along and tell everybody that this whole journal-logging is stupid, and that it's just better to not ever re-write blocks on disk, but instead write to new blocks with version numbers (and not re-use old blocks until new versions are stable on disk). There was even somebody who did something like that for a PhD thesis, I forget the details (and it apparently died when the thesis was presumably accepted ;). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
> 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 own bugs, but cause bugs elsewhere? (And > yes, > I believe STD is both of those. There's a reason it's called "STD". Go > to google and type "STD" and press "I'm feeling lucky". Google is God). Linus, the fact that you personally don't use S2D does not mean it's not useful for other people. I've been using solely laptop for six years and until recently (when my commute is now only two miles) I'd always used hibernate when I go to or leave form work. And even now if I take my laptop to somewhere farther away (like on a vacation) I need hibernation. This is one area where Windows has been doing great for many years, and it's not like Linux has not had a mature implementation for many years either. So don't you think your comments are a bit odd at this point? Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
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 own bugs, but cause bugs elsewhere? (And yes, I believe STD is both of those. There's a reason it's called STD. Go to google and type STD and press I'm feeling lucky. Google is God). Linus, the fact that you personally don't use S2D does not mean it's not useful for other people. I've been using solely laptop for six years and until recently (when my commute is now only two miles) I'd always used hibernate when I go to or leave form work. And even now if I take my laptop to somewhere farther away (like on a vacation) I need hibernation. This is one area where Windows has been doing great for many years, and it's not like Linux has not had a mature implementation for many years either. So don't you think your comments are a bit odd at this point? Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
> 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 s2ram). > The only thing that matters is the end result Amen to that. The end result is not just code size, but quality and whether it actually *works reliably*. Cheers, Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
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 s2ram). The only thing that matters is the end result Amen to that. The end result is not just code size, but quality and whether it actually *works reliably*. Cheers, Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: O_DIRECT question
> 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 the trick. At least for MMU systems. > Non MMU systems just can't play mmap type games. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: O_DIRECT question
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 the trick. At least for MMU systems. Non MMU systems just can't play mmap type games. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] support O_DIRECT in tmpfs/ramfs
> > 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 > O_DIRECT (though NFS does not), I've veered right back to my > original position: this all just seems silly to me. O_DIRECT > is and always has been rather an awkward hack (Linus > described it in stronger terms!), supported by many but not > all filesystems: shall we just leave it at that? So I take your word that NFS does not impose this restraint, which means filesystems could choose their own alignment requirement that makes sense. So it would not be too horrible if tmpfs chooses to be liberal. In fact, in the O_DIRECT man page it says: O_DIRECT [] Under Linux 2.4 transfer sizes, and the alignment of user buffer and file offset must all be multiples of the logi- cal block size of the file system. Under Linux 2.6 alignment to 512-byte boundaries suffices. So even Linux 2.4 and 2.6 are different - 2.6 is less restrictive. My point is that as long as we don't put more restrictions, it should not cause real problems. And about Linus..let's put his comment aside because O_DIRECT is there to stay. :-) In fact, since O_DIRECT is not the most beaufitul piece of code in the kernel, what I try to do is just to make software developer's life easier by making filesystem behavior as close to each other as possible with the minimal effort. > In particular, having now looked into the code, I'm amused to > be reminded that one of its particular effects is to > invalidate the pagecache for the area directly written. > Well, it's hardly going to be worth replicating that > behaviour with tmpfs or ramfs; yet if we don't, then we stand > accused of it behaving misleadingly differently on them. > > I think Michael, who started off this discussion, did just the right > thing: used a direct_IO filesystem on a loop device on a tmpfs file. That's a rather heavy-weight workaround don't you think? > > 1. A new fs flag FS_RAM_BASED is added and the O_DIRECT > flag is ignored > >if this flag is set (suggestions on a better name?) > > > > 2. Specify FS_RAM_BASED for tmpfs and ramfs. > > If this is pursued (not my preference, but let me stand aside > now), you'd want to add in at least hugetlbfs and > tiny-shmem.c. And set your (renamed) FS_RAM_BASED flag in > ext2_aops_xip: that seems to be what they're wanting, then > you can remove that strange test for > f->f_mapping->a_ops->get_xip_page from __dentry_open. > > > > > 3. When EINVAL is returned only a fput is done. I changed it to go > >through cleanup_all. But there is still a cleanup problem: > > Is that change correct? Are you saying that the existing > code leaks some structures? If so, please do send a patch to > fix just that as soon as you can. But are you sure? Having looked at the code more closely, the change is probably not correct. fput(f) apparently does everything cleanup_all does, and more, despite it's a single call. I guess those names are a bit confusing at first glance. :-) > > If a new file is created and then EINVAL is returned due to > > O_DIRECT, the file is still left on the disk. I am not exactly > > sure how to fix it other than adding another fs flag so we > > could check O_DIRECT support at a much earlier stage. > > Comments on how to fix it? > > None from me, sorry. It's untidy, but not a new issue you > have to fix. Well, looks like people are not in consensus to add the tmpfs direct-io support, but since I've looked at the code, it would be nice to fix this bug though. The get_xip_page thing you mentioned makes it a bit more complicated since XIP support is a mount option, not a register_filesystem time option. If we ought to add a flag somewhere, where is the right place? vfsmount? I can cook up a patch for this bug if people think it's worth fixing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] support O_DIRECT in tmpfs/ramfs
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 O_DIRECT (though NFS does not), I've veered right back to my original position: this all just seems silly to me. O_DIRECT is and always has been rather an awkward hack (Linus described it in stronger terms!), supported by many but not all filesystems: shall we just leave it at that? So I take your word that NFS does not impose this restraint, which means filesystems could choose their own alignment requirement that makes sense. So it would not be too horrible if tmpfs chooses to be liberal. In fact, in the O_DIRECT man page it says: O_DIRECT [] Under Linux 2.4 transfer sizes, and the alignment of user buffer and file offset must all be multiples of the logi- cal block size of the file system. Under Linux 2.6 alignment to 512-byte boundaries suffices. So even Linux 2.4 and 2.6 are different - 2.6 is less restrictive. My point is that as long as we don't put more restrictions, it should not cause real problems. And about Linus..let's put his comment aside because O_DIRECT is there to stay. :-) In fact, since O_DIRECT is not the most beaufitul piece of code in the kernel, what I try to do is just to make software developer's life easier by making filesystem behavior as close to each other as possible with the minimal effort. In particular, having now looked into the code, I'm amused to be reminded that one of its particular effects is to invalidate the pagecache for the area directly written. Well, it's hardly going to be worth replicating that behaviour with tmpfs or ramfs; yet if we don't, then we stand accused of it behaving misleadingly differently on them. I think Michael, who started off this discussion, did just the right thing: used a direct_IO filesystem on a loop device on a tmpfs file. That's a rather heavy-weight workaround don't you think? 1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored if this flag is set (suggestions on a better name?) 2. Specify FS_RAM_BASED for tmpfs and ramfs. If this is pursued (not my preference, but let me stand aside now), you'd want to add in at least hugetlbfs and tiny-shmem.c. And set your (renamed) FS_RAM_BASED flag in ext2_aops_xip: that seems to be what they're wanting, then you can remove that strange test for f-f_mapping-a_ops-get_xip_page from __dentry_open. 3. When EINVAL is returned only a fput is done. I changed it to go through cleanup_all. But there is still a cleanup problem: Is that change correct? Are you saying that the existing code leaks some structures? If so, please do send a patch to fix just that as soon as you can. But are you sure? Having looked at the code more closely, the change is probably not correct. fput(f) apparently does everything cleanup_all does, and more, despite it's a single call. I guess those names are a bit confusing at first glance. :-) If a new file is created and then EINVAL is returned due to O_DIRECT, the file is still left on the disk. I am not exactly sure how to fix it other than adding another fs flag so we could check O_DIRECT support at a much earlier stage. Comments on how to fix it? None from me, sorry. It's untidy, but not a new issue you have to fix. Well, looks like people are not in consensus to add the tmpfs direct-io support, but since I've looked at the code, it would be nice to fix this bug though. The get_xip_page thing you mentioned makes it a bit more complicated since XIP support is a mount option, not a register_filesystem time option. If we ought to add a flag somewhere, where is the right place? vfsmount? I can cook up a patch for this bug if people think it's worth fixing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] support O_DIRECT in tmpfs/ramfs
Hi,
A while ago there was a discussion about supporting direct-io on tmpfs.
Here is a simple patch that does it.
1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored
if this flag is set (suggestions on a better name?)
2. Specify FS_RAM_BASED for tmpfs and ramfs.
3. When EINVAL is returned only a fput is done. I changed it to go
through cleanup_all. But there is still a cleanup problem:
If a new file is created and then EINVAL is returned due to O_DIRECT,
the file is still left on the disk. I am not exactly sure how to fix
it other than adding another fs 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(struct
/* NB: we're sure to have correct a_ops only after f_op->open */
if (f->f_flags & O_DIRECT) {
- if (!f->f_mapping->a_ops ||
- ((!f->f_mapping->a_ops->direct_IO) &&
- (!f->f_mapping->a_ops->get_xip_page))) {
- fput(f);
- f = ERR_PTR(-EINVAL);
+ if (dentry->d_sb->s_type->fs_flags & FS_RAM_BASED)
+ f->f_flags &= ~O_DIRECT;
+ else if (!f->f_mapping->a_ops ||
+((!f->f_mapping->a_ops->direct_IO) &&
+ (!f->f_mapping->a_ops->get_xip_page))) {
+ error = -EINVAL;
+ goto cleanup_all;
}
}
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 2faf4cd..0d4bebc 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -199,11 +199,13 @@ static int rootfs_get_sb(struct file_sys
static struct file_system_type ramfs_fs_type = {
.name = "ramfs",
+ .fs_flags = FS_RAM_BASED,
.get_sb = ramfs_get_sb,
.kill_sb= kill_litter_super,
};
static struct file_system_type rootfs_fs_type = {
.name = "rootfs",
+ .fs_flags = FS_RAM_BASED,
.get_sb = rootfs_get_sb,
.kill_sb= kill_litter_super,
};
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 186da81..0d95988 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -91,6 +91,7 @@ extern int dir_notify_enable;
/* public flags for file_system_type */
#define FS_REQUIRES_DEV 1
#define FS_BINARY_MOUNTDATA 2
+#define FS_RAM_BASED 8192/* Ignore O_DIRECT */
#define FS_REVAL_DOT 16384 /* Check the paths ".", ".." for staleness */
#define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move()
* during rename() internally.
diff --git a/mm/shmem.c b/mm/shmem.c
index 70da7a0..5d23e8a 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2413,6 +2413,7 @@ static int shmem_get_sb(struct file_syst
static struct file_system_type tmpfs_fs_type = {
.owner = THIS_MODULE,
.name = "tmpfs",
+ .fs_flags = FS_RAM_BASED,
.get_sb = shmem_get_sb,
.kill_sb= kill_litter_super,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] include/linux/slab.h: new KFREE() macro.
> --- 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. > > > > How does this help? It doesn't. I thought that was my point? > > > And as I explained, it can result in longer code too. So, why > > > keep this value around. Why not re-initialize it to NULL. > > > > Because initialization increases code size. > > Then why use kzalloc()? Let's remove _ALL_ the initialization > code from the kernel. You initialize before use, not after. > Attached is some code from the kernel. Expanded KFREE() has > been used atleast 1000 times in the > kernel. By your logic, everyone is stupid in doing so. > Something has been done atleast 1000 times > in the kernel, that looks okay. But consolidating it at one > place does not look okay. I am listing > some of the 1000 places where KFREE() has been used. All this > code have been written by atleast 50 > different people. From your logic they were doing "silly" things. Maybe you should first each one of them and see why they do it. And if there is no purpose than "better be safe than sorry", maybe you can then submit a patch to fix it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] include/linux/slab.h: new KFREE() macro.
--- 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. How does this help? It doesn't. I thought that was my point? And as I explained, it can result in longer code too. So, why keep this value around. Why not re-initialize it to NULL. Because initialization increases code size. Then why use kzalloc()? Let's remove _ALL_ the initialization code from the kernel. You initialize before use, not after. Attached is some code from the kernel. Expanded KFREE() has been used atleast 1000 times in the kernel. By your logic, everyone is stupid in doing so. Something has been done atleast 1000 times in the kernel, that looks okay. But consolidating it at one place does not look okay. I am listing some of the 1000 places where KFREE() has been used. All this code have been written by atleast 50 different people. From your logic they were doing silly things. Maybe you should first each one of them and see why they do it. And if there is no purpose than better be safe than sorry, maybe you can then submit a patch to fix it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] support O_DIRECT in tmpfs/ramfs
Hi,
A while ago there was a discussion about supporting direct-io on tmpfs.
Here is a simple patch that does it.
1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored
if this flag is set (suggestions on a better name?)
2. Specify FS_RAM_BASED for tmpfs and ramfs.
3. When EINVAL is returned only a fput is done. I changed it to go
through cleanup_all. But there is still a cleanup problem:
If a new file is created and then EINVAL is returned due to O_DIRECT,
the file is still left on the disk. I am not exactly sure how to fix
it other than adding another fs 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(struct
/* NB: we're sure to have correct a_ops only after f_op-open */
if (f-f_flags O_DIRECT) {
- if (!f-f_mapping-a_ops ||
- ((!f-f_mapping-a_ops-direct_IO)
- (!f-f_mapping-a_ops-get_xip_page))) {
- fput(f);
- f = ERR_PTR(-EINVAL);
+ if (dentry-d_sb-s_type-fs_flags FS_RAM_BASED)
+ f-f_flags = ~O_DIRECT;
+ else if (!f-f_mapping-a_ops ||
+((!f-f_mapping-a_ops-direct_IO)
+ (!f-f_mapping-a_ops-get_xip_page))) {
+ error = -EINVAL;
+ goto cleanup_all;
}
}
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index 2faf4cd..0d4bebc 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -199,11 +199,13 @@ static int rootfs_get_sb(struct file_sys
static struct file_system_type ramfs_fs_type = {
.name = ramfs,
+ .fs_flags = FS_RAM_BASED,
.get_sb = ramfs_get_sb,
.kill_sb= kill_litter_super,
};
static struct file_system_type rootfs_fs_type = {
.name = rootfs,
+ .fs_flags = FS_RAM_BASED,
.get_sb = rootfs_get_sb,
.kill_sb= kill_litter_super,
};
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 186da81..0d95988 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -91,6 +91,7 @@ extern int dir_notify_enable;
/* public flags for file_system_type */
#define FS_REQUIRES_DEV 1
#define FS_BINARY_MOUNTDATA 2
+#define FS_RAM_BASED 8192/* Ignore O_DIRECT */
#define FS_REVAL_DOT 16384 /* Check the paths ., .. for staleness */
#define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move()
* during rename() internally.
diff --git a/mm/shmem.c b/mm/shmem.c
index 70da7a0..5d23e8a 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2413,6 +2413,7 @@ static int shmem_get_sb(struct file_syst
static struct file_system_type tmpfs_fs_type = {
.owner = THIS_MODULE,
.name = tmpfs,
+ .fs_flags = FS_RAM_BASED,
.get_sb = shmem_get_sb,
.kill_sb= kill_litter_super,
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] include/linux/slab.h: new KFREE() macro.
> 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 it to NULL. Because initialization increases code size. It's a silly patch. > If x should not be re-initialized to NULL, then by the same > logic, we should not even initialize local variables. And all > of us know that local variables should be initialized. > > I would like to know a good reason as to why x should not be > set to NULL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] include/linux/slab.h: new KFREE() macro.
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 it to NULL. Because initialization increases code size. It's a silly patch. If x should not be re-initialized to NULL, then by the same logic, we should not even initialize local variables. And all of us know that local variables should be initialized. I would like to know a good reason as to why x should not be set to NULL. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: open(O_DIRECT) on a tmpfs?
> 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. According to "man 2 open" on my system: O_DIRECT Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is synchronous, i.e., at the completion of the read(2) or write(2) system call, data is guaranteed to have been trans- ferred. Under Linux 2.4 transfer sizes, and the alignment of user buffer and file offset must all be multiples of the logi- cal block size of the file system. Under Linux 2.6 alignment to 512-byte boundaries suffices. A semantically similar interface for block devices is described in raw(8). This says nothing about (probably disk based) persistent backing store. I don't see why tmpfs has to conflict with it. So I'd argue that it makes more sense to support O_DIRECT on tmpfs as the memory IS the backing store. And EINVAL isn't even a very specific error. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: open(O_DIRECT) on a tmpfs?
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. According to man 2 open on my system: O_DIRECT Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is synchronous, i.e., at the completion of the read(2) or write(2) system call, data is guaranteed to have been trans- ferred. Under Linux 2.4 transfer sizes, and the alignment of user buffer and file offset must all be multiples of the logi- cal block size of the file system. Under Linux 2.6 alignment to 512-byte boundaries suffices. A semantically similar interface for block devices is described in raw(8). This says nothing about (probably disk based) persistent backing store. I don't see why tmpfs has to conflict with it. So I'd argue that it makes more sense to support O_DIRECT on tmpfs as the memory IS the backing store. And EINVAL isn't even a very specific error. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2-mm1] init segfaults whenCONFIG_PROFILE_LIKELY=y
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/include/linux/compiler.h.orig 2007-01-02 13:51:32.0
-0800
+++ linux-2.6/include/linux/compiler.h 2007-01-02 14:18:33.0 -0800
@@ -53,6 +53,9 @@
# include
#endif
+#define __likely(x)__builtin_expect(!!(x), 1)
+#define __unlikely(x) __builtin_expect(!!(x), 0)
+
#if defined(CONFIG_PROFILE_LIKELY) && !(defined(CONFIG_MODULE_UNLOAD) &&
defined(MODULE))
struct likeliness {
const char *func;
@@ -93,8 +96,8 @@
* specific implementations come from the above header files
*/
-#define likely(x) __builtin_expect(!!(x), 1)
-#define unlikely(x)__builtin_expect(!!(x), 0)
+#define likely(x) __likely(x)
+#define unlikely(x)__unlikely(x)
#endif
/* Optimization barrier */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG 2.6.20-rc2-mm1] init segfaults whenCONFIG_PROFILE_LIKELY=y
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/include/linux/compiler.h.orig 2007-01-02 13:51:32.0
-0800
+++ linux-2.6/include/linux/compiler.h 2007-01-02 14:18:33.0 -0800
@@ -53,6 +53,9 @@
# include linux/compiler-intel.h
#endif
+#define __likely(x)__builtin_expect(!!(x), 1)
+#define __unlikely(x) __builtin_expect(!!(x), 0)
+
#if defined(CONFIG_PROFILE_LIKELY) !(defined(CONFIG_MODULE_UNLOAD)
defined(MODULE))
struct likeliness {
const char *func;
@@ -93,8 +96,8 @@
* specific implementations come from the above header files
*/
-#define likely(x) __builtin_expect(!!(x), 1)
-#define unlikely(x)__builtin_expect(!!(x), 0)
+#define likely(x) __likely(x)
+#define unlikely(x)__unlikely(x)
#endif
/* Optimization barrier */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
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: Chris Wedgwood > Cc: Eric Sandeen; Christoph Hellwig; Linus Torvalds; Jeff > Garzik; Greg KH; Jonathan Corbet; Andrew Morton; Martin > Bligh; Michael K. Edwards; linux-kernel@vger.kernel.org > Subject: Re: GPL only modules [was Re: [GIT PATCH] more > Driver core patches for 2.6.19] > > On 12/14/06, Chris Wedgwood <[EMAIL PROTECTED]> wrote: > > On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > > > > > Please don't use that name, it strikes me as much more confusing > > > than EXPORT_SYMBOL_GPL, even though I agree that _GPL > doesn't quite > > > convey what it means, either. > > > > Calling internal symbols _INTERNAL is confusing? > > I think it's the combination of "INTERNAL" and "EXPORT" that > seems contradictory - "If it's internal, why are you exporting it?" > > I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would > make the meaning clearer, but I don't really think the gain > is worth the pain. > Anybody using kernel interfaces ought to be able to figure it out. > > > > > But those symbols aren't, they're about internal interfaces > that might > > change. > > Folks who think this is likely to make a difference in court > might want to look at > > for a litany of court cases that have rejected infringement > claims where a much sterner effort had been made to hide or > block use of interfaces. > The article claims that courts have increasingly found that > interfacing your code to an existing work is not > infringement, regardless of what you have to work around to do it. > > Of course, that's one author's reading of the case law and > I'm sure there are others who disagree, but it's something > you'd want to keep in mind in calculating the expected value > of a suit... > > scott > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to > [EMAIL PROTECTED] More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
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: Chris Wedgwood Cc: Eric Sandeen; Christoph Hellwig; Linus Torvalds; Jeff Garzik; Greg KH; Jonathan Corbet; Andrew Morton; Martin Bligh; Michael K. Edwards; linux-kernel@vger.kernel.org Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] On 12/14/06, Chris Wedgwood [EMAIL PROTECTED] wrote: On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: Please don't use that name, it strikes me as much more confusing than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite convey what it means, either. Calling internal symbols _INTERNAL is confusing? I think it's the combination of INTERNAL and EXPORT that seems contradictory - If it's internal, why are you exporting it? I think EXPORT_SYMBOL_GPL_ONLY or ...ONLY UNDER_GPL would make the meaning clearer, but I don't really think the gain is worth the pain. Anybody using kernel interfaces ought to be able to figure it out. But those symbols aren't, they're about internal interfaces that might change. Folks who think this is likely to make a difference in court might want to look at http:www.linuxworld.com/news/2006/120806-closed-modules2.html for a litany of court cases that have rejected infringement claims where a much sterner effort had been made to hide or block use of interfaces. The article claims that courts have increasingly found that interfacing your code to an existing work is not infringement, regardless of what you have to work around to do it. Of course, that's one author's reading of the case law and I'm sure there are others who disagree, but it's something you'd want to keep in mind in calculating the expected value of a suit... scott - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
> 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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
> 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 "historical" purpose: they tell > > when the contribution was made, what the author's email addresses > > were at that point. > > For historical purposes, you can always use historical kernels. Then remove all the lines like the following: - * 1.0 16 Feb 2000, Tigran Aivazian <[EMAIL PROTECTED]> + * 1.0 16 Feb 2000, Tigran Aivazian * Initial release. - * 1.0118 Feb 2000, Tigran Aivazian <[EMAIL PROTECTED]> + * 1.0118 Feb 2000, Tigran Aivazian * Added read() support + cleanups. If you keep them, they tell the history and email addresses are part of the history. Or simply remove all the history and tell people to look for the information in git changelogs. The way you are doing it, serves no purpose other than losing information. > > It's not MAINTAINERS. If people want to contact someone, go > > find the latest address there. > > It's also MODULE_AUTHOR() and printk() which are far more > user-visible than MAINTAINERS. Those are OK. But majority of you patch isn't the case. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
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 Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Bunk > Sent: Thursday, November 30, 2006 9:52 PM > To: [EMAIL PROTECTED] > Cc: linux-kernel@vger.kernel.org > Subject: [2.6 patch] Tigran Aivazian: remove bouncing email addresses > > This patch removes bouncing email addresses of Tigran > Aivazian from the kernel tree. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > > Documentation/filesystems/bfs.txt |2 +- > arch/i386/kernel/microcode.c | 28 ++-- > arch/sh/kernel/kgdb_stub.c|2 +- > drivers/net/tlan.c|2 +- > fs/bfs/bfs.h |2 +- > fs/bfs/dir.c |2 +- > fs/bfs/file.c |2 +- > fs/bfs/inode.c|2 +- > fs/proc/kcore.c |4 ++-- > include/asm-sh/kgdb.h |2 +- > include/linux/bfs_fs.h|2 +- > mm/vmalloc.c |2 +- > 12 files changed, 26 insertions(+), 26 deletions(-) > > --- linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c.old > 2006-11-30 06:04:39.0 +0100 > +++ linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c > 2006-11-30 06:08:32.0 +0100 > @@ -20,25 +20,25 @@ > * as published by the Free Software Foundation; either version > * 2 of the License, or (at your option) any later version. > * > - * 1.0 16 Feb 2000, Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.0 16 Feb 2000, Tigran Aivazian > * Initial release. > - * 1.0118 Feb 2000, Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.0118 Feb 2000, Tigran Aivazian > * Added read() support + cleanups. > - * 1.0221 Feb 2000, Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.0221 Feb 2000, Tigran Aivazian > * Added 'device trimming' support. open(O_WRONLY) zeroes > * and frees the saved copy of applied microcode. > - * 1.0329 Feb 2000, Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.0329 Feb 2000, Tigran Aivazian > * Made to use devfs (/dev/cpu/microcode) + cleanups. > * 1.0406 Jun 2000, Simon Trimmer <[EMAIL PROTECTED]> > * Added misc device support (now uses both devfs > and misc). > * Added MICROCODE_IOCFREE ioctl to clear memory. > * 1.0509 Jun 2000, Simon Trimmer <[EMAIL PROTECTED]> > * Messages for error cases (non Intel & no > suitable microcode). > - * 1.0603 Aug 2000, Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.0603 Aug 2000, Tigran Aivazian > * Removed ->release(). Removed exclusive open and > status bitmap. > * Added microcode_rwsem to serialize > read()/write()/ioctl(). > * Removed global kernel lock usage. > - * 1.0707 Sep 2000, Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.0707 Sep 2000, Tigran Aivazian > * Write 0 to 0x8B msr and then cpuid before > reading revision, > * so that it works even if there were no update > done by the > * BIOS. Otherwise, reading from 0x8B gives junk > (which happened > @@ -46,26 +46,26 @@ > * disabled update by the BIOS) > * Thanks to Eric W. Biederman > for the fix. > * 1.0811 Dec 2000, Richard Schaal > <[EMAIL PROTECTED]> and > - *Tigran Aivazian <[EMAIL PROTECTED]> > + *Tigran Aivazian > * Intel Pentium 4 processor support and bugfixes. > - * 1.0930 Oct 2001, Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.0930 Oct 2001, Tigran Aivazian > * Bugfix for HT (Hyper-Threading) enabled processors > * whereby processor resources are shared by all > logical processors > * in a single CPU package. > * 1.1028 Feb 2002 Asit K Mallick > <[EMAIL PROTECTED]> and > - * Tigran Aivazian <[EMAIL PROTECTED]>, > + * Tigran Aivazian > * Serialize updates as required on HT processors > due to speculative > * nature of implementation. > - * 1.1122 Mar 2002 Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.1122 Mar 2002 Tigran Aivazian > * Fix the panic when writing zero-length microcode chunk. > * 1.1229 Sep 2003 Nitin Kamble <[EMAIL PROTECTED]>, > * Jun Nakajima <[EMAIL PROTECTED]> > * Support for the microcode updates in the new format. > - * 1.1310 Oct 2003 Tigran Aivazian <[EMAIL PROTECTED]> > + * 1.1310 Oct 2003 Tigran Aivazian > * Removed ->read() method and obsoleted > MICROCODE_IOCFREE ioctl > * because
RE: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
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 Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Bunk Sent: Thursday, November 30, 2006 9:52 PM To: [EMAIL PROTECTED] Cc: linux-kernel@vger.kernel.org Subject: [2.6 patch] Tigran Aivazian: remove bouncing email addresses This patch removes bouncing email addresses of Tigran Aivazian from the kernel tree. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- Documentation/filesystems/bfs.txt |2 +- arch/i386/kernel/microcode.c | 28 ++-- arch/sh/kernel/kgdb_stub.c|2 +- drivers/net/tlan.c|2 +- fs/bfs/bfs.h |2 +- fs/bfs/dir.c |2 +- fs/bfs/file.c |2 +- fs/bfs/inode.c|2 +- fs/proc/kcore.c |4 ++-- include/asm-sh/kgdb.h |2 +- include/linux/bfs_fs.h|2 +- mm/vmalloc.c |2 +- 12 files changed, 26 insertions(+), 26 deletions(-) --- linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c.old 2006-11-30 06:04:39.0 +0100 +++ linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c 2006-11-30 06:08:32.0 +0100 @@ -20,25 +20,25 @@ * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. * - * 1.0 16 Feb 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0 16 Feb 2000, Tigran Aivazian * Initial release. - * 1.0118 Feb 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0118 Feb 2000, Tigran Aivazian * Added read() support + cleanups. - * 1.0221 Feb 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0221 Feb 2000, Tigran Aivazian * Added 'device trimming' support. open(O_WRONLY) zeroes * and frees the saved copy of applied microcode. - * 1.0329 Feb 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0329 Feb 2000, Tigran Aivazian * Made to use devfs (/dev/cpu/microcode) + cleanups. * 1.0406 Jun 2000, Simon Trimmer [EMAIL PROTECTED] * Added misc device support (now uses both devfs and misc). * Added MICROCODE_IOCFREE ioctl to clear memory. * 1.0509 Jun 2000, Simon Trimmer [EMAIL PROTECTED] * Messages for error cases (non Intel no suitable microcode). - * 1.0603 Aug 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0603 Aug 2000, Tigran Aivazian * Removed -release(). Removed exclusive open and status bitmap. * Added microcode_rwsem to serialize read()/write()/ioctl(). * Removed global kernel lock usage. - * 1.0707 Sep 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0707 Sep 2000, Tigran Aivazian * Write 0 to 0x8B msr and then cpuid before reading revision, * so that it works even if there were no update done by the * BIOS. Otherwise, reading from 0x8B gives junk (which happened @@ -46,26 +46,26 @@ * disabled update by the BIOS) * Thanks to Eric W. Biederman ebiederman@lnxi.com for the fix. * 1.0811 Dec 2000, Richard Schaal [EMAIL PROTECTED] and - *Tigran Aivazian [EMAIL PROTECTED] + *Tigran Aivazian * Intel Pentium 4 processor support and bugfixes. - * 1.0930 Oct 2001, Tigran Aivazian [EMAIL PROTECTED] + * 1.0930 Oct 2001, Tigran Aivazian * Bugfix for HT (Hyper-Threading) enabled processors * whereby processor resources are shared by all logical processors * in a single CPU package. * 1.1028 Feb 2002 Asit K Mallick [EMAIL PROTECTED] and - * Tigran Aivazian [EMAIL PROTECTED], + * Tigran Aivazian * Serialize updates as required on HT processors due to speculative * nature of implementation. - * 1.1122 Mar 2002 Tigran Aivazian [EMAIL PROTECTED] + * 1.1122 Mar 2002 Tigran Aivazian * Fix the panic when writing zero-length microcode chunk. * 1.1229 Sep 2003 Nitin Kamble [EMAIL PROTECTED], * Jun Nakajima [EMAIL PROTECTED] * Support for the microcode updates in the new format. - * 1.1310 Oct 2003 Tigran Aivazian [EMAIL PROTECTED] + * 1.1310 Oct 2003 Tigran Aivazian * Removed -read() method and obsoleted MICROCODE_IOCFREE ioctl * because we no longer hold a copy of applied microcode * in kernel memory. - * 1.1425 Jun 2004 Tigran Aivazian
RE: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
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 historical purpose: they tell when the contribution was made, what the author's email addresses were at that point. For historical purposes, you can always use historical kernels. Then remove all the lines like the following: - * 1.0 16 Feb 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0 16 Feb 2000, Tigran Aivazian * Initial release. - * 1.0118 Feb 2000, Tigran Aivazian [EMAIL PROTECTED] + * 1.0118 Feb 2000, Tigran Aivazian * Added read() support + cleanups. If you keep them, they tell the history and email addresses are part of the history. Or simply remove all the history and tell people to look for the information in git changelogs. The way you are doing it, serves no purpose other than losing information. It's not MAINTAINERS. If people want to contact someone, go find the latest address there. It's also MODULE_AUTHOR() and printk() which are far more user-visible than MAINTAINERS. Those are OK. But majority of you patch isn't the case. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
>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 space file takelock lockresource lock1 do stuff droplock lockresource lock1 close lock space file Then if you are killed the ->release of lock space file should take care of cleaning up all the locks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
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 space file takelock lockresource lock1 do stuff droplock lockresource lock1 close lock space file Then if you are killed the -release of lock space file should take care of cleaning up all the locks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Linux-cluster] Re: GFS, what's remaining
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 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Christoph Hellwig > Sent: Thursday, September 01, 2005 10:56 AM > To: Alan Cox > Cc: Christoph Hellwig; Andrew Morton; > linux-fsdevel@vger.kernel.org; [EMAIL PROTECTED]; > linux-kernel@vger.kernel.org > Subject: [Linux-cluster] Re: GFS, what's remaining > > On Thu, Sep 01, 2005 at 04:28:30PM +0100, Alan Cox wrote: > > > That's GFS. The submission is about a GFS2 that's > on-disk incompatible > > > to GFS. > > > > Just like say reiserfs3 and reiserfs4 or ext and ext2 or > ext2 and ext3 > > then. I think the main point still stands - we have always taken > > multiple file systems on board and we have benefitted > enormously from > > having the competition between them instead of a dictat > from the kernel > > kremlin that 'foofs is the one true way' > > I didn't say anything agains a particular fs, just that your previous > arguments where utter nonsense. In fact I think having two > or more cluster > filesystems in the tree is a good thing. Whether the gfs2 > code is mergeable > is a completely different question, and it seems at least debatable to > submit a filesystem for inclusion that's still pretty new. > > While we're at it I can't find anything describing what gfs2 is about, > what is lacking in gfs, what structual changes did you make, etc.. > > p.s. why is gfs2 in fs/gfs in the kernel tree? > > -- > Linux-cluster mailing list > [EMAIL PROTECTED] > http://www.redhat.com/mailman/listinfo/linux-cluster - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Linux-cluster] Re: GFS, what's remaining
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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Hellwig Sent: Thursday, September 01, 2005 10:56 AM To: Alan Cox Cc: Christoph Hellwig; Andrew Morton; linux-fsdevel@vger.kernel.org; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Subject: [Linux-cluster] Re: GFS, what's remaining On Thu, Sep 01, 2005 at 04:28:30PM +0100, Alan Cox wrote: That's GFS. The submission is about a GFS2 that's on-disk incompatible to GFS. Just like say reiserfs3 and reiserfs4 or ext and ext2 or ext2 and ext3 then. I think the main point still stands - we have always taken multiple file systems on board and we have benefitted enormously from having the competition between them instead of a dictat from the kernel kremlin that 'foofs is the one true way' I didn't say anything agains a particular fs, just that your previous arguments where utter nonsense. In fact I think having two or more cluster filesystems in the tree is a good thing. Whether the gfs2 code is mergeable is a completely different question, and it seems at least debatable to submit a filesystem for inclusion that's still pretty new. While we're at it I can't find anything describing what gfs2 is about, what is lacking in gfs, what structual changes did you make, etc.. p.s. why is gfs2 in fs/gfs in the kernel tree? -- Linux-cluster mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/linux-cluster - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel SCM saga..
> 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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel SCM saga..
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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 2.6.11.6
> 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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 2.6.11.6
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: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> -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 a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
-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 a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> 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 develops at a faster pace than testers can keep up with, and that's why you feel there aren't enough testers. Not everyone downloads a kernel every day or even every week. Just once a while. If you roll out a kernel, you need to give some time to people to test it out. However, with the current model the kernel keeps adding features, non-bug fixes, etc, _and completely abandons the previous one and moves on_. So what's the point of testing? When I download 2.6.9, 2.6.11 might have come out. Even if bug reports do not become obosolete, they are outpaced by new bugs. Agreed we need a balance. The problem is the 2.6 focuses too much on development than stablization. The old "stable release maintainer" model was completely abandoned. Surely that was not an exciting job, but people need it. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> 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 2.6.x.y until he thinks stable enough, and he moves on to another 2.6.z release and start the same work. He decides which 2.6.x to pick for the next stable release. Alan Cox has expressed his interest in this during the last discussion but it seems you didn't pay attention or care. The reason that I think it's important for some other person to do this job independently is that you are not bothered by bugfixes, which you never did well. :) You move on to each release as you do today, with different criteria, and someone else who can do the job better do so to stablize it. In the end it's more like the old way of 2.5/2.4, but just with a shorter release cycle, and the "2.6 stable release maintainer" could also continue to pick up new 2.6.x releases to work on instead of having to be stuck on one tree for 2 years or ever. He can say "this is the last 2.6.12.x release and next I'll start 2.6.16.1", etc. For this to happen the person has to be well-recognized and trusted by the community. Alan is one of the best candidates. :) Of course, I'm not sure if he is still interested.. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> In fact, if somebody maintained that kind of tree, especially > in BK, it would be trivial for me to just pull from it every once in a > while (like ever _day_ if necessary). But for that to work, then that > tree would have to be about so _obviously_ not wild patches that > 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 a 2.6 stable > release" hence the comment. I'll do it if Linus wants Do you consider having a real stable release maintainer again? If you want someone to do the job, give him a title. It's a thankless and boring job, and you can't make it worse by just hiding him somewhere. How a "stable release maintainer" works for the current model is up to you. One thought is that he picks up 2.6.x release as a start point and takes patches to make it stable, then releases it _himself_, not by Linus. Because the real work is done by him and you need to give him the authority (just like other Linux 2.x maintainers who release official kernels). But of course you still pull from his tree to make sure the bug fixes are also committed to mainline. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
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 develops at a faster pace than testers can keep up with, and that's why you feel there aren't enough testers. Not everyone downloads a kernel every day or even every week. Just once a while. If you roll out a kernel, you need to give some time to people to test it out. However, with the current model the kernel keeps adding features, non-bug fixes, etc, _and completely abandons the previous one and moves on_. So what's the point of testing? When I download 2.6.9, 2.6.11 might have come out. Even if bug reports do not become obosolete, they are outpaced by new bugs. Agreed we need a balance. The problem is the 2.6 focuses too much on development than stablization. The old stable release maintainer model was completely abandoned. Surely that was not an exciting job, but people need it. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
In fact, if somebody maintained that kind of tree, especially in BK, it would be trivial for me to just pull from it every once in a while (like ever _day_ if necessary). But for that to work, then that tree would have to be about so _obviously_ not wild patches that 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 a 2.6 stable release hence the comment. I'll do it if Linus wants Do you consider having a real stable release maintainer again? If you want someone to do the job, give him a title. It's a thankless and boring job, and you can't make it worse by just hiding him somewhere. How a stable release maintainer works for the current model is up to you. One thought is that he picks up 2.6.x release as a start point and takes patches to make it stable, then releases it _himself_, not by Linus. Because the real work is done by him and you need to give him the authority (just like other Linux 2.x maintainers who release official kernels). But of course you still pull from his tree to make sure the bug fixes are also committed to mainline. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
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 2.6.x.y until he thinks stable enough, and he moves on to another 2.6.z release and start the same work. He decides which 2.6.x to pick for the next stable release. Alan Cox has expressed his interest in this during the last discussion but it seems you didn't pay attention or care. The reason that I think it's important for some other person to do this job independently is that you are not bothered by bugfixes, which you never did well. :) You move on to each release as you do today, with different criteria, and someone else who can do the job better do so to stablize it. In the end it's more like the old way of 2.5/2.4, but just with a shorter release cycle, and the 2.6 stable release maintainer could also continue to pick up new 2.6.x releases to work on instead of having to be stuck on one tree for 2 years or ever. He can say this is the last 2.6.12.x release and next I'll start 2.6.16.1, etc. For this to happen the person has to be well-recognized and trusted by the community. Alan is one of the best candidates. :) Of course, I'm not sure if he is still interested.. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> 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 will realize it and just stop testing even real releases. The trick won't last. What other names will we try then? Seriously, this is silly and the focus is wrong, and will accomplish nothing but confusing people one more time. Let's start by making rc really "release-candidate", not something with last-minute unpredictable random changes. Why should I test rc when I know the final release will be much different anyway? What is worse is that we actually _complain_ about the fact that people do not take rc seriously, while the release management doesn't take it seriously itself. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> 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 source keeps people honest". Don't play game with the naming. :-) Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
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 source keeps people honest. Don't play game with the naming. :-) Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
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 will realize it and just stop testing even real releases. The trick won't last. What other names will we try then? Seriously, this is silly and the focus is wrong, and will accomplish nothing but confusing people one more time. Let's start by making rc really release-candidate, not something with last-minute unpredictable random changes. Why should I test rc when I know the final release will be much different anyway? What is worse is that we actually _complain_ about the fact that people do not take rc seriously, while the release management doesn't take it seriously itself. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BK] upgrade will be needed
> 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 *free* Unix (and thus whether they could have been asked to not go write a clone) is another matter. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BK] upgrade will be needed
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 *free* Unix (and thus whether they could have been asked to not go write a clone) is another matter. Hua - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
-> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
-> 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 programs listening on a port and accepting incoming connections or datagrams? :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
- 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 programs listening on a port and accepting incoming connections or datagrams? :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
- 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 unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
-> 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 if they have to use a computer in their jobs (maybe they can Macintosh). One of my dreams is someday Linux can really be a great desktop operating system, but you know that's not yet real now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
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 > -- > -- > Martin Knoblauch |email: [EMAIL PROTECTED] > TeraPort GmbH|Phone: +49-89-510857-309 > C+ITS|Fax:+49-89-510857-111 > http://www.teraport.de |Mobile: +49-170-4904759 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -> From Martin Knoblauch <[EMAIL PROTECTED]> : - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
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 read MAINTAINERS, they won't read /proc/maintainers either. > >Print all copyright, config, etc. as KERN_DEBUG. > > How about a new level, say "KERN_CONFIG", with a "show-config" > parameter to enable displaying KERN_CONFIG messages? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
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 read MAINTAINERS, they won't read /proc/maintainers either. Print all copyright, config, etc. as KERN_DEBUG. How about a new level, say KERN_CONFIG, with a show-config parameter to enable displaying KERN_CONFIG messages? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
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 -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - From Martin Knoblauch [EMAIL PROTECTED] : - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
- 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 if they have to use a computer in their jobs (maybe they can Macintosh). One of my dreams is someday Linux can really be a great desktop operating system, but you know that's not yet real now. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
> 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, etc). After VM was invented, there is really no reason to use it. I don't think newer OSes like Linux implemented this. > Also I think S (setuid but no execute bit) have something to do with file locking >but I'am not shure exactly how it works. On some unix systems S means using mandatory locking (instead of advisory locking). I am not sure about Linux though. > "H. Peter Anvin" wrote: > > > > Followup to: <[EMAIL PROTECTED]> > > By author:Shawn Starr <[EMAIL PROTECTED]> > > In newsgroup: linux.dev.kernel > > > > > > Is this a bug or something thats undocumented somewhere? > > > > > > dT > > > and > > > drwSrwSrwT > > > > > > are these special bits? I'm not aware of +S and +T > > > > > > > It's neither a bug nor undocumented. > > > > "info ls" would have told you the following: > > > > The permissions listed are similar to symbolic mode > > specifications > > (*note Symbolic Modes::.). But `ls' combines multiple bits into > > the third character of each set of permissions as follows: > > `s' > > If the setuid or setgid bit and the corresponding executable > > bit are both set. > > > > `S' > > If the setuid or setgid bit is set but the corresponding > > executable bit is not set. > > > > `t' > > If the sticky bit and the other-executable bit are both set. > > > > `T' > > If the sticky bit is set but the other-executable bit is not > > set. > > > > `x' > > If the executable bit is set and none of the above apply. > > > > `-' > > Otherwise. > > > > -hpa > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
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, etc). After VM was invented, there is really no reason to use it. I don't think newer OSes like Linux implemented this. Also I think S (setuid but no execute bit) have something to do with file locking but I'am not shure exactly how it works. On some unix systems S means using mandatory locking (instead of advisory locking). I am not sure about Linux though. H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Shawn Starr [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Is this a bug or something thats undocumented somewhere? dT and drwSrwSrwT are these special bits? I'm not aware of +S and +T It's neither a bug nor undocumented. info ls would have told you the following: The permissions listed are similar to symbolic mode specifications (*note Symbolic Modes::.). But `ls' combines multiple bits into the third character of each set of permissions as follows: `s' If the setuid or setgid bit and the corresponding executable bit are both set. `S' If the setuid or setgid bit is set but the corresponding executable bit is not set. `t' If the sticky bit and the other-executable bit are both set. `T' If the sticky bit is set but the other-executable bit is not set. `x' If the executable bit is set and none of the above apply. `-' Otherwise. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some experience of linux on a Laptop
> 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 wants to try > and write such a tool 8) "make xconfig" is alerady very nice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some experience of linux on a Laptop
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 wants to try and write such a tool 8) make xconfig is alerady very nice. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CRAK: a process checkpoint/restart kernel module
On Fri, 25 May 2001, Pavel Machek wrote: > > Basically I took three steps to migrate a TCP socket. Assuming A and B > > are the two peers: > > > > 1. shutdown process A while keep B open > > 2. restart A and re-establish the socket which points to B > > 3 . change the socket on B to point to the new location of A > > This assumes both A and B are on same machine, right? No. They can be on different machines. That's why it's called "migration" :-) > > The problem is, during this stage, if B sends packets to A before 3 is > > complete, B's socket will get a RST. In the case of X, if you click or > > move cursor on A's window when A is being migrated, it will crash. > > > You might shutdown machine's networking between checkpoint and > restart. That way, packets are silently lost, and there's no RST to be > generated. > That's what virtual network interface could be used for. Packets sent to A can be queued or discarded, whatever, if we have the control at the interface level. Actually one PhD student in my department has been working on it, and CRAK is just part of the project. > I guess you can't checkpoint/restart when there's remote machine > involved. I was not thinking online games, I was thinking about > tuxracer (game on localhost). localhost is much easier, but the same problem still exists. > -- > 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 Central Research Facilities Department of Computer Science Columbia University New York, NY 10027 Email: [EMAIL PROTECTED] http://www.cs.columbia.edu/~huaz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CRAK: a process checkpoint/restart kernel module
On Fri, 25 May 2001, Pavel Machek wrote: Basically I took three steps to migrate a TCP socket. Assuming A and B are the two peers: 1. shutdown process A while keep B open 2. restart A and re-establish the socket which points to B 3 . change the socket on B to point to the new location of A This assumes both A and B are on same machine, right? No. They can be on different machines. That's why it's called migration :-) The problem is, during this stage, if B sends packets to A before 3 is complete, B's socket will get a RST. In the case of X, if you click or move cursor on A's window when A is being migrated, it will crash. EVIL SOLUTION You might shutdown machine's networking between checkpoint and restart. That way, packets are silently lost, and there's no RST to be generated. /EVIL That's what virtual network interface could be used for. Packets sent to A can be queued or discarded, whatever, if we have the control at the interface level. Actually one PhD student in my department has been working on it, and CRAK is just part of the project. I guess you can't checkpoint/restart when there's remote machine involved. I was not thinking online games, I was thinking about tuxracer (game on localhost). localhost is much easier, but the same problem still exists. -- 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 Central Research Facilities Department of Computer Science Columbia University New York, NY 10027 Email: [EMAIL PROTECTED] http://www.cs.columbia.edu/~huaz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
