igb reset adapter on kernels > 4.14
Hi all Since upgrading my routers from the 4.14 to the 4.19 kernel series, I frequently get into the situation that my second (and also third) nic goes down, with igb :02:00.0 enp2s0: Reset adapter Sometimes, it will come up again, sometimes not. I have googled and got a lot of hits, with no appartently clear fix for this, so I assume it's a kernel bug. In my case, I'm currently running 4.19.31 and the said nic is part of a bridge that also includes a wlan and a tap device. I did not have any issues with this configuration on older kernels for over a year. I also switched the hardware, which did not help. lspci -v reports on the card: 02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) Subsystem: Intel Corporation I210 Gigabit Network Connection Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at fe60 (32-bit, non-prefetchable) [size=128K] I/O ports at 2000 [size=32] Memory at fe62 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable+ Count=5 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-0d-b9-ff-ff-4e-79-0d Capabilities: [1a0] Transaction Processing Hints Kernel driver in use: igb Kernel modules: igb ethtool reports: driver: igb version: 5.4.0-k firmware-version: 0. 6-5 expansion-rom-version: bus-info: :02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes And of course, here is the kernel trace: [88273.078248] [ cut here ] [88273.083042] NETDEV WATCHDOG: enp2s0 (igb): transmit queue 2 timed out [88273.089827] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x1ee/0x200 [88273.098253] Modules linked in: ctr ccm xt_limit nfsd nfs_acl lockd grace sunrpc nf_log_ipv4 nf_log_common xt_LOG ipt_MASQUERADE xt_conntrack iptable_nat nf_nat_ipv4 iptable_filter nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp ipv6 crc_ccitt arc4 amd64_edac_mod kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ath10k_pci crc32c_intel ath10k_core ghash_clmulni_intel sdhci_pci ath pcbc mac80211 cqhci aesni_intel ehci_pci aes_x86_64 sdhci leds_apu xhci_pci crypto_simd ehci_hcd mmc_core fam15h_power cryptd glue_helper igb xhci_hcd k10temp cfg80211 pcspkr rtc_cmos ptp hwmon dca usbcore usb_common ccp fuse [88273.157981] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.31 #1 [88273.164223] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017 [88273.170918] RIP: 0010:dev_watchdog+0x1ee/0x200 [88273.175457] Code: 00 48 63 4d e0 eb 93 4c 89 e7 c6 05 f1 2a b1 00 01 e8 e6 14 fd ff 89 d9 48 89 c2 4c 89 e6 48 c7 c7 38 24 dd 81 e8 02 ef aa ff <0f> 0b eb c0 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 47 08 [88273.194827] RSP: 0018:88811ab03e88 EFLAGS: 00010286 [88273.200160] RAX: RBX: 0002 RCX: [88273.207484] RDX: 00040400 RSI: 00f6 RDI: 0300 [88273.214941] RBP: 888117fd4480 R08: 0266 R09: 0007 [88273.222315] R10: 0082 R11: 824d188d R12: 888117fd4000 [88273.229669] R13: 0002 R14: 82005100 R15: 0001 [88273.236965] FS: () GS:88811ab0() knlGS: [88273.245318] CS: 0010 DS: ES: CR0: 80050033 [88273.251170] CR2: 7f68d06d8000 CR3: 00011332e000 CR4: 000406e0 [88273.258571] Call Trace: [88273.261124] [88273.263204] ? qdisc_reset+0xe0/0xe0 [88273.266841] call_timer_fn+0x2b/0x130 [88273.270620] expire_timers+0x8e/0xe0 [88273.274328] run_timer_softirq+0xb9/0x160 [88273.278480] ? __hrtimer_run_queues+0x133/0x2b0 [88273.283175] ? ktime_get+0x39/0x90 [88273.286655] __do_softirq+0xd7/0x2f8 [88273.290338] irq_exit+0xb2/0xc0 [88273.293559] smp_apic_timer_interrupt+0x79/0x130 [88273.298414] apic_timer_interrupt+0xf/0x20 [88273.302664] [88273.304873] RIP: 0010:cpuidle_enter_state+0xab/0x310 [88273.310016] Code: e8 ca c6 b5 ff 48 89 c3 8b 05 39 7a b9 00 85 c0 0f 8f 33 01 00 00 31 ff e8 92 cf b5 ff 45 84 f6 0f 85 f1 00 00 00 fb 4c 29 fb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff [88273.329275] RSP: 0018:c96a3e90 EFLAGS: 0216 ORIG_RAX: ff13 [88273.337073] RAX: 88811ab20bc0 RBX: 032f0f7e RCX: 001f [88273.344368] RDX: 5048ad789efb RSI: 803d7d59 RDI: [88273.351650] RBP: 0002 R08: 0002 R09: 00020480 [88273.359007] R10: c96a3e78 R11: 2e10 R12:
Re: [BUG] Kernel Panic in squashfs
On Fri, Feb 6, 2015 at 5:55 PM, Tim Tassonis wrote: Hi all Just found out that squashfs panics when compiled in statically instead of as a module, when mounting an sqf file. The sequence I did was: # mkdir /mnt/gaia-ro # mount /gaiarule.sqf /mnt/gaia-ro -t squashfs -o loop Maybe it is of importance that the sqf file is located in the initramfs. The kernel was panicking reliably with different sqf files, on different hardware upon the mount command, with "unable to handle kernel paging request". This was on 3.18.5. As soon as I compiled squashfs as a modules, the problem went away. If you need further details, please cc me directly, as I unsubscribed from the list due to not being able to handle the massive load. What about sharing the actual kernel panic? :-) Well, I was trying to reproduce it. Upgraded to 3.18.6, built the kernel with static squashfs, and now it doesn't panic anymore. Guess some fixes for 3.18.6 fixed this too. If somebody really, really cares, I could go through the whole procedure again with 3.18.6, but I guess, as it's gone now, this would be rather academeic. Bye Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Kernel Panic in squashfs
On Fri, Feb 6, 2015 at 5:55 PM, Tim Tassonis wrote: Hi all Just found out that squashfs panics when compiled in statically instead of as a module, when mounting an sqf file. The sequence I did was: # mkdir /mnt/gaia-ro # mount /gaiarule.sqf /mnt/gaia-ro -t squashfs -o loop Maybe it is of importance that the sqf file is located in the initramfs. The kernel was panicking reliably with different sqf files, on different hardware upon the mount command, with "unable to handle kernel paging request". This was on 3.18.5. As soon as I compiled squashfs as a modules, the problem went away. If you need further details, please cc me directly, as I unsubscribed from the list due to not being able to handle the massive load. What about sharing the actual kernel panic? :-) Well, I will, if somebody bothers to actually look at it. Takes me some time to set everything up again for it. And it would be nice if you could cc me directly in the reply, as already mentioned, I'm not on the list and this copy-paste stuff from marc.info is a bit a nuisance. Bye Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] Kernel Panic in squashfs
Hi all Just found out that squashfs panics when compiled in statically instead of as a module, when mounting an sqf file. The sequence I did was: # mkdir /mnt/gaia-ro # mount /gaiarule.sqf /mnt/gaia-ro -t squashfs -o loop Maybe it is of importance that the sqf file is located in the initramfs. The kernel was panicking reliably with different sqf files, on different hardware upon the mount command, with "unable to handle kernel paging request". This was on 3.18.5. As soon as I compiled squashfs as a modules, the problem went away. If you need further details, please cc me directly, as I unsubscribed from the list due to not being able to handle the massive load. Bye Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Kernel Panic in squashfs
On Fri, Feb 6, 2015 at 5:55 PM, Tim Tassonis st...@decentral.ch wrote: Hi all Just found out that squashfs panics when compiled in statically instead of as a module, when mounting an sqf file. The sequence I did was: # mkdir /mnt/gaia-ro # mount /gaiarule.sqf /mnt/gaia-ro -t squashfs -o loop Maybe it is of importance that the sqf file is located in the initramfs. The kernel was panicking reliably with different sqf files, on different hardware upon the mount command, with unable to handle kernel paging request. This was on 3.18.5. As soon as I compiled squashfs as a modules, the problem went away. If you need further details, please cc me directly, as I unsubscribed from the list due to not being able to handle the massive load. What about sharing the actual kernel panic? :-) Well, I will, if somebody bothers to actually look at it. Takes me some time to set everything up again for it. And it would be nice if you could cc me directly in the reply, as already mentioned, I'm not on the list and this copy-paste stuff from marc.info is a bit a nuisance. Bye Tim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Kernel Panic in squashfs
On Fri, Feb 6, 2015 at 5:55 PM, Tim Tassonis st...@decentral.ch wrote: Hi all Just found out that squashfs panics when compiled in statically instead of as a module, when mounting an sqf file. The sequence I did was: # mkdir /mnt/gaia-ro # mount /gaiarule.sqf /mnt/gaia-ro -t squashfs -o loop Maybe it is of importance that the sqf file is located in the initramfs. The kernel was panicking reliably with different sqf files, on different hardware upon the mount command, with unable to handle kernel paging request. This was on 3.18.5. As soon as I compiled squashfs as a modules, the problem went away. If you need further details, please cc me directly, as I unsubscribed from the list due to not being able to handle the massive load. What about sharing the actual kernel panic? :-) Well, I was trying to reproduce it. Upgraded to 3.18.6, built the kernel with static squashfs, and now it doesn't panic anymore. Guess some fixes for 3.18.6 fixed this too. If somebody really, really cares, I could go through the whole procedure again with 3.18.6, but I guess, as it's gone now, this would be rather academeic. Bye Tim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] Kernel Panic in squashfs
Hi all Just found out that squashfs panics when compiled in statically instead of as a module, when mounting an sqf file. The sequence I did was: # mkdir /mnt/gaia-ro # mount /gaiarule.sqf /mnt/gaia-ro -t squashfs -o loop Maybe it is of importance that the sqf file is located in the initramfs. The kernel was panicking reliably with different sqf files, on different hardware upon the mount command, with unable to handle kernel paging request. This was on 3.18.5. As soon as I compiled squashfs as a modules, the problem went away. If you need further details, please cc me directly, as I unsubscribed from the list due to not being able to handle the massive load. Bye Tim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overlayfs: "filesystem of lowerdir is not supported" on cdrom
On 10/28/2014 11:54 PM, Al Viro wrote: > On Tue, Oct 28, 2014 at 09:13:13PM +, Al Viro wrote: > >> >> We probably ought to split the normal (case-sensitive, no joliet shite) case >> out and leave it with NULL ->s_d_op, but that'll need to be done carefully, >> or isofs_cmp() will blow up on us. > > See if vfs.git#for-linus works for you. > Yes, works for me! Could mount the overlayfs, remove a file, add a file and modify a file. Not the definive stress-test I guess, but it's a start... Took only the following two commits: f643ff550afbc82a2bc7026f4a6d64427e4fbc9 5b71ecfa78271d5c576f17156ed8a53981c1ecb Kind regards Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
overlayfs: "filesystem of lowerdir is not supported" on cdrom
Hi Just installed 3.18-rc2 and tried to test the overlayfs stuff: $ mkdir /ovtmp $ mount -t tmpfs tmpfs /ovtmp/ $ mkdir /ovtmp/work $ mkdir /ovtmp/upper $ mkdir /cdrw $ mount /dev/sr0 /mnt $ mount |egrep "ovtmp|sr0" /dev/sr0 on /mnt type iso9660 (ro,relatime) tmpfs on /ovtmp type tmpfs (rw,relatime) $ mount -t overlayfs overlayfs \ -olowerdir=/mnt,upperdir=/ovtmp/upper,workdir=/ovtmp/work /cdrw mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. $ dmesg |tail [ 3266.793218] overlayfs: filesystem of lowerdir is not supported However, the doc in Documentation/filesystems/overlayfs.txt states: "The lower filesystem can be any filesystem supported by Linux and does not need to be writable. The lower filesystem can even be another overlayfs. The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable." So: Is the documentation wrong, the error message in dmesg wrong, or have missed something completely? Kind regards Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
overlayfs: filesystem of lowerdir is not supported on cdrom
Hi Just installed 3.18-rc2 and tried to test the overlayfs stuff: $ mkdir /ovtmp $ mount -t tmpfs tmpfs /ovtmp/ $ mkdir /ovtmp/work $ mkdir /ovtmp/upper $ mkdir /cdrw $ mount /dev/sr0 /mnt $ mount |egrep ovtmp|sr0 /dev/sr0 on /mnt type iso9660 (ro,relatime) tmpfs on /ovtmp type tmpfs (rw,relatime) $ mount -t overlayfs overlayfs \ -olowerdir=/mnt,upperdir=/ovtmp/upper,workdir=/ovtmp/work /cdrw mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. $ dmesg |tail [ 3266.793218] overlayfs: filesystem of lowerdir is not supported However, the doc in Documentation/filesystems/overlayfs.txt states: The lower filesystem can be any filesystem supported by Linux and does not need to be writable. The lower filesystem can even be another overlayfs. The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable. So: Is the documentation wrong, the error message in dmesg wrong, or have missed something completely? Kind regards Tim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overlayfs: filesystem of lowerdir is not supported on cdrom
On 10/28/2014 11:54 PM, Al Viro wrote: On Tue, Oct 28, 2014 at 09:13:13PM +, Al Viro wrote: We probably ought to split the normal (case-sensitive, no joliet shite) case out and leave it with NULL -s_d_op, but that'll need to be done carefully, or isofs_cmp() will blow up on us. See if vfs.git#for-linus works for you. Yes, works for me! Could mount the overlayfs, remove a file, add a file and modify a file. Not the definive stress-test I guess, but it's a start... Took only the following two commits: f643ff550afbc82a2bc7026f4a6d64427e4fbc9 5b71ecfa78271d5c576f17156ed8a53981c1ecb Kind regards Tim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
Hi Marc What's the point? People are openly hostile to new ideas here. I started out nice and laid out my ideas and you have a bunch of morons who attack anything new. If you think using subjects like "Thinking out of the box" (implicitely calling everybody else narrow-minded) and "vi causes brain damage" is starting out nice, you also got a serious communication problem. Look at the reality of the situation. Linux is free and yey it can't compete with operating systems that are paid for. Maybe the reason is that when someone point out the something is broken all yopu get is justification and excuses and insults. Funny, even Microsoft acknoledges that Linux can very well compete, as does your beloved Novell that just recently bought Suse. Maybe you haven't noticed yet that you're the only one left that thinks Linux can't compete. Think about it. Why did it take 20 years for Linux to fix the RM problem? If you type RM * you expect the files to be gone, not some stupid error that I'm trying to delete too many files. Well, it's not a stupid error, this is called a limit. Other people have already explained to you how the UNIX shell works, so I'm not going to repeat it again. That said, I even would admit that I have been bitten by this limit before (deleting a few thousand bounced mail in a spool directory), So who's fault is that? I say it's a problem with Linux culture. If something is broken you have to justify it instead of fixing it. I use Linux since the mid 90's and remember thousands and thousands of bugs fixed and limits removed. But you must be here longer and have the better view of how "the Linux culture" really works. You guys are trying to may the RM problem MY FAULT because I didn't say it nicely. We'll it doesn't have to be said nicely. If something is broken then it needs fixed regardless of who and how it is pointed out. Nobody denied the limit, you were just pointed out that you don't have a fucking clue what the behavior actually means and where the limit lies. And calling other people brain-damaged at the same time... > So wat does it tell you when something like this is left broken for so long? What it tells me is that the development process is broken. Well, it tells _me_: - It is a limit and not a bug - The limit is not severe, not many people constantly have to delete millions of files in the directory without deleting the directory itself - the limit can be worked around by "find . |xargs \rm" But, as you proved again and again, you're the expert. My rant on VI is to make a point. That point being that when you use an editor that totally sucks then it's going to cause you to write code that sucks. It going to lower your standards. It's going to create a culture where poorly done work is considered acceptable. When you use an editor as poor as vi then the idea that rm * doesn't work becomes acceptable and justifiable, as demonstrated here by people who ACTUALLY DEFENDED IT. You might have wanted to make this point. But all you really showed is that you're an arrogant, ignorant loudmouth, takling about things you have no clue about. I bet you haven't written a single line of decent code in your life. Kind regards Tim - 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: The vi editor causes brain damage
Hi Marc Before everyone gets pissed off and freaks out why don't you ponder the question why rm won't delete all the files in the directory. If you can't grasp that then you're brain damaged. Think big people. Say NO to vi! At first I thought you've got a point here: you definitely _do_ suffer from brain damage. Then again, I know too many people without brain damage that are using vi, so it must me something else. Maybe a car accindent, or your mother drinking a bottle of vodka per day in your pregnancy? Regards Tim - 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: The vi editor causes brain damage
Hi Marc Before everyone gets pissed off and freaks out why don't you ponder the question why rm won't delete all the files in the directory. If you can't grasp that then you're brain damaged. Think big people. Say NO to vi! At first I thought you've got a point here: you definitely _do_ suffer from brain damage. Then again, I know too many people without brain damage that are using vi, so it must me something else. Maybe a car accindent, or your mother drinking a bottle of vodka per day in your pregnancy? Regards Tim - 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: Thinking outside the box on file systems
Hi Marc What's the point? People are openly hostile to new ideas here. I started out nice and laid out my ideas and you have a bunch of morons who attack anything new. If you think using subjects like Thinking out of the box (implicitely calling everybody else narrow-minded) and vi causes brain damage is starting out nice, you also got a serious communication problem. Look at the reality of the situation. Linux is free and yey it can't compete with operating systems that are paid for. Maybe the reason is that when someone point out the something is broken all yopu get is justification and excuses and insults. Funny, even Microsoft acknoledges that Linux can very well compete, as does your beloved Novell that just recently bought Suse. Maybe you haven't noticed yet that you're the only one left that thinks Linux can't compete. Think about it. Why did it take 20 years for Linux to fix the RM problem? If you type RM * you expect the files to be gone, not some stupid error that I'm trying to delete too many files. Well, it's not a stupid error, this is called a limit. Other people have already explained to you how the UNIX shell works, so I'm not going to repeat it again. That said, I even would admit that I have been bitten by this limit before (deleting a few thousand bounced mail in a spool directory), So who's fault is that? I say it's a problem with Linux culture. If something is broken you have to justify it instead of fixing it. I use Linux since the mid 90's and remember thousands and thousands of bugs fixed and limits removed. But you must be here longer and have the better view of how the Linux culture really works. You guys are trying to may the RM problem MY FAULT because I didn't say it nicely. We'll it doesn't have to be said nicely. If something is broken then it needs fixed regardless of who and how it is pointed out. Nobody denied the limit, you were just pointed out that you don't have a fucking clue what the behavior actually means and where the limit lies. And calling other people brain-damaged at the same time... So wat does it tell you when something like this is left broken for so long? What it tells me is that the development process is broken. Well, it tells _me_: - It is a limit and not a bug - The limit is not severe, not many people constantly have to delete millions of files in the directory without deleting the directory itself - the limit can be worked around by find . |xargs \rm But, as you proved again and again, you're the expert. My rant on VI is to make a point. That point being that when you use an editor that totally sucks then it's going to cause you to write code that sucks. It going to lower your standards. It's going to create a culture where poorly done work is considered acceptable. When you use an editor as poor as vi then the idea that rm * doesn't work becomes acceptable and justifiable, as demonstrated here by people who ACTUALLY DEFENDED IT. You might have wanted to make this point. But all you really showed is that you're an arrogant, ignorant loudmouth, takling about things you have no clue about. I bet you haven't written a single line of decent code in your life. Kind regards Tim - 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: Thinking outside the box on file systems
The ACLs that were added to Linux were a step in the right direction but very incomplete. What should be is a complex permission system that would allow fine grained permissions and inherentance masks to control what permission are granted when someone moves new files into a directory. Instead of just root and users there would be mid level roles where users and objects had management authority over parts of the system and the roles can be defined in a very flexible way. For example, rights might change during "business hours". The problem with complex permission systems is, well, they are complex... I'd still go for the UNIX KISS philosophy and the rather easy permission system, as it is easier to manage. Windows has all that great permission stuff, but if you look at the reality, hardly anybody uses it due to its complexity. Tim - 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: Thinking outside the box on file systems
The ACLs that were added to Linux were a step in the right direction but very incomplete. What should be is a complex permission system that would allow fine grained permissions and inherentance masks to control what permission are granted when someone moves new files into a directory. Instead of just root and users there would be mid level roles where users and objects had management authority over parts of the system and the roles can be defined in a very flexible way. For example, rights might change during business hours. The problem with complex permission systems is, well, they are complex... I'd still go for the UNIX KISS philosophy and the rather easy permission system, as it is easier to manage. Windows has all that great permission stuff, but if you look at the reality, hardly anybody uses it due to its complexity. Tim - 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: [git patches] two warning fixes
Linus Torvalds wrote: I think "must_check" is an abomination. It makes the callee dictate what the caller has to do, but dammit, if the callee really "knows" its errors are that serious, it should damn well handle them itself. The whole "sysfs_create_file()" thing is an example of that. If it fails, it fails. The caller can't do anythign about it anyway, except perhaps print a message. Why the hell does such a function have the "right" to dictate what the user should do? Well, that's just how OO fascists think. An object dictates to the user what he/she can do with it, as opposed to the user can do what he wants/needs. Tim - 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: [git patches] two warning fixes
Linus Torvalds wrote: I think must_check is an abomination. It makes the callee dictate what the caller has to do, but dammit, if the callee really knows its errors are that serious, it should damn well handle them itself. The whole sysfs_create_file() thing is an example of that. If it fails, it fails. The caller can't do anythign about it anyway, except perhaps print a message. Why the hell does such a function have the right to dictate what the user should do? Well, that's just how OO fascists think. An object dictates to the user what he/she can do with it, as opposed to the user can do what he wants/needs. Tim - 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
+ printk("Fair Scheduler: Copyright (c) 2007 Red Hat, Inc., Ingo
Molnar\n");
So that's what all the fuss about the staircase scheduler is all about
then! At last, I see your point.
i'd like to give credit to Con Kolivas for the general approach here:
he has proven via RSDL/SD that 'fair scheduling' is possible and that
it results in better desktop scheduling. Kudos Con!
How pathetic can you get?
Tim, really looking forward to the CL final where Liverpool will beat
the shit out of Scum (and there's a lot to be beaten out).
-
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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
+ printk(Fair Scheduler: Copyright (c) 2007 Red Hat, Inc., Ingo Molnar\n); So that's what all the fuss about the staircase scheduler is all about then! At last, I see your point. i'd like to give credit to Con Kolivas for the general approach here: he has proven via RSDL/SD that 'fair scheduling' is possible and that it results in better desktop scheduling. Kudos Con! How pathetic can you get? Tim, really looking forward to the CL final where Liverpool will beat the shit out of Scum (and there's a lot to be beaten out). - 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: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler
Hi Con Just also wanted to throw in my less than two cents: I applied the patch and also have the very strong subjective impression that my system "feels" much more responsive than with stock 2.6.20. Thanks for the great work. Bye Tim - 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: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler
Hi Con Just also wanted to throw in my less than two cents: I applied the patch and also have the very strong subjective impression that my system feels much more responsive than with stock 2.6.20. Thanks for the great work. Bye Tim - 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/
