Re: fbcon: remove soft scrollback code (missing Doc. patch)
Daniel Vetter writes: > Just a quick comment on this: Since most framebuffers are write-combining, > and reads from that tend to be ~3 orders of magnitude slower than writes > (at least on the pile of machines I looked at here, there's big > differences, and some special streaming cpu instructions to make the > reading side not so slow). > > So scrolling by copying tends to be significantly slower than just > redrawing everything. I know this was the case years ago with AGP as iirc, it doubled ( 4x, 8x ) the PCI clock rate but only for writes wasn't it? I thought this was no longer an issue with PCIe, but if it is, then I guess I'll go ahead with cleaning up the dead code and having it re-render with the larger text buffer.
Re: fbcon: remove soft scrollback code (missing Doc. patch)
Geert Uytterhoeven writes: Judging from some of the comments in the code, it looks like you were one of the original authors of fbcon? I haven't been able to find any of these sczbot crash reports, and am not sure how fuzzing syscalls would really affect this code ( it's not really handling a buch of ioctls or otherwise taking arguments from user space ) , but I am a bit confused as to why the softback was implemented the way that it was. vgacon simply copies the main buffer to vram in ->set_origin() and then changes the pointers to operate out of the much larger vram while that virtual terminal is active. If I understand it correctly, it looks like fbcon instead opts to operate out of the main buffer but rescue lines as they are scrolled off and relocate them to the softback buffer. This seems to be rather more convoluted. I'm thinking of re-implementing scrollback more like the way vgacon does it: allocate a big "vram" buffer and operate out of that. Obviously ->scroll() and ->scrolldelta() have to actually repaint the screen rather than simply change the pointer register, but that should be about the only difference. I have also noticed that there was some code to use hardware panning of the video buffer rather than having to do a block bitblt to scroll the contents of the screen, but that it was disabled because virtually no video drivers actually implemented it? That seems like a shame, but if it is so, then there's no sense carrying the dead code so I think I'll clean that up now. Now that I look at it again, everything is simply always redrawn now instead of even doing a simple bitblt. Daniel, you mentioned that almost nobody supports hardware acceleration, but even without any specific hardware support, surely even if bitblt() is implemented just as a memcpy(), it has to be faster than redrawing all of the characters doesn't it? Getting rid of the panning if it isn't generally supported I can see, but I don't understand killing bitblt even if most devices don't accelerate it. In addition, I noticed that ->screen_pos() was changed to just return vc_origin+offset. fbcon is the only console driver to implement ->screenpos() and if not implemented, vt defaults to using vc_visible_origin+offset, so it looks like this function isn't needed at all anymore and ->screen_pos() can be removed from struct consw. Does this make sense or am I talking crazy?
Re: fbcon: remove soft scrollback code (missing Doc. patch)
Linus Torvalds writes: > It really was buggy, with security implications. And we have no maintainers. Could you be more specific? I can't try to fix it if I don't understand what is wrong with it. Are there any bug reports or anything I could look at?
lkml.org issues
Does anyone know where you can report issues on lkml.org? There's a link to have it forward you a copy of mail but it has a capcha and the capha is broken.
Re: fbcon: remove soft scrollback code (missing Doc. patch)
> Could we pause this madness? Scrollback is still useful. I needed it > today... it was too small, so command results I was looking for > already scrolled away, but... life will be really painful with 0 > scrollback. > You'll need it, too... as soon as you get oops and will want to see > errors just prior to that oops. > If it means I get to maintain it... I'm not happy about it but that's > better than no scrollback. Amen! What self respecting admin installs a gui on servers? What do we have to do to get this back in? What was so buggy with this code that it needed to be removed? Why was it such a burden to just leave it be? Now excuse me while I go dust off the old ext2 defrag utility and enjoy watching disk blocks move around the ncurses interface.
mount --move and shared namespaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It seems that mount --move does not work on a shared namespace ( now the default under systemd ), yet you can mount --bind and then umount the original, which seems to amount to exactly the same thing. Why is the direct move not allowed? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJXMRMqAAoJEBB5UWFcu6UWUqEH/1WHjvhn8aDKTkUHt+T8NR+z STybvyZgI/y8Du+O6ikeZ9AEX5aGhaSoz1xTdNbv3QX7NphRDYjO9CJDGhRpXzzt bVpG0+1DORR5w4/7LlhdqKgjt3UFgo5AFQj+S4NAO3G1vlSaXL33YYP+4YP3Vin7 0XKNCCGbEeEbasGTFNTc0mXPrS5GZBDEStJKfCxb6+SIaMDCoovHRNTY1J1RNudM 5fniCpxBewmY7EnMNJ2UOYvuT3gknNBZuzpvMQ6QhLLVi2R0oyrqxuckFgemv6Dw TMDXfH1e3nw2WtcywOKt8zsi6RAfLpikJ3+ZDJkmD9ObiCS1RM/RfkjgHYCXB3Y= =jb7W -END PGP SIGNATURE-
mount --move and shared namespaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It seems that mount --move does not work on a shared namespace ( now the default under systemd ), yet you can mount --bind and then umount the original, which seems to amount to exactly the same thing. Why is the direct move not allowed? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJXMRMqAAoJEBB5UWFcu6UWUqEH/1WHjvhn8aDKTkUHt+T8NR+z STybvyZgI/y8Du+O6ikeZ9AEX5aGhaSoz1xTdNbv3QX7NphRDYjO9CJDGhRpXzzt bVpG0+1DORR5w4/7LlhdqKgjt3UFgo5AFQj+S4NAO3G1vlSaXL33YYP+4YP3Vin7 0XKNCCGbEeEbasGTFNTc0mXPrS5GZBDEStJKfCxb6+SIaMDCoovHRNTY1J1RNudM 5fniCpxBewmY7EnMNJ2UOYvuT3gknNBZuzpvMQ6QhLLVi2R0oyrqxuckFgemv6Dw TMDXfH1e3nw2WtcywOKt8zsi6RAfLpikJ3+ZDJkmD9ObiCS1RM/RfkjgHYCXB3Y= =jb7W -END PGP SIGNATURE-
Re: [RFC PATCH] sg3_utils: Added hybrid information log utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/15/2014 07:46 PM, Phillip Susi wrote: > On 11/25/2014 02:13 PM, Akers, Jason B wrote: >> Hi Phillip, It turns out that this patch was based on an old >> github repository that doesn't appear to be updated. Doug >> Gilbert reached out after the initial RFC and directed us to his >> page (http://sg.danny.cz/sg/) where he has updated sg3_utils >> code. > >> As we continue to work through the feedback from our SSHD kernel >> patches, I'm going to follow up with Doug again on sg3_utils. > > So is there a set of patches that applies to a release from that > web site? Also is the source only released as tarballs? There is > no source repo? Hello. I am still beta testing an SSHD drive and would very much like to get some more information out of its logs and/or manipulate the cache pinned working set. Is there somewhere I can get these patched utilities yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVEMt2AAoJENRVrw2cjl5RR7AH/iOPMYRoT1/gdpdVlbIfCsWw kP9MnaWVTcqT3O1rgKbudFuMqcJGD/ScnZOIsowdnJkKxwWyGUq7w863GFtaPOul o4DBWqLYPYFbmbsgs/meiS3I2qyFrUNGYL0Db8H2mQ2bbaXg59hJ4gO00eSvf8Zm gMOu3njcs3REEfu/QDi2pfJXXlWMAQfgUUomxdGb1HHmnQqR7YGAdakfRXOXfNHk Feu2QtdZTLZPkBYkcNDM22yPDSYOb6LbpbuNTYFUfPfHp8X8aejAV8zdtZx5aH7C ZNA3DEejFqlOltT1fcgTTSb0U0WV/ZcvfTH4g9FCUfx5HOnTI5Oz86He1OthbR0= =YMQp -END PGP SIGNATURE- -- 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: [RFC PATCH] sg3_utils: Added hybrid information log utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/15/2014 07:46 PM, Phillip Susi wrote: On 11/25/2014 02:13 PM, Akers, Jason B wrote: Hi Phillip, It turns out that this patch was based on an old github repository that doesn't appear to be updated. Doug Gilbert reached out after the initial RFC and directed us to his page (http://sg.danny.cz/sg/) where he has updated sg3_utils code. As we continue to work through the feedback from our SSHD kernel patches, I'm going to follow up with Doug again on sg3_utils. So is there a set of patches that applies to a release from that web site? Also is the source only released as tarballs? There is no source repo? Hello. I am still beta testing an SSHD drive and would very much like to get some more information out of its logs and/or manipulate the cache pinned working set. Is there somewhere I can get these patched utilities yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVEMt2AAoJENRVrw2cjl5RR7AH/iOPMYRoT1/gdpdVlbIfCsWw kP9MnaWVTcqT3O1rgKbudFuMqcJGD/ScnZOIsowdnJkKxwWyGUq7w863GFtaPOul o4DBWqLYPYFbmbsgs/meiS3I2qyFrUNGYL0Db8H2mQ2bbaXg59hJ4gO00eSvf8Zm gMOu3njcs3REEfu/QDi2pfJXXlWMAQfgUUomxdGb1HHmnQqR7YGAdakfRXOXfNHk Feu2QtdZTLZPkBYkcNDM22yPDSYOb6LbpbuNTYFUfPfHp8X8aejAV8zdtZx5aH7C ZNA3DEejFqlOltT1fcgTTSb0U0WV/ZcvfTH4g9FCUfx5HOnTI5Oz86He1OthbR0= =YMQp -END PGP SIGNATURE- -- 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: [RFC PATCH] sg3_utils: Added hybrid information log utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/25/2014 02:13 PM, Akers, Jason B wrote: > Hi Phillip, It turns out that this patch was based on an old > github repository that doesn't appear to be updated. Doug Gilbert > reached out after the initial RFC and directed us to his page > (http://sg.danny.cz/sg/) where he has updated sg3_utils code. > > As we continue to work through the feedback from our SSHD kernel > patches, I'm going to follow up with Doug again on sg3_utils. So is there a set of patches that applies to a release from that web site? Also is the source only released as tarballs? There is no source repo? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJUj4DKAAoJENRVrw2cjl5RwEwH/147w+N+z9r3J70AQrLdXgtN mRF2VLEK/v0l7rpnnyiKyL7Trjc3/YXY9tLf3feC225l9UL6K73moLKGWMI+iRU2 xvCWIJKHQyf8E/j6qFqid0G9V/IQNG9vXAZSEmrTcvT5NaEJ0U3kSCKe5w9xEYEE 6SLYTF+FRHkXceloFvW/8PAwj/2K4g/KsZShIS07kdzAh+fIoZM6qQP3XbEK5v1T x+zuFZtIVzVglQmQWF6wAn5pBjHGNLCA1Yw1+Lx3tuJCoVv1B5ze1k0FOnWu6xOQ bjeOQ0cgZOjYGjgywhoJn5hgKxOhfXsNsIhSSqA/SNky4vMOV5gRXKjA2WgHu6g= =7jVR -END PGP SIGNATURE- -- 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: [RFC PATCH] sg3_utils: Added hybrid information log utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/25/2014 02:13 PM, Akers, Jason B wrote: Hi Phillip, It turns out that this patch was based on an old github repository that doesn't appear to be updated. Doug Gilbert reached out after the initial RFC and directed us to his page (http://sg.danny.cz/sg/) where he has updated sg3_utils code. As we continue to work through the feedback from our SSHD kernel patches, I'm going to follow up with Doug again on sg3_utils. So is there a set of patches that applies to a release from that web site? Also is the source only released as tarballs? There is no source repo? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJUj4DKAAoJENRVrw2cjl5RwEwH/147w+N+z9r3J70AQrLdXgtN mRF2VLEK/v0l7rpnnyiKyL7Trjc3/YXY9tLf3feC225l9UL6K73moLKGWMI+iRU2 xvCWIJKHQyf8E/j6qFqid0G9V/IQNG9vXAZSEmrTcvT5NaEJ0U3kSCKe5w9xEYEE 6SLYTF+FRHkXceloFvW/8PAwj/2K4g/KsZShIS07kdzAh+fIoZM6qQP3XbEK5v1T x+zuFZtIVzVglQmQWF6wAn5pBjHGNLCA1Yw1+Lx3tuJCoVv1B5ze1k0FOnWu6xOQ bjeOQ0cgZOjYGjgywhoJn5hgKxOhfXsNsIhSSqA/SNky4vMOV5gRXKjA2WgHu6g= =7jVR -END PGP SIGNATURE- -- 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: [RFC PATCH] sg3_utils: Added hybrid information log utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/29/2014 03:57 PM, Jason B. Akers wrote: > From: Kapil Karkra > > A solid state hybrid drive (SSHD) is a hard drive with a small > embedded NAND. Host drivers can manage this NAND using the commands > defined by SATA 3.2 standard. One SATA command that provides > visibility into the SSHD's cache behavior is get hybrid log > command. This augmentation allows users to issue the command as > follows: > > sg_sat_get_hybrid_log /dev/sdc assuming /dev/sdc is an SSHD. > > patch applies to the following sourcebase from where to clone: > https://github.com/hreinecke/sg3_utils.git I cloned that repo and the patch does not apply cleanly. git am -3 says the referenced blobs are not found and it has conflicts in src/Makefile.am. I manually fixed that up and then it fails to link due to unresolved externals. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJUc85UAAoJENRVrw2cjl5RR3YIAJOF0fcTkF5pM0OIA87hK8k8 ujwflBTy66ZbPzXMD97cTGYQ6gPp3UCeT/ZcElBfrGGAuD5u/ETXMJY7lqAZgYtK bELPv6oLhz3ya2IO442sUlRYO4dVfwhsnak+2rLiQkXCy4WKSJ1EYiMIP/VHj8ne 5e8VYkuc0KamKjvT4v6EwJ7tM0blfJbYgmFGruIxOSgCAo94Zp9thAcctb9PbRex HnPTcnw5cI1sCoLf5fJafhc9w/1H45WjJTnGF7zs4hq/GGsYCwryvI0ovwAzU9ST R3jRvE+70oiyQDsj9EBak63hRYIAd8QzQ3TkCjaM5E1XHSU7vTnxvxAjKb4ZyF4= =a8Vh -END PGP SIGNATURE- -- 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: [RFC PATCH] sg3_utils: Added hybrid information log utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/29/2014 03:57 PM, Jason B. Akers wrote: From: Kapil Karkra kapil.kar...@intel.com A solid state hybrid drive (SSHD) is a hard drive with a small embedded NAND. Host drivers can manage this NAND using the commands defined by SATA 3.2 standard. One SATA command that provides visibility into the SSHD's cache behavior is get hybrid log command. This augmentation allows users to issue the command as follows: sg_sat_get_hybrid_log /dev/sdc assuming /dev/sdc is an SSHD. patch applies to the following sourcebase from where to clone: https://github.com/hreinecke/sg3_utils.git I cloned that repo and the patch does not apply cleanly. git am -3 says the referenced blobs are not found and it has conflicts in src/Makefile.am. I manually fixed that up and then it fails to link due to unresolved externals. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJUc85UAAoJENRVrw2cjl5RR3YIAJOF0fcTkF5pM0OIA87hK8k8 ujwflBTy66ZbPzXMD97cTGYQ6gPp3UCeT/ZcElBfrGGAuD5u/ETXMJY7lqAZgYtK bELPv6oLhz3ya2IO442sUlRYO4dVfwhsnak+2rLiQkXCy4WKSJ1EYiMIP/VHj8ne 5e8VYkuc0KamKjvT4v6EwJ7tM0blfJbYgmFGruIxOSgCAo94Zp9thAcctb9PbRex HnPTcnw5cI1sCoLf5fJafhc9w/1H45WjJTnGF7zs4hq/GGsYCwryvI0ovwAzU9ST R3jRvE+70oiyQDsj9EBak63hRYIAd8QzQ3TkCjaM5E1XHSU7vTnxvxAjKb4ZyF4= =a8Vh -END PGP SIGNATURE- -- 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: [PATCH 00/33] [RFC] Non disruptive application core dump infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/24/2014 5:43 AM, Janani Venkataraman wrote: > Gcore attaches to the process using gdb and runs the gdb gcore > command and then detaches. In gcore the dump cannot be issued from > a signal handler context as fork() is not signal safe and moreover > it is disruptive in You can fork+exec from a signal handler just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMDknAAoJEI5FoCIzSKrwo2QH/RCmAn404PlO6cZLNuQ5PXqc MdR6U62K/BwZo42Fr694FzzjGKwuqx3YHB8gU+tyE26yZ31reFWG8KpdfV46NRYG sEPH/lJOerMXwfbpxE0YFZBow5wZqTg/XsiXMyz8M4/KdMgOgCEqsaG/IRPvK0+B NiaQmFct0Y2onwoy50mrR2sGeKOgA5510osoChCq+TKUrsCJp80jYvz6bVOi6kwY Oi+bAl/tzcQDy7yHkUqYJXYRf3o9jbHqGxnC/IzygOntggqmIiB8ez4ZDZC2YbOl htv0gP/jqZk8Pm3C/gv5S7xhqjy2+yvkWXg7mhsz7gsbSA4K5LXd5bN5ovEBGAw= =JWwx -END PGP SIGNATURE- -- 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: [PATCH 00/33] [RFC] Non disruptive application core dump infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/24/2014 5:43 AM, Janani Venkataraman wrote: Gcore attaches to the process using gdb and runs the gdb gcore command and then detaches. In gcore the dump cannot be issued from a signal handler context as fork() is not signal safe and moreover it is disruptive in You can fork+exec from a signal handler just fine. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMDknAAoJEI5FoCIzSKrwo2QH/RCmAn404PlO6cZLNuQ5PXqc MdR6U62K/BwZo42Fr694FzzjGKwuqx3YHB8gU+tyE26yZ31reFWG8KpdfV46NRYG sEPH/lJOerMXwfbpxE0YFZBow5wZqTg/XsiXMyz8M4/KdMgOgCEqsaG/IRPvK0+B NiaQmFct0Y2onwoy50mrR2sGeKOgA5510osoChCq+TKUrsCJp80jYvz6bVOi6kwY Oi+bAl/tzcQDy7yHkUqYJXYRf3o9jbHqGxnC/IzygOntggqmIiB8ez4ZDZC2YbOl htv0gP/jqZk8Pm3C/gv5S7xhqjy2+yvkWXg7mhsz7gsbSA4K5LXd5bN5ovEBGAw= =JWwx -END PGP SIGNATURE- -- 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: [PATCH 00/33] [RFC] Non disruptive application core dump infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/21/2014 4:17 AM, Karel Zak wrote: > The gencore command looks like a good idea, but why we need the > client-server infrastructure? At least at first glance it seems > like overkill. Yes, the server seems pointless. >> We would like to push this to one of the following packages: a) >> util-linux b) coreutils c) procps-ng > > d) somewhere near to gdb :-) gdb already has such a thing; it's called gcore. Kind of makes this work seem redundant? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTLFSjAAoJEI5FoCIzSKrwuTIH/jGtc3dB1WKgtDSE2wtXXHO0 0WxhWDbVkpJ0Q+tkG/tjw4wudYtEJ+XAHsCIK3vH7OMX7i4PMOLDgjT/FyxTPrWl W+eUCazi4vRPNGscii5mRFlsthgEd2pofotlx5UB7Br9D05/QZqErtEMJMqD935V 94wlvJSvJI0n3hfAUgcM8apxTgxYr/TIPEQPfqLem3xTZIw3lTRic613Qji2Kwif l+kqs0WLy/AHEwBLRrXDQahnv5n2IhOVUn3KDwm9Su56rbrmAF7LAvK0+uxRyoQk IVC5h8BdBQ4QMYl7KYYEPy+n+0Qbe1EQ4tLmYvaEBwXP5c0QDGX0M5VUkko+eGI= =zFoW -END PGP SIGNATURE- -- 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: [PATCH 00/33] [RFC] Non disruptive application core dump infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/21/2014 4:17 AM, Karel Zak wrote: The gencore command looks like a good idea, but why we need the client-server infrastructure? At least at first glance it seems like overkill. Yes, the server seems pointless. We would like to push this to one of the following packages: a) util-linux b) coreutils c) procps-ng d) somewhere near to gdb :-) gdb already has such a thing; it's called gcore. Kind of makes this work seem redundant? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTLFSjAAoJEI5FoCIzSKrwuTIH/jGtc3dB1WKgtDSE2wtXXHO0 0WxhWDbVkpJ0Q+tkG/tjw4wudYtEJ+XAHsCIK3vH7OMX7i4PMOLDgjT/FyxTPrWl W+eUCazi4vRPNGscii5mRFlsthgEd2pofotlx5UB7Br9D05/QZqErtEMJMqD935V 94wlvJSvJI0n3hfAUgcM8apxTgxYr/TIPEQPfqLem3xTZIw3lTRic613Qji2Kwif l+kqs0WLy/AHEwBLRrXDQahnv5n2IhOVUn3KDwm9Su56rbrmAF7LAvK0+uxRyoQk IVC5h8BdBQ4QMYl7KYYEPy+n+0Qbe1EQ4tLmYvaEBwXP5c0QDGX0M5VUkko+eGI= =zFoW -END PGP SIGNATURE- -- 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: [RFC] [PATCH v5 0/3] fadvise: support POSIX_FADV_NOREUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What ever happened to this patch set? It looks like a great idea to me and I'd *really* like to see this flag implemented. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSxdlTAAoJEI5FoCIzSKrw0O0H/3cIe/XvrXvF6qzgHpQPIfnN a+14iqUa5+fNKNRM0Rwk9Tb3EFUjIXKHcRiRzGD9CINVxonBQQME68KA94UxVZIL oul4YMP4dNcBhp8Ux1M80JY3Y/CMSo9SAN1pc7bmIezua/v821vb6wgCamj3EnS5 /Zs51cIWMkRSAr7EVvycI6mI04MzqsEdtGHdI0U6jrLjLLHsEgbuqkBMrc5BNkQ/ 3tD6atY5zNyBIl+RBOvukNoijtEW4Z5OU+zfZHSk/L72yZnl+17nz4mRApmikUDV zhJoCheWqLCLtpg2SxVC/EMUS3TDy3k9+8zQHbRZ3igXP4e58NZFR+XC1JhVonQ= =TqVD -END PGP SIGNATURE- -- 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: [RFC] [PATCH v5 0/3] fadvise: support POSIX_FADV_NOREUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What ever happened to this patch set? It looks like a great idea to me and I'd *really* like to see this flag implemented. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSxdlTAAoJEI5FoCIzSKrw0O0H/3cIe/XvrXvF6qzgHpQPIfnN a+14iqUa5+fNKNRM0Rwk9Tb3EFUjIXKHcRiRzGD9CINVxonBQQME68KA94UxVZIL oul4YMP4dNcBhp8Ux1M80JY3Y/CMSo9SAN1pc7bmIezua/v821vb6wgCamj3EnS5 /Zs51cIWMkRSAr7EVvycI6mI04MzqsEdtGHdI0U6jrLjLLHsEgbuqkBMrc5BNkQ/ 3tD6atY5zNyBIl+RBOvukNoijtEW4Z5OU+zfZHSk/L72yZnl+17nz4mRApmikUDV zhJoCheWqLCLtpg2SxVC/EMUS3TDy3k9+8zQHbRZ3igXP4e58NZFR+XC1JhVonQ= =TqVD -END PGP SIGNATURE- -- 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/
Depreciated and scheduled for removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I swear there was a text file that listed features that were depreciated and scheduled for removal, but now I can not find it. Did it get removed, or am I just daft? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSk2FFAAoJEJrBOlT6nu75KHEH/j/OSxbYRBa79pPlX7ocvL1v m1flj2zBt8HDd9iba0xzwFPwTcEWk9R08E5OcirpfGMWTbJDHvhV017prNr8vcVG Dqg8ffDiqf8VKgzG1t2IGjnVvZk1BQ6i07lbFeyTDFEpvbucHZ7cFzT+0aUF/ZBi x2Y8mIftoCrOdafEXIyj9TaibtTt7RQ8d0iD/42M91nJVfc5m3tLt21wk1GRp6/2 XNQXXo1MXpXf2JmtVcyCHlUGFVkS3bDNJrKfsenMmQZo5jb+HfxvPKoFPhMIFpTj RJvurkNXqQLfp8A18OvUugGoa4V0GYgitm9n1kW7lqA4PLtslymm+b2tGYtWZ8o= =H9KL -END PGP SIGNATURE- -- 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/
Depreciated and scheduled for removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I swear there was a text file that listed features that were depreciated and scheduled for removal, but now I can not find it. Did it get removed, or am I just daft? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSk2FFAAoJEJrBOlT6nu75KHEH/j/OSxbYRBa79pPlX7ocvL1v m1flj2zBt8HDd9iba0xzwFPwTcEWk9R08E5OcirpfGMWTbJDHvhV017prNr8vcVG Dqg8ffDiqf8VKgzG1t2IGjnVvZk1BQ6i07lbFeyTDFEpvbucHZ7cFzT+0aUF/ZBi x2Y8mIftoCrOdafEXIyj9TaibtTt7RQ8d0iD/42M91nJVfc5m3tLt21wk1GRp6/2 XNQXXo1MXpXf2JmtVcyCHlUGFVkS3bDNJrKfsenMmQZo5jb+HfxvPKoFPhMIFpTj RJvurkNXqQLfp8A18OvUugGoa4V0GYgitm9n1kW7lqA4PLtslymm+b2tGYtWZ8o= =H9KL -END PGP SIGNATURE- -- 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: OOPS: Bluetooth: Store RFCOMM address information in its own socket structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2013 2:53 AM, Marcel Holtmann wrote: > fix for this is already in John’s wireless tree. On a side note, > the bisect is correct, but it is not the patch that broke it. It is > just the patch that uncovered it. Great, thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjMp0AAoJEJrBOlT6nu75SVcIAIdHUznWh7VjtCEebcF+LzGK DGPReiaaRqHJMtd02Oka/3ARxwv9F2y8V/eYK9RIrE+6Wbi3uSOueqgWlz6mZQoo cXNceyZngmwBmvQZJyDa3Eza/D/SBXclkkZu5F0J8umlY2y59FWNk2mBLJCYGJbB o+SQgP6lwgUsB92PWLUJ4khd/oqsWYb9t5d2TJO1uMKCy2Gzr4y5EjXfoe7xluIw UkzxW1TDO3bwBUlzB8u7bmJLt52D3+n2Tmc6YC819R67t/BqKDjbG+/kocEizrL5 w7QjsU0/HJw8b0E3jx3Y87z0fCdEAL2RibxUUuG5MIPjrFsh4QqDopqZ71+mbc4= =G8YC -END PGP SIGNATURE- -- 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: OOPS: Bluetooth: Store RFCOMM address information in its own socket structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2013 2:53 AM, Marcel Holtmann wrote: fix for this is already in John’s wireless tree. On a side note, the bisect is correct, but it is not the patch that broke it. It is just the patch that uncovered it. Great, thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjMp0AAoJEJrBOlT6nu75SVcIAIdHUznWh7VjtCEebcF+LzGK DGPReiaaRqHJMtd02Oka/3ARxwv9F2y8V/eYK9RIrE+6Wbi3uSOueqgWlz6mZQoo cXNceyZngmwBmvQZJyDa3Eza/D/SBXclkkZu5F0J8umlY2y59FWNk2mBLJCYGJbB o+SQgP6lwgUsB92PWLUJ4khd/oqsWYb9t5d2TJO1uMKCy2Gzr4y5EjXfoe7xluIw UkzxW1TDO3bwBUlzB8u7bmJLt52D3+n2Tmc6YC819R67t/BqKDjbG+/kocEizrL5 w7QjsU0/HJw8b0E3jx3Y87z0fCdEAL2RibxUUuG5MIPjrFsh4QqDopqZ71+mbc4= =G8YC -END PGP SIGNATURE- -- 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/
OOPS: Bluetooth: Store RFCOMM address information in its own socket structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Bisected an OOPS to this commit: commit 94a86df01082557e2de45865e538d7fb6c46231c Author: Marcel Holtmann Date: Sun Oct 13 10:34:02 2013 -0700 Bluetooth: Store RFCOMM address information in its own socket structure The address information of RFCOMM sockets should be stored in its own socket structure. Trying to generalize them is not helpful since different transports have different address types. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg OOPS looks like: [ 16.636145] BUG: unable to handle kernel paging request at 00268333770b [ 16.637771] IP: [] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm] [ 16.639350] PGD 0 [ 16.640875] Oops: [#11] SMP [ 16.642394] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec joydev snd_hwdep snd_pcm snd_page_alloc snd_seq_midi radeon snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore ttm dm_multipath scsi_dh drm_kms_helper microcode(+) drm btusb i2c_algo_bit lpc_ich psmouse wmi serio_raw bnep rfcomm bluetooth binfmt_misc btrfs xor raid6_pq libcrc32c hid_generic hid_microsoft usbhid hid e1000e ahci libahci ptp pps_core [ 16.645718] CPU: 1 PID: 968 Comm: bluetoothd Tainted: G D 3.12.0+ #74 [ 16.647369] Hardware name: System manufacturer System Product Name/P8P67 PRO REV 3.1, BIOS 1904 08/15/2011 [ 16.649030] task: 8801262d8000 ti: 8800c772c000 task.ti: 8800c772c000 [ 16.650693] RIP: 0010:[] [] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm] [ 16.652372] RSP: 0018:8800c772df08 EFLAGS: 00010246 [ 16.654118] RAX: 00268333770b RBX: 8800c9156080 RCX: 7fff67e9cd98 [ 16.655800] RDX: 0003 RSI: 0012 RDI: 8800c9156080 [ 16.657445] RBP: 8800c772df38 R08: 7fff67e9cd9c R09: 7fff67e9d018 [ 16.659055] R10: 7fff67e9cd98 R11: 0202 R12: 880036dbd800 [ 16.660624] R13: 7fff67e9cd98 R14: 0003 R15: 7fff67e9cd9c [ 16.662190] FS: 7f1cfe1a1740() GS:88012f48() knlGS: [ 16.663742] CS: 0010 DS: ES: CR0: 80050033 [ 16.665284] CR2: 00268333770b CR3: c746b000 CR4: 000407e0 [ 16.666823] Stack: [ 16.668353] 00038800c772df30 8800c9156080 0012 0003 [ 16.669906] 7fff67e9cd98 7fff67e9cd9c 8800c772df78 8155ff38 [ 16.671460] 0001 7fff67e9d018 0001 [ 16.673016] Call Trace: [ 16.674562] [] SyS_getsockopt+0x68/0xd0 [ 16.676111] [] system_call_fastpath+0x1a/0x1f [ 16.677651] Code: 00 4c 89 e7 e8 1a bf 38 e1 45 89 f1 48 83 c4 08 44 89 c8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 44 00 00 49 8b 84 24 e8 02 00 00 <48> 8b 18 4c 89 c0 e8 dd 91 14 e1 85 c0 49 89 d7 41 b9 f2 ff ff [ 16.679393] RIP [] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm] [ 16.681022] RSP [ 16.682639] CR2: 00268333770b [ 16.684262] ---[ end trace a5f6978e71640635 ]--- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSjCplAAoJEJrBOlT6nu75RRQH/jTyamvlWeLBWMa4e97WiRWL 4oaWn0nU49CcU3RGP8B6lxb0NyqSVng48UT1gwcktDU5SXZs9aT92pU6HKSdCMsh 4qRjGLcLdAtr8b6sp9wf5nZlMZud7eJbr+Bs/O9zGACuvceXdXfJgub4tMm8go9E VThfT5cECmNo8m/3m4wcWSxjOXdfkaEMqeeJFSQRBgOOwIYNvz8Cq4jKD17F0M3A Kv1rtBS0706kI3FMOHyyrIeLxc6RDe7WojX1RJr3gIME5sOI7cF8J6b8YbK43uOI qffp1Tgtq7ZU7eFmuTt7OeKj961pzGri1efeJxsf1cQn0iZXl+lhMQIGM/J3tg8= =b2nC -END PGP SIGNATURE- -- 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/
OOPS: Bluetooth: Store RFCOMM address information in its own socket structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Bisected an OOPS to this commit: commit 94a86df01082557e2de45865e538d7fb6c46231c Author: Marcel Holtmann mar...@holtmann.org Date: Sun Oct 13 10:34:02 2013 -0700 Bluetooth: Store RFCOMM address information in its own socket structure The address information of RFCOMM sockets should be stored in its own socket structure. Trying to generalize them is not helpful since different transports have different address types. Signed-off-by: Marcel Holtmann mar...@holtmann.org Signed-off-by: Johan Hedberg johan.hedb...@intel.com OOPS looks like: [ 16.636145] BUG: unable to handle kernel paging request at 00268333770b [ 16.637771] IP: [a01d7c78] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm] [ 16.639350] PGD 0 [ 16.640875] Oops: [#11] SMP [ 16.642394] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec joydev snd_hwdep snd_pcm snd_page_alloc snd_seq_midi radeon snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore ttm dm_multipath scsi_dh drm_kms_helper microcode(+) drm btusb i2c_algo_bit lpc_ich psmouse wmi serio_raw bnep rfcomm bluetooth binfmt_misc btrfs xor raid6_pq libcrc32c hid_generic hid_microsoft usbhid hid e1000e ahci libahci ptp pps_core [ 16.645718] CPU: 1 PID: 968 Comm: bluetoothd Tainted: G D 3.12.0+ #74 [ 16.647369] Hardware name: System manufacturer System Product Name/P8P67 PRO REV 3.1, BIOS 1904 08/15/2011 [ 16.649030] task: 8801262d8000 ti: 8800c772c000 task.ti: 8800c772c000 [ 16.650693] RIP: 0010:[a01d7c78] [a01d7c78] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm] [ 16.652372] RSP: 0018:8800c772df08 EFLAGS: 00010246 [ 16.654118] RAX: 00268333770b RBX: 8800c9156080 RCX: 7fff67e9cd98 [ 16.655800] RDX: 0003 RSI: 0012 RDI: 8800c9156080 [ 16.657445] RBP: 8800c772df38 R08: 7fff67e9cd9c R09: 7fff67e9d018 [ 16.659055] R10: 7fff67e9cd98 R11: 0202 R12: 880036dbd800 [ 16.660624] R13: 7fff67e9cd98 R14: 0003 R15: 7fff67e9cd9c [ 16.662190] FS: 7f1cfe1a1740() GS:88012f48() knlGS: [ 16.663742] CS: 0010 DS: ES: CR0: 80050033 [ 16.665284] CR2: 00268333770b CR3: c746b000 CR4: 000407e0 [ 16.666823] Stack: [ 16.668353] 00038800c772df30 8800c9156080 0012 0003 [ 16.669906] 7fff67e9cd98 7fff67e9cd9c 8800c772df78 8155ff38 [ 16.671460] 0001 7fff67e9d018 0001 [ 16.673016] Call Trace: [ 16.674562] [8155ff38] SyS_getsockopt+0x68/0xd0 [ 16.676111] [81672356] system_call_fastpath+0x1a/0x1f [ 16.677651] Code: 00 4c 89 e7 e8 1a bf 38 e1 45 89 f1 48 83 c4 08 44 89 c8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 44 00 00 49 8b 84 24 e8 02 00 00 48 8b 18 4c 89 c0 e8 dd 91 14 e1 85 c0 49 89 d7 41 b9 f2 ff ff [ 16.679393] RIP [a01d7c78] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm] [ 16.681022] RSP 8800c772df08 [ 16.682639] CR2: 00268333770b [ 16.684262] ---[ end trace a5f6978e71640635 ]--- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSjCplAAoJEJrBOlT6nu75RRQH/jTyamvlWeLBWMa4e97WiRWL 4oaWn0nU49CcU3RGP8B6lxb0NyqSVng48UT1gwcktDU5SXZs9aT92pU6HKSdCMsh 4qRjGLcLdAtr8b6sp9wf5nZlMZud7eJbr+Bs/O9zGACuvceXdXfJgub4tMm8go9E VThfT5cECmNo8m/3m4wcWSxjOXdfkaEMqeeJFSQRBgOOwIYNvz8Cq4jKD17F0M3A Kv1rtBS0706kI3FMOHyyrIeLxc6RDe7WojX1RJr3gIME5sOI7cF8J6b8YbK43uOI qffp1Tgtq7ZU7eFmuTt7OeKj961pzGri1efeJxsf1cQn0iZXl+lhMQIGM/J3tg8= =b2nC -END PGP SIGNATURE- -- 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: [PATCH 2/2] libata: avoid waking disk to check power
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:39 PM, Aaron Lu wrote: > If the disk entered sleep mode due to runtime PM, then udisks can > easily tell by checking the device's runtime status and not send > out the query. > > But if the disk entered sleep mode due to other reason, the patch > may be necessary. So what's your scenario? I am planning on patching udisks to do that as well, but if you have a current udsisk or manually run hdparm -C, or some other program is doing something similar, then this patch takes care of that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFvFAAoJEJrBOlT6nu75hcYH/0YsYcs3u9Dmuqq9z5kFXL3k C4xYQtvOxw2z+B/vEFzdym5J3ZfVyT4+ZdcHMvRgbbPH+R8/rzNC+F3OjdGtDIRA 5EUo0BUT2IfY0Yp2SzP44+8aRC4iF5jLLcH9XJKQx7WHedJQ7puCgJXXHAgUhpwW 52gJ0UEHnjlBgjwxY9RKqppnJs57x2VwgwR2BeFns6Hcry0S0HN0U4gwROmb1GZR kjpOUUYHb3MH/gfzCaY97t0duAAp7jzZeOIuu+XHfkyV3APwsnbasLOOoRYtpbvQ M++xmYQdNAh2DcZLEmAo6H6HLB/Z5d9K0+SKUFnsKHFaUCH0GPHm8SZ7E/NN7ig= =7c7v -END PGP SIGNATURE- -- 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: [PATCH 1/2] libata: use sleep instead of standby command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:23 PM, Aaron Lu wrote: > I suppose this is mainly for runtime PM? Since for system > suspend/hibernation, the disk and its controller will be powered > off anyway. Yes, or the second patch also helps when one manually issues hdparm - -Y, which otherwise will cause the drive to be woken up to answer the CHECK POWER command, which udisks issues to decide if it should skip polling the SMART status of the drive. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFpOAAoJEJrBOlT6nu75JdwIALFvwncNyf1ENxnIho2Y3CXC N6BpHQ7CzD1tap/5ybSFPBvUvJfyC/UPAY69bjldOtbwnArDIWRFqEWW7JWm6G0z J1C5MMCIRHSuRo4RbN/rnsPQFsaFJy0Z5kJ0uXX+aOrZwEov5vo2MEuj/DEdCBDC SKpYkogDlSHTNhFsaEF5iJiJlLU9FF5pEM6S6P0/+Z+SrZ5PVCDOm9rK+oeqrn0U TBX5tKPxWRSjJ/2F094DYia5l8ODNgzl1gPDXA50a+A4M0CZi3d5Liz5Ctfnv88A ac5cG8Ae8MDss0kJmSMCuRwkKVIROM3qMxf1wDWjBwm3eCTAJV1gxRYSN0adOvc= =Rfny -END PGP SIGNATURE- -- 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/
[PATCH 2/2] libata: avoid waking disk to check power
When a disk is in SLEEP mode it can not respond to commands,
including the CHECK POWER command. Instead of waking up the
sleeping disk, fake the reply to the CHECK POWER command to
indicate the disk is in standby mode. This prevents udisks
from waking up sleeping disks when it polls to see if they
are awake or not before trying to read their smart status.
Signed-off-by: Phillip Susi
---
drivers/ata/libata-core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 83b1a9f..573d151 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5084,6 +5084,13 @@ void ata_qc_issue(struct ata_queued_cmd *qc)
/* if device is sleeping, schedule reset and abort the link */
if (unlikely(qc->dev->flags & ATA_DFLAG_SLEEPING)) {
+ if (unlikely(qc->tf.command == ATA_CMD_CHK_POWER))
+ {
+ /* fake reply to avoid waking drive */
+ qc->result_tf.nsect = 0;
+ ata_qc_complete(qc);
+ return;
+ }
link->eh_info.action |= ATA_EH_RESET;
ata_ehi_push_desc(>eh_info, "waking up from sleep");
ata_link_abort(link);
--
1.8.3.2
--
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/
[PATCH 1/2] libata: use sleep instead of standby command
The ATA SLEEP mode saves some more power than SUSPEND, and has basically the same recovery time, so use it instead. Signed-off-by: Phillip Susi --- drivers/ata/libata-scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 97a0cef..79b75fd 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1362,8 +1362,8 @@ static unsigned int ata_scsi_start_stop_xlat(struct ata_queued_cmd *qc) system_entering_hibernation()) goto skip; - /* Issue ATA STANDBY IMMEDIATE command */ - tf->command = ATA_CMD_STANDBYNOW1; + /* Issue ATA SLEEP command */ + tf->command = ATA_CMD_SLEEP; } /* -- 1.8.3.2 -- 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/
[PATCH 1/2] libata: use sleep instead of standby command
The ATA SLEEP mode saves some more power than SUSPEND, and has basically the same recovery time, so use it instead. Signed-off-by: Phillip Susi ps...@ubuntu.com --- drivers/ata/libata-scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 97a0cef..79b75fd 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1362,8 +1362,8 @@ static unsigned int ata_scsi_start_stop_xlat(struct ata_queued_cmd *qc) system_entering_hibernation()) goto skip; - /* Issue ATA STANDBY IMMEDIATE command */ - tf-command = ATA_CMD_STANDBYNOW1; + /* Issue ATA SLEEP command */ + tf-command = ATA_CMD_SLEEP; } /* -- 1.8.3.2 -- 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/
[PATCH 2/2] libata: avoid waking disk to check power
When a disk is in SLEEP mode it can not respond to commands,
including the CHECK POWER command. Instead of waking up the
sleeping disk, fake the reply to the CHECK POWER command to
indicate the disk is in standby mode. This prevents udisks
from waking up sleeping disks when it polls to see if they
are awake or not before trying to read their smart status.
Signed-off-by: Phillip Susi ps...@ubuntu.com
---
drivers/ata/libata-core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 83b1a9f..573d151 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5084,6 +5084,13 @@ void ata_qc_issue(struct ata_queued_cmd *qc)
/* if device is sleeping, schedule reset and abort the link */
if (unlikely(qc-dev-flags ATA_DFLAG_SLEEPING)) {
+ if (unlikely(qc-tf.command == ATA_CMD_CHK_POWER))
+ {
+ /* fake reply to avoid waking drive */
+ qc-result_tf.nsect = 0;
+ ata_qc_complete(qc);
+ return;
+ }
link-eh_info.action |= ATA_EH_RESET;
ata_ehi_push_desc(link-eh_info, waking up from sleep);
ata_link_abort(link);
--
1.8.3.2
--
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: [PATCH 1/2] libata: use sleep instead of standby command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:23 PM, Aaron Lu wrote: I suppose this is mainly for runtime PM? Since for system suspend/hibernation, the disk and its controller will be powered off anyway. Yes, or the second patch also helps when one manually issues hdparm - -Y, which otherwise will cause the drive to be woken up to answer the CHECK POWER command, which udisks issues to decide if it should skip polling the SMART status of the drive. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFpOAAoJEJrBOlT6nu75JdwIALFvwncNyf1ENxnIho2Y3CXC N6BpHQ7CzD1tap/5ybSFPBvUvJfyC/UPAY69bjldOtbwnArDIWRFqEWW7JWm6G0z J1C5MMCIRHSuRo4RbN/rnsPQFsaFJy0Z5kJ0uXX+aOrZwEov5vo2MEuj/DEdCBDC SKpYkogDlSHTNhFsaEF5iJiJlLU9FF5pEM6S6P0/+Z+SrZ5PVCDOm9rK+oeqrn0U TBX5tKPxWRSjJ/2F094DYia5l8ODNgzl1gPDXA50a+A4M0CZi3d5Liz5Ctfnv88A ac5cG8Ae8MDss0kJmSMCuRwkKVIROM3qMxf1wDWjBwm3eCTAJV1gxRYSN0adOvc= =Rfny -END PGP SIGNATURE- -- 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: [PATCH 2/2] libata: avoid waking disk to check power
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2013 09:39 PM, Aaron Lu wrote: If the disk entered sleep mode due to runtime PM, then udisks can easily tell by checking the device's runtime status and not send out the query. But if the disk entered sleep mode due to other reason, the patch may be necessary. So what's your scenario? I am planning on patching udisks to do that as well, but if you have a current udsisk or manually run hdparm -C, or some other program is doing something similar, then this patch takes care of that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSeFvFAAoJEJrBOlT6nu75hcYH/0YsYcs3u9Dmuqq9z5kFXL3k C4xYQtvOxw2z+B/vEFzdym5J3ZfVyT4+ZdcHMvRgbbPH+R8/rzNC+F3OjdGtDIRA 5EUo0BUT2IfY0Yp2SzP44+8aRC4iF5jLLcH9XJKQx7WHedJQ7puCgJXXHAgUhpwW 52gJ0UEHnjlBgjwxY9RKqppnJs57x2VwgwR2BeFns6Hcry0S0HN0U4gwROmb1GZR kjpOUUYHb3MH/gfzCaY97t0duAAp7jzZeOIuu+XHfkyV3APwsnbasLOOoRYtpbvQ M++xmYQdNAh2DcZLEmAo6H6HLB/Z5d9K0+SKUFnsKHFaUCH0GPHm8SZ7E/NN7ig= =7c7v -END PGP SIGNATURE- -- 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: block layer runtime pm and udisks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have been trying out the new block layer runtime pm, and run into a problem: udisks keeps waking up the disk. Every 10 minutes it tries to poll the SMART status of the drive, but it does first issue an ata CHECK POWER command to see if it is in standby, and skips the check to avoid waking the disk. The problem with runtime pm is that *any* request brings the drive out of suspend, and the suspend wake path forces the drive to spin up by issuing a verify command on sector 0. Is there a reason that the wakeup path forces the drive to spin up, or could this be removed and rely on the drive waking up automatically if the request requires it? Or would it be possible to notice that the command being sent is a check power command, and fake the reply instead of resuming the device? Or does udisks just need to check the runtime pm status before trying the check power command? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSVgWPAAoJEJrBOlT6nu75k/cH+gMAb9YtMS21rEt94umJpBYj BcNoyGoK39tAKZHW7pXfP2hRIm1+kPTPi44Wp7kQHu7m6BSp4YetmDkqjNv+6yAy 8SUvPcqRsJVbF1oBXN09phBEnk/JfxqID7n6hB1lT6NqYV72VVVUEUOlnSnpHtDJ gszV+TLH37uhd5/KiDFja3J2bJC0R/klzDF1x1clc53tGJd1NZ+h9tZZBLszIdnS EnjukLA02Q7ooq+445WyWth2cypTXKfRbigZW+FfCI3hfAKOShVevodlGmmrQb7Z 0xzhSoO5JTpNqJPLaNL3+JZFdXwANd+7PuO9v2XVKKUkydQ9+Vl4CfydSFhqo5U= =iuSZ -END PGP SIGNATURE- -- 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: block layer runtime pm and udisks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have been trying out the new block layer runtime pm, and run into a problem: udisks keeps waking up the disk. Every 10 minutes it tries to poll the SMART status of the drive, but it does first issue an ata CHECK POWER command to see if it is in standby, and skips the check to avoid waking the disk. The problem with runtime pm is that *any* request brings the drive out of suspend, and the suspend wake path forces the drive to spin up by issuing a verify command on sector 0. Is there a reason that the wakeup path forces the drive to spin up, or could this be removed and rely on the drive waking up automatically if the request requires it? Or would it be possible to notice that the command being sent is a check power command, and fake the reply instead of resuming the device? Or does udisks just need to check the runtime pm status before trying the check power command? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSVgWPAAoJEJrBOlT6nu75k/cH+gMAb9YtMS21rEt94umJpBYj BcNoyGoK39tAKZHW7pXfP2hRIm1+kPTPi44Wp7kQHu7m6BSp4YetmDkqjNv+6yAy 8SUvPcqRsJVbF1oBXN09phBEnk/JfxqID7n6hB1lT6NqYV72VVVUEUOlnSnpHtDJ gszV+TLH37uhd5/KiDFja3J2bJC0R/klzDF1x1clc53tGJd1NZ+h9tZZBLszIdnS EnjukLA02Q7ooq+445WyWth2cypTXKfRbigZW+FfCI3hfAKOShVevodlGmmrQb7Z 0xzhSoO5JTpNqJPLaNL3+JZFdXwANd+7PuO9v2XVKKUkydQ9+Vl4CfydSFhqo5U= =iuSZ -END PGP SIGNATURE- -- 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/
Tracking down a workqueue io source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I worked up some patches to use the ata SLEEP command instead of STANDBY to save more power, but I have found that something in the kernel keeps issuing a request to the disk ( no mounted filesystems on it ) every 10 minutes. This request resets the link bringing the disk back up to STANDBY mode. blktrace shows the process name is "pool" so I guess it is a work queue item? Inserting a dump_stack() was not helpful. How can I track down the source of this request? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSQzETAAoJEJrBOlT6nu75Pu0IAMOSNFLbklwCjmVMFZjuQk2x zrc6xOfPPmPsFqHUPG1TaoSUgzGJXsbZLUeaVFV2ZEIOFJPVl8Vn4Izkzyemk9dp xtgbtECLMCMZujpqGpL6UwBwBepUfDvoRSpdpcjZ28XByrXS1V8SrQtBw/4HtnDm Pkmf2MXxlqGDhAxCCuKHfnvjlP2pjfEt8teFH9Vsj4znMJw4BUC8IOepDATwbGd3 WEEv5kqmN27K7ZiEE3zo3jaQMlUtWrJwdyU+1zwvvdTpos/USdem9P4n80s5+CYm S7e0awRKOjleEZnozyNU9VO5tLViuKyp2096/6+gvna7MIE/Mgj7aWI/S4+A28c= =f2IA -END PGP SIGNATURE- -- 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/
Tracking down a workqueue io source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I worked up some patches to use the ata SLEEP command instead of STANDBY to save more power, but I have found that something in the kernel keeps issuing a request to the disk ( no mounted filesystems on it ) every 10 minutes. This request resets the link bringing the disk back up to STANDBY mode. blktrace shows the process name is pool so I guess it is a work queue item? Inserting a dump_stack() was not helpful. How can I track down the source of this request? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSQzETAAoJEJrBOlT6nu75Pu0IAMOSNFLbklwCjmVMFZjuQk2x zrc6xOfPPmPsFqHUPG1TaoSUgzGJXsbZLUeaVFV2ZEIOFJPVl8Vn4Izkzyemk9dp xtgbtECLMCMZujpqGpL6UwBwBepUfDvoRSpdpcjZ28XByrXS1V8SrQtBw/4HtnDm Pkmf2MXxlqGDhAxCCuKHfnvjlP2pjfEt8teFH9Vsj4znMJw4BUC8IOepDATwbGd3 WEEv5kqmN27K7ZiEE3zo3jaQMlUtWrJwdyU+1zwvvdTpos/USdem9P4n80s5+CYm S7e0awRKOjleEZnozyNU9VO5tLViuKyp2096/6+gvna7MIE/Mgj7aWI/S4+A28c= =f2IA -END PGP SIGNATURE- -- 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: [RFC PATCH v2 00/15][Sorted-buddy] mm: Memory Power Management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/19/2013 3:12 AM, Srivatsa S. Bhat wrote: > But going further, as I had mentioned in my TODO list, we can be > smarter than this while doing compaction to evacuate memory regions > - we can choose to migrate only the active pages, and leave the > inactive pages alone. Because, the goal is to actually consolidate > the *references* and not necessarily the *allocations* themselves. That would help with keeping references compact to allow use of the low power states, but it would also be nice to keep allocations compact, and completely power off a bank of ram with no allocations. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRpQ7EAAoJEJrBOlT6nu75wqYH/Aq18xGwk3QCJPEBb3BQX4be NY0JfHH9sHE7CFH4t13qpwNj/+N73xBg+TumY2qekUxqfwYSRo3hDhPRonlW/eDI X2AaEGDs8+aQT+QY8bAZnZFHFX8ZayNYOsNCewEV8djZDll2l+fOaFjVfZAwuQLK KtsMxjhlTzqMleRxVpZFLtVPG4GzLRITifKlBRQ+ffrO1zTTMI7glvM+IygIa5vS ajOCI0Nis1Rst2cOsrxfWc+DKN+gnI6c/qTsHarPD5zda1AFwe9DzWQ7EGiqnbJq 39vJmGIsspwrEPbaK0VX5dVYp85Bvd03EudeEish4EHVmH+hphpFokxoypRJePg= =Flf3 -END PGP SIGNATURE- -- 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: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jens, did this get lost in the shuffle, or just miss the window for 3.10 and will go in 3.11? On 4/4/2013 4:30 PM, Phillip Susi wrote: >> I have not tested it yet, but I am pretty sure it won't work. >> It looks like the patch changes the BLKRRPART path to go ahead >> and remove existing partitions when GENHD_FL_NO_PARTSCAN is set. >> loop doesn't issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so >> this won't help. I think loop needs to set GENHD_FL_NO_PARTSCAN >> and then issue the ioctl regardless of the LO_FLAGS_PARTSCAN flag >> to get the partitions to be removed. I will try to test >> tonight. > > After testing, my initial thoughts appeared to have been correct. > I had to modify the patch as follows. To test, simply do: > > truncate -s 10m img losetup /dev/loop0 img parted /dev/loop0 > mklabel msdos mkpart primary ext2 1m 2m quit ls /dev/loop0* > > Note the /dev/loop0p1 node. Run losetup -d /dev/loop0 and see if > it is still there. > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRpMRWAAoJEJrBOlT6nu75yUYH/1PSNmTOBYgvEqQclWPBTd8n Fm95yILcIlJWdUr3gUvQmjBax1NzKnG3NZ2U4hucpCcJH4FkHSTTFl5uZ3wU1B/Q nvuQoSqYXVP+V9PVSTsUsxOI4Mvw5YP5sFwSdwRKpkCldXOuHrRZsuccFtkQducU AIij42jvI1un+/qc6NLW+/S+rcLGUj21boPmX3g80km1De9QMrYrbGAAEbFO3rrq fzsvGuVvOroGppLGpze4iMDn060Lxrw6//KDGtiUBIeD8kZCFGkBh1KupHqLLzXm gmfdlHIqAR5uWB29m9TOlRbHPzdeQutwt8zL2LOYlCft5OiBIOW8dT8EFkl2Buw= =7BGq -END PGP SIGNATURE- -- 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: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jens, did this get lost in the shuffle, or just miss the window for 3.10 and will go in 3.11? On 4/4/2013 4:30 PM, Phillip Susi wrote: I have not tested it yet, but I am pretty sure it won't work. It looks like the patch changes the BLKRRPART path to go ahead and remove existing partitions when GENHD_FL_NO_PARTSCAN is set. loop doesn't issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so this won't help. I think loop needs to set GENHD_FL_NO_PARTSCAN and then issue the ioctl regardless of the LO_FLAGS_PARTSCAN flag to get the partitions to be removed. I will try to test tonight. After testing, my initial thoughts appeared to have been correct. I had to modify the patch as follows. To test, simply do: truncate -s 10m img losetup /dev/loop0 img parted /dev/loop0 mklabel msdos mkpart primary ext2 1m 2m quit ls /dev/loop0* Note the /dev/loop0p1 node. Run losetup -d /dev/loop0 and see if it is still there. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRpMRWAAoJEJrBOlT6nu75yUYH/1PSNmTOBYgvEqQclWPBTd8n Fm95yILcIlJWdUr3gUvQmjBax1NzKnG3NZ2U4hucpCcJH4FkHSTTFl5uZ3wU1B/Q nvuQoSqYXVP+V9PVSTsUsxOI4Mvw5YP5sFwSdwRKpkCldXOuHrRZsuccFtkQducU AIij42jvI1un+/qc6NLW+/S+rcLGUj21boPmX3g80km1De9QMrYrbGAAEbFO3rrq fzsvGuVvOroGppLGpze4iMDn060Lxrw6//KDGtiUBIeD8kZCFGkBh1KupHqLLzXm gmfdlHIqAR5uWB29m9TOlRbHPzdeQutwt8zL2LOYlCft5OiBIOW8dT8EFkl2Buw= =7BGq -END PGP SIGNATURE- -- 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: [RFC PATCH v2 00/15][Sorted-buddy] mm: Memory Power Management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/19/2013 3:12 AM, Srivatsa S. Bhat wrote: But going further, as I had mentioned in my TODO list, we can be smarter than this while doing compaction to evacuate memory regions - we can choose to migrate only the active pages, and leave the inactive pages alone. Because, the goal is to actually consolidate the *references* and not necessarily the *allocations* themselves. That would help with keeping references compact to allow use of the low power states, but it would also be nice to keep allocations compact, and completely power off a bank of ram with no allocations. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRpQ7EAAoJEJrBOlT6nu75wqYH/Aq18xGwk3QCJPEBb3BQX4be NY0JfHH9sHE7CFH4t13qpwNj/+N73xBg+TumY2qekUxqfwYSRo3hDhPRonlW/eDI X2AaEGDs8+aQT+QY8bAZnZFHFX8ZayNYOsNCewEV8djZDll2l+fOaFjVfZAwuQLK KtsMxjhlTzqMleRxVpZFLtVPG4GzLRITifKlBRQ+ffrO1zTTMI7glvM+IygIa5vS ajOCI0Nis1Rst2cOsrxfWc+DKN+gnI6c/qTsHarPD5zda1AFwe9DzWQ7EGiqnbJq 39vJmGIsspwrEPbaK0VX5dVYp85Bvd03EudeEish4EHVmH+hphpFokxoypRJePg= =Flf3 -END PGP SIGNATURE- -- 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: Abysmal HDD/USB write speed after sleep on a UEFI system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/8/2013 4:37 AM, Artem S. Tashkinov wrote: > Have you tried suspending more than three times? In the absence of > UEFI boot this bug emerges only on a third or even fourth resume > attempt. UEFI boot triggers it immediately on a first resume > though. I suspend my P8P67 every night. One thing that does come to mind now though, is that when I first built it, there was a problem involving suspend and the firewire driver, but IIRC, it manifested as a failure to suspend with an error in dmesg, so I disabled the firewire controller since I have no use for it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRilZ2AAoJEJrBOlT6nu75IbkH/RdaAwGoBbJbkTxh4vhR3l/+ nILa2X83WwEYADozNL7zi2w8AExTBHzfKZeE7uzXLPzsryPxJxAQY+LtXwRdCHQy GXVKZL2TpxPsNQTv1uhdCRiSTgIm9U1Y/INPZ2ugn+WbiH9iXzhRzLRgKH3kALO4 OvReW/XQeZ77RP6IaffnoLbStpORAXH+Ttnt5nMdLvm/rGuBlUsyDvT9TAAcF3W1 1muRJnzpDdMj+Ibwn/IW5smp9RBm2EJb2aP2N+KOV7WgiwPC+8T7omWV6Fjl+NI7 xrc8BQTGVfbZJXpeg2KH7v5Ty+M4xFYfdCJjLocL3rFJCYR+3WCDqpRB+I55Yvo= =eIDL -END PGP SIGNATURE- -- 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: Abysmal HDD/USB write speed after sleep on a UEFI system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/8/2013 4:37 AM, Artem S. Tashkinov wrote: Have you tried suspending more than three times? In the absence of UEFI boot this bug emerges only on a third or even fourth resume attempt. UEFI boot triggers it immediately on a first resume though. I suspend my P8P67 every night. One thing that does come to mind now though, is that when I first built it, there was a problem involving suspend and the firewire driver, but IIRC, it manifested as a failure to suspend with an error in dmesg, so I disabled the firewire controller since I have no use for it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRilZ2AAoJEJrBOlT6nu75IbkH/RdaAwGoBbJbkTxh4vhR3l/+ nILa2X83WwEYADozNL7zi2w8AExTBHzfKZeE7uzXLPzsryPxJxAQY+LtXwRdCHQy GXVKZL2TpxPsNQTv1uhdCRiSTgIm9U1Y/INPZ2ugn+WbiH9iXzhRzLRgKH3kALO4 OvReW/XQeZ77RP6IaffnoLbStpORAXH+Ttnt5nMdLvm/rGuBlUsyDvT9TAAcF3W1 1muRJnzpDdMj+Ibwn/IW5smp9RBm2EJb2aP2N+KOV7WgiwPC+8T7omWV6Fjl+NI7 xrc8BQTGVfbZJXpeg2KH7v5Ty+M4xFYfdCJjLocL3rFJCYR+3WCDqpRB+I55Yvo= =eIDL -END PGP SIGNATURE- -- 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: Abysmal HDD/USB write speed after sleep on a UEFI system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/7/2013 11:25 AM, Bjorn Helgaas wrote: > Phillip, I cc'd you because you have similar hardware and your > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1131468 report > is slightly similar. Have you seen anything like this "reduced > performance after resume" issue? If so, can you collect > /proc/mtrr contents before and after suspending? Nope, not seen that issue. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRiSgCAAoJEJrBOlT6nu75e0IH/1tqoTRyAMfVgcWTfhdcSAVi kBnvTpfGqlwD1ThxF3AZ+kHFPykI7TNUEvPR+syBFIi6BLHDoCZJMyCnKWwrY3jW 62lpgBZPZNejK+Yms3wjt6bZs81g38FKhWqm/IGruo7u79j/CS6puUypQMZ7WkC4 8y3SjBfiVy3ncQAOr7akCJzCv4fgqY+vtpIOHOXknfUxwgHqVOo3Pa0rMeat2TrN 8KHLkzYjML7Z+vN9DvPnqnRYFwFmkRZl01wRITo3OaFFJFhH70uqnwZ3ES+H0oh5 OpAJqEZ1PqiSAn+P7nI8RJ8lt7c5bta6Mvv0ev4+aDOQxnL3AmipOMNGfI37Ubk= =fiiM -END PGP SIGNATURE- -- 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: Abysmal HDD/USB write speed after sleep on a UEFI system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/7/2013 11:25 AM, Bjorn Helgaas wrote: Phillip, I cc'd you because you have similar hardware and your https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1131468 report is slightly similar. Have you seen anything like this reduced performance after resume issue? If so, can you collect /proc/mtrr contents before and after suspending? Nope, not seen that issue. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRiSgCAAoJEJrBOlT6nu75e0IH/1tqoTRyAMfVgcWTfhdcSAVi kBnvTpfGqlwD1ThxF3AZ+kHFPykI7TNUEvPR+syBFIi6BLHDoCZJMyCnKWwrY3jW 62lpgBZPZNejK+Yms3wjt6bZs81g38FKhWqm/IGruo7u79j/CS6puUypQMZ7WkC4 8y3SjBfiVy3ncQAOr7akCJzCv4fgqY+vtpIOHOXknfUxwgHqVOo3Pa0rMeat2TrN 8KHLkzYjML7Z+vN9DvPnqnRYFwFmkRZl01wRITo3OaFFJFhH70uqnwZ3ES+H0oh5 OpAJqEZ1PqiSAn+P7nI8RJ8lt7c5bta6Mvv0ev4+aDOQxnL3AmipOMNGfI37Ubk= =fiiM -END PGP SIGNATURE- -- 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: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]
> I have not tested it yet, but I am pretty sure it won't work. It
> looks like the patch changes the BLKRRPART path to go ahead and remove
> existing partitions when GENHD_FL_NO_PARTSCAN is set. loop doesn't
> issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so this won't help.
> I think loop needs to set GENHD_FL_NO_PARTSCAN and then issue the
> ioctl regardless of the LO_FLAGS_PARTSCAN flag to get the partitions
> to be removed. I will try to test tonight.
After testing, my initial thoughts appeared to have been correct. I had
to modify the patch as follows. To test, simply do:
truncate -s 10m img
losetup /dev/loop0 img
parted /dev/loop0
mklabel msdos
mkpart primary ext2 1m 2m
quit
ls /dev/loop0*
Note the /dev/loop0p1 node. Run losetup -d /dev/loop0 and see if it is
still there.
diff --git a/block/ioctl.c b/block/ioctl.c
index a31d91d..8b78b5a 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -155,7 +155,7 @@ static int blkdev_reread_part(struct block_device *bdev)
struct gendisk *disk = bdev->bd_disk;
int res;
- if (!disk_part_scan_enabled(disk) || bdev != bdev->bd_contains)
+ if (bdev != bdev->bd_contains)
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 1cb4dec..0e7d637 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -430,6 +430,15 @@ rescan:
disk->fops->revalidate_disk(disk);
check_disk_size_change(disk, bdev);
bdev->bd_invalidated = 0;
+
+ /*
+* If partition scanning is disabled, we are done.
+*/
+ if (!disk_part_scan_enabled(disk)) {
+ kobject_uevent(_to_dev(disk)->kobj, KOBJ_CHANGE);
+ return 0;
+ }
+
if (!get_capacity(disk) || !(state = check_partition(disk, bdev)))
return 0;
if (IS_ERR(state)) {
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 8bc6d39..326fac9 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1039,11 +1039,9 @@ static int loop_clr_fd(struct loop_device *lo)
lo->lo_state = Lo_unbound;
/* This is safe: open() is still holding a reference. */
module_put(THIS_MODULE);
- if (lo->lo_flags & LO_FLAGS_PARTSCAN && bdev)
- ioctl_by_bdev(bdev, BLKRRPART, 0);
+ lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
+ ioctl_by_bdev(bdev, BLKRRPART, 0);
lo->lo_flags = 0;
- if (!part_shift)
- lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
mutex_unlock(>lo_ctl_mutex);
/*
* Need not hold lo_ctl_mutex to fput backing file.
signature.asc
Description: OpenPGP digital signature
Re: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]
I have not tested it yet, but I am pretty sure it won't work. It
looks like the patch changes the BLKRRPART path to go ahead and remove
existing partitions when GENHD_FL_NO_PARTSCAN is set. loop doesn't
issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so this won't help.
I think loop needs to set GENHD_FL_NO_PARTSCAN and then issue the
ioctl regardless of the LO_FLAGS_PARTSCAN flag to get the partitions
to be removed. I will try to test tonight.
After testing, my initial thoughts appeared to have been correct. I had
to modify the patch as follows. To test, simply do:
truncate -s 10m img
losetup /dev/loop0 img
parted /dev/loop0
mklabel msdos
mkpart primary ext2 1m 2m
quit
ls /dev/loop0*
Note the /dev/loop0p1 node. Run losetup -d /dev/loop0 and see if it is
still there.
diff --git a/block/ioctl.c b/block/ioctl.c
index a31d91d..8b78b5a 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -155,7 +155,7 @@ static int blkdev_reread_part(struct block_device *bdev)
struct gendisk *disk = bdev-bd_disk;
int res;
- if (!disk_part_scan_enabled(disk) || bdev != bdev-bd_contains)
+ if (bdev != bdev-bd_contains)
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 1cb4dec..0e7d637 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -430,6 +430,15 @@ rescan:
disk-fops-revalidate_disk(disk);
check_disk_size_change(disk, bdev);
bdev-bd_invalidated = 0;
+
+ /*
+* If partition scanning is disabled, we are done.
+*/
+ if (!disk_part_scan_enabled(disk)) {
+ kobject_uevent(disk_to_dev(disk)-kobj, KOBJ_CHANGE);
+ return 0;
+ }
+
if (!get_capacity(disk) || !(state = check_partition(disk, bdev)))
return 0;
if (IS_ERR(state)) {
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 8bc6d39..326fac9 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1039,11 +1039,9 @@ static int loop_clr_fd(struct loop_device *lo)
lo-lo_state = Lo_unbound;
/* This is safe: open() is still holding a reference. */
module_put(THIS_MODULE);
- if (lo-lo_flags LO_FLAGS_PARTSCAN bdev)
- ioctl_by_bdev(bdev, BLKRRPART, 0);
+ lo-lo_disk-flags |= GENHD_FL_NO_PART_SCAN;
+ ioctl_by_bdev(bdev, BLKRRPART, 0);
lo-lo_flags = 0;
- if (!part_shift)
- lo-lo_disk-flags |= GENHD_FL_NO_PART_SCAN;
mutex_unlock(lo-lo_ctl_mutex);
/*
* Need not hold lo_ctl_mutex to fput backing file.
signature.asc
Description: OpenPGP digital signature
Re: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/3/2013 7:41 AM, Jens Axboe wrote: >> Thanks for testing! I don't particularly like this stuff in >> loop, though. It's quite nasty and depends on other behaviour. It >> would be prettier if we just had rescan_partitions() do the right >> thing, and only drop partitions and not rescan if NO_PART_SCAN is >> set. >> >> Ala the below, dropping the loop change and implementing that >> change in the core code. Phillip, can you check whether this does >> the right thing for your bug too? > > Phillip? I'm going to revert the loop change asap, so if you want > this fixed for 3.10, it's about that time to test it out. I have not tested it yet, but I am pretty sure it won't work. It looks like the patch changes the BLKRRPART path to go ahead and remove existing partitions when GENHD_FL_NO_PARTSCAN is set. loop doesn't issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so this won't help. I think loop needs to set GENHD_FL_NO_PARTSCAN and then issue the ioctl regardless of the LO_FLAGS_PARTSCAN flag to get the partitions to be removed. I will try to test tonight. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRXE2dAAoJEJrBOlT6nu75PM0IAIxVmuHdxLPtdtUNPqkU2a1r QanHb6F43qSbd7l37XlwYgzUlybVlntf1yvKGzh29g3QM0603sFqV1o+mbXd5LI3 b+I5QrQJh90Vou9oVSAxz1Ps/AlZvxVIDv8bRwNhpXcMmaj0EN5R+6pU5L7KU2BU GFsvajssedFh3XnNskgkR3XlqevI7U7A8VqLRsswl7FJVu7R1s45xP/sQgBWgiUS P5viykwhje4OTKmu0D7bFKrOVx6O3gK7IHzdOwwT9aWRxuxL+Y9yfBF9nx/xZXkc I2G09w852KgYDVYUHgW3IfuRo4F+4Y7Mw0Klu4XX5OmEXhselIqhwwTmEKMvEns= =OLri -END PGP SIGNATURE- -- 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: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/3/2013 7:41 AM, Jens Axboe wrote: Thanks for testing! I don't particularly like this stuff in loop, though. It's quite nasty and depends on other behaviour. It would be prettier if we just had rescan_partitions() do the right thing, and only drop partitions and not rescan if NO_PART_SCAN is set. Ala the below, dropping the loop change and implementing that change in the core code. Phillip, can you check whether this does the right thing for your bug too? Phillip? I'm going to revert the loop change asap, so if you want this fixed for 3.10, it's about that time to test it out. I have not tested it yet, but I am pretty sure it won't work. It looks like the patch changes the BLKRRPART path to go ahead and remove existing partitions when GENHD_FL_NO_PARTSCAN is set. loop doesn't issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so this won't help. I think loop needs to set GENHD_FL_NO_PARTSCAN and then issue the ioctl regardless of the LO_FLAGS_PARTSCAN flag to get the partitions to be removed. I will try to test tonight. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRXE2dAAoJEJrBOlT6nu75PM0IAIxVmuHdxLPtdtUNPqkU2a1r QanHb6F43qSbd7l37XlwYgzUlybVlntf1yvKGzh29g3QM0603sFqV1o+mbXd5LI3 b+I5QrQJh90Vou9oVSAxz1Ps/AlZvxVIDv8bRwNhpXcMmaj0EN5R+6pU5L7KU2BU GFsvajssedFh3XnNskgkR3XlqevI7U7A8VqLRsswl7FJVu7R1s45xP/sQgBWgiUS P5viykwhje4OTKmu0D7bFKrOVx6O3gK7IHzdOwwT9aWRxuxL+Y9yfBF9nx/xZXkc I2G09w852KgYDVYUHgW3IfuRo4F+4Y7Mw0Klu4XX5OmEXhselIqhwwTmEKMvEns= =OLri -END PGP SIGNATURE- -- 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: [PATCH] loop: cleanup partitions when detaching loop device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2013 06:07 PM, Andrew Morton wrote: > huh. What is the user-visible effect of this bug? Just a memory > leak or something more serious? Not serious, but user-visible in that the partition devnodes still show up after detaching the backing file, and I think the partitions remained in place after attaching a new file even though it had different or no partitions at all. > scripts/checkpatch.pl is your friend. Oops. I see you pushed a patch fixing up the brace position and breaking the long line. Did you want me to squash it and resubmit, or just sign off on it? If the latter, consider it signed off. > Can you please suggest a code comment which we can slip in here to > tell readers what's going on and why we're doing this? How about "Remove all partitions, since BLKRRPART won't remove user added partitions when max_part=0"? >> +struct disk_part_iter piter; + struct hd_struct *part; >> + + >> mutex_lock_nested(>bd_mutex, 1); + >> invalidate_partition(bdev->bd_disk, 0); + >> disk_part_iter_init(, bdev->bd_disk, >> DISK_PITER_INCL_EMPTY); +while ((part = >> disk_part_iter_next())) + >> delete_partition(bdev->bd_disk, >> part->partno); + disk_part_iter_exit(); + >> mutex_unlock(>bd_mutex); + } > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQn1XAAoJEJrBOlT6nu75QIEIAIM4skpZoKWYzAYXCK84JjP2 7Z0toyWfpQ63ku7grFPMST8wpGrsq31zcwa7zvya2Tg0ivi0vHOZmw0QBVic3mw0 Ce88iVkCDQSoASwPdHRLwNLj7Lj/cvHkwqZIHbDXR5u15v1sr3NTrCDMP33kZlPi Z8TbX+3fTTMYriYXUOI8fmqnC+d1gj8w+fsNNAB23/mVgN6ed9uGMQqEQjXGQOnQ By9R7dD5SZ9hqstLBSCvochBVfNjWm2rMtKTnixcY1qTDGCLWZ2sUpxns6WTjAZl lWL/S80kt+sbpkQorXWWDZJAvyRhQny4703rwPRhzgMWPDY7qJkn465tDT4S/ic= =3/XD -END PGP SIGNATURE- -- 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: [PATCH] loop: cleanup partitions when detaching loop device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2013 06:07 PM, Andrew Morton wrote: huh. What is the user-visible effect of this bug? Just a memory leak or something more serious? Not serious, but user-visible in that the partition devnodes still show up after detaching the backing file, and I think the partitions remained in place after attaching a new file even though it had different or no partitions at all. scripts/checkpatch.pl is your friend. Oops. I see you pushed a patch fixing up the brace position and breaking the long line. Did you want me to squash it and resubmit, or just sign off on it? If the latter, consider it signed off. Can you please suggest a code comment which we can slip in here to tell readers what's going on and why we're doing this? How about Remove all partitions, since BLKRRPART won't remove user added partitions when max_part=0? +struct disk_part_iter piter; + struct hd_struct *part; + + mutex_lock_nested(bdev-bd_mutex, 1); + invalidate_partition(bdev-bd_disk, 0); + disk_part_iter_init(piter, bdev-bd_disk, DISK_PITER_INCL_EMPTY); +while ((part = disk_part_iter_next(piter))) + delete_partition(bdev-bd_disk, part-partno); + disk_part_iter_exit(piter); + mutex_unlock(bdev-bd_mutex); + } -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQn1XAAoJEJrBOlT6nu75QIEIAIM4skpZoKWYzAYXCK84JjP2 7Z0toyWfpQ63ku7grFPMST8wpGrsq31zcwa7zvya2Tg0ivi0vHOZmw0QBVic3mw0 Ce88iVkCDQSoASwPdHRLwNLj7Lj/cvHkwqZIHbDXR5u15v1sr3NTrCDMP33kZlPi Z8TbX+3fTTMYriYXUOI8fmqnC+d1gj8w+fsNNAB23/mVgN6ed9uGMQqEQjXGQOnQ By9R7dD5SZ9hqstLBSCvochBVfNjWm2rMtKTnixcY1qTDGCLWZ2sUpxns6WTjAZl lWL/S80kt+sbpkQorXWWDZJAvyRhQny4703rwPRhzgMWPDY7qJkn465tDT4S/ic= =3/XD -END PGP SIGNATURE- -- 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: mmap vs fs cache
On 3/11/2013 7:52 AM, Jan Kara wrote: Yep, that's because it isn't implemented. Why do you think so? AFAICS it is implemented by setting VM_RAND_READ flag in the VMA and do_async_mmap_readahead() and do_sync_mmap_readahead() check for the flag and don't do anything if it is set... Oh, don't know how I missed that... I was just looking for it the other day and couldn't find any references to VM_RandomReadHint so I assumed it hadn't been implemented. -- 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: mmap vs fs cache
On 3/11/2013 7:52 AM, Jan Kara wrote: Yep, that's because it isn't implemented. Why do you think so? AFAICS it is implemented by setting VM_RAND_READ flag in the VMA and do_async_mmap_readahead() and do_sync_mmap_readahead() check for the flag and don't do anything if it is set... Oh, don't know how I missed that... I was just looking for it the other day and couldn't find any references to VM_RandomReadHint so I assumed it hadn't been implemented. -- 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: mmap vs fs cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 10:00 AM, Howard Chu wrote: > Yes, that's what I was thinking. I added a > posix_madvise(..POSIX_MADV_RANDOM) but that had no effect on the > test. Yep, that's because it isn't implemented. You might try MADV_WILLNEED to schedule it to be read in first. I believe that will only read in the requested page, without additional readahead, and then when you fault on the page, it already has IO scheduled, so the extra readahead will also be skipped. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJROo7GAAoJEJrBOlT6nu759SAH+wRhoUIZUuzNGrhfUJ6RnwV8 VjFyftBCAsdC+Mzq81Da3KJOi+BdYV8VbkYNPzbKll5AnxzL5Udvbdyf9SkROhug UgLWHe8pC6ZtHfSvWBCqS1YDLkzw+TiWwJzuL5iUEDC2NGuUJQ5SbhwyTEypvWai pdPZeFVyhLAKOtAUwD5e/5vhBWSq2M1TG2C7BUCow2fbJ6kil+kWuXtiDeNPvtUk 4FwabL8zHA9pNtMlHB0cUrn5W3VQYGqeTaDngjyLxR1gw7uFQn52G47IPe2LAMGx 58L/tHjbkSY9oukGiMHoF1jiaFqJqV1pw+Q2P7S+0XsU8JdW6CmzotTqDmcozqE= =DOZT -END PGP SIGNATURE- -- 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: mmap vs fs cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2013 10:00 AM, Howard Chu wrote: Yes, that's what I was thinking. I added a posix_madvise(..POSIX_MADV_RANDOM) but that had no effect on the test. Yep, that's because it isn't implemented. You might try MADV_WILLNEED to schedule it to be read in first. I believe that will only read in the requested page, without additional readahead, and then when you fault on the page, it already has IO scheduled, so the extra readahead will also be skipped. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJROo7GAAoJEJrBOlT6nu759SAH+wRhoUIZUuzNGrhfUJ6RnwV8 VjFyftBCAsdC+Mzq81Da3KJOi+BdYV8VbkYNPzbKll5AnxzL5Udvbdyf9SkROhug UgLWHe8pC6ZtHfSvWBCqS1YDLkzw+TiWwJzuL5iUEDC2NGuUJQ5SbhwyTEypvWai pdPZeFVyhLAKOtAUwD5e/5vhBWSq2M1TG2C7BUCow2fbJ6kil+kWuXtiDeNPvtUk 4FwabL8zHA9pNtMlHB0cUrn5W3VQYGqeTaDngjyLxR1gw7uFQn52G47IPe2LAMGx 58L/tHjbkSY9oukGiMHoF1jiaFqJqV1pw+Q2P7S+0XsU8JdW6CmzotTqDmcozqE= =DOZT -END PGP SIGNATURE- -- 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/
[PATCH] loop: cleanup partitions when detaching loop device
Any partitions added by user space to the loop device were being
left in place after detaching the loop device. This was because
the detach path issued a BLKRRPART to clean up partitions if
LO_FLAGS_PARTSCAN was set, meaning that the partitions were auto
scanned on attach. Replace this BLKRRPART with code that
unconditionally cleans up partitions on detach instead.
Signed-off-by: Phillip Susi
---
drivers/block/loop.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ae12512..38f0239 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1039,12 +1039,24 @@ static int loop_clr_fd(struct loop_device *lo)
lo->lo_state = Lo_unbound;
/* This is safe: open() is still holding a reference. */
module_put(THIS_MODULE);
- if (lo->lo_flags & LO_FLAGS_PARTSCAN && bdev)
- ioctl_by_bdev(bdev, BLKRRPART, 0);
lo->lo_flags = 0;
if (!part_shift)
lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
mutex_unlock(>lo_ctl_mutex);
+ if (bdev)
+ {
+ struct disk_part_iter piter;
+ struct hd_struct *part;
+
+ mutex_lock_nested(>bd_mutex, 1);
+ invalidate_partition(bdev->bd_disk, 0);
+ disk_part_iter_init(, bdev->bd_disk,
DISK_PITER_INCL_EMPTY);
+ while ((part = disk_part_iter_next()))
+ delete_partition(bdev->bd_disk, part->partno);
+ disk_part_iter_exit();
+ mutex_unlock(>bd_mutex);
+ }
+
/*
* Need not hold lo_ctl_mutex to fput backing file.
* Calling fput holding lo_ctl_mutex triggers a circular
--
1.8.1.2
--
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/
[PATCH] loop: cleanup partitions when detaching loop device
Any partitions added by user space to the loop device were being
left in place after detaching the loop device. This was because
the detach path issued a BLKRRPART to clean up partitions if
LO_FLAGS_PARTSCAN was set, meaning that the partitions were auto
scanned on attach. Replace this BLKRRPART with code that
unconditionally cleans up partitions on detach instead.
Signed-off-by: Phillip Susi ps...@ubuntu.com
---
drivers/block/loop.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ae12512..38f0239 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1039,12 +1039,24 @@ static int loop_clr_fd(struct loop_device *lo)
lo-lo_state = Lo_unbound;
/* This is safe: open() is still holding a reference. */
module_put(THIS_MODULE);
- if (lo-lo_flags LO_FLAGS_PARTSCAN bdev)
- ioctl_by_bdev(bdev, BLKRRPART, 0);
lo-lo_flags = 0;
if (!part_shift)
lo-lo_disk-flags |= GENHD_FL_NO_PART_SCAN;
mutex_unlock(lo-lo_ctl_mutex);
+ if (bdev)
+ {
+ struct disk_part_iter piter;
+ struct hd_struct *part;
+
+ mutex_lock_nested(bdev-bd_mutex, 1);
+ invalidate_partition(bdev-bd_disk, 0);
+ disk_part_iter_init(piter, bdev-bd_disk,
DISK_PITER_INCL_EMPTY);
+ while ((part = disk_part_iter_next(piter)))
+ delete_partition(bdev-bd_disk, part-partno);
+ disk_part_iter_exit(piter);
+ mutex_unlock(bdev-bd_mutex);
+ }
+
/*
* Need not hold lo_ctl_mutex to fput backing file.
* Calling fput holding lo_ctl_mutex triggers a circular
--
1.8.1.2
--
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: [PATCH] fadvise: perform WILLNEED readahead in a workqueue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/15/2012 9:45 PM, Dave Chinner wrote: > On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote: >> Applications streaming large files may want to reduce disk >> spinups and I/O latency by performing large amounts of readahead >> up front. Applications also tend to read files soon after opening >> them, so waiting on a slow fadvise may cause unpleasant latency >> when the application starts reading the file. >> >> As a userspace hacker, I'm sometimes tempted to create a >> background thread in my app to run readahead(). However, I >> believe doing this in the kernel will make life easier for other >> userspace hackers. >> >> Since fadvise makes no guarantees about when (or even if) >> readahead is performed, this change should not hurt existing >> applications. >> >> "strace -T" timing on an uncached, one gigabyte file: >> >> Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832> >> After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.61> > > You've basically asked fadvise() to readahead the entire file if > it can. That means it is likely to issue enough readahead to fill > the IO queue, and that's where all the latency is coming from. If > all you are trying to do is reduce the latency of the first read, > then only readahead the initial range that you are going to need to > read... It shouldn't take 2 seconds to queue up some async reads. Are you using ext3? The blocks have to be mapped in order to queue the reads, and without ext4 extents, this means the indirect blocks have to be read and can cause fadvise to block. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRJ6CjAAoJEJrBOlT6nu759s8IAKmIyZYDk1JSRP6oJaGaGZ/r aZCBH52wTPH8DaqFGe+62L8lyIQ5hD15Y+zTuaWh+fJ7C1k/lU8F/QbKCG2D+xCB vfLF0WRx63fWLLg8xZTRU1x8X6sG+Byp+UYWNspTDrL15ChlaqqGGmwLNo4JxLa8 +AGQVt1WMU3TitD9CUMUfYFWGUQsMR0gWeJkJnjHiEZ7VoGzft2PTlnvElzIk76u 3cmwfoKHrnXzi50rPtP2gonRjMwd8VY859qOk0zlHoMDMcXklAWeIN9PEUIMx+VP fMnBm6u48cKXPYGvQrGMOdjxlt7k4LhGDZxIlvmwNHWUSaifmkJ8oBMvfbAYtUA= =G5rE -END PGP SIGNATURE- -- 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: [PATCH] fadvise: perform WILLNEED readahead in a workqueue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/15/2012 9:45 PM, Dave Chinner wrote: On Sat, Dec 15, 2012 at 12:54:48AM +, Eric Wong wrote: Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front. Applications also tend to read files soon after opening them, so waiting on a slow fadvise may cause unpleasant latency when the application starts reading the file. As a userspace hacker, I'm sometimes tempted to create a background thread in my app to run readahead(). However, I believe doing this in the kernel will make life easier for other userspace hackers. Since fadvise makes no guarantees about when (or even if) readahead is performed, this change should not hurt existing applications. strace -T timing on an uncached, one gigabyte file: Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 2.484832 After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 0.61 You've basically asked fadvise() to readahead the entire file if it can. That means it is likely to issue enough readahead to fill the IO queue, and that's where all the latency is coming from. If all you are trying to do is reduce the latency of the first read, then only readahead the initial range that you are going to need to read... It shouldn't take 2 seconds to queue up some async reads. Are you using ext3? The blocks have to be mapped in order to queue the reads, and without ext4 extents, this means the indirect blocks have to be read and can cause fadvise to block. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRJ6CjAAoJEJrBOlT6nu759s8IAKmIyZYDk1JSRP6oJaGaGZ/r aZCBH52wTPH8DaqFGe+62L8lyIQ5hD15Y+zTuaWh+fJ7C1k/lU8F/QbKCG2D+xCB vfLF0WRx63fWLLg8xZTRU1x8X6sG+Byp+UYWNspTDrL15ChlaqqGGmwLNo4JxLa8 +AGQVt1WMU3TitD9CUMUfYFWGUQsMR0gWeJkJnjHiEZ7VoGzft2PTlnvElzIk76u 3cmwfoKHrnXzi50rPtP2gonRjMwd8VY859qOk0zlHoMDMcXklAWeIN9PEUIMx+VP fMnBm6u48cKXPYGvQrGMOdjxlt7k4LhGDZxIlvmwNHWUSaifmkJ8oBMvfbAYtUA= =G5rE -END PGP SIGNATURE- -- 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/
LDM Documentation dead link
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 drivers/fs/partitions/ldm.[ch] refer to documentation at http://www.linux-ntfs.org/content/view/19/37/. This link appears to be dead and just redirects to the main tuxera.com page. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQvQShAAoJEJrBOlT6nu75rNQIAM9ZTLTtrzdVNcO9biLGxyu6 ROnUhIyWKRBTUddSfkv3WRcy+9SEQqlSRJpQ9tGp6IqdQbYXuTuy30fPq+crrZd7 ccHCT2T3Uk0AMmVKBxZ/S1mZAFc0pKmWUdPrIuPLnoN/hhX9hGXRYJYsO8kFZgyj xaDTmgWxRKKfqy60uRHRyKYvhV/Jm0XL8GN7osVn5j0Zr3n3PHRDxqaTcnWkCtyM x5Fr0DZHAkpDC/NoWdwsvnlRNoXiVDQLenL5cnFim44qGsPJgj75RcnHX2BctOLI +ZdkzJmAvIRtOCsbbEUL/a9gebMH4RWaksg3bq4fHJoyUf2HuQXFTnsrMwAiAEU= =nE2+ -END PGP SIGNATURE- -- 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/
LDM Documentation dead link
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 drivers/fs/partitions/ldm.[ch] refer to documentation at http://www.linux-ntfs.org/content/view/19/37/. This link appears to be dead and just redirects to the main tuxera.com page. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQvQShAAoJEJrBOlT6nu75rNQIAM9ZTLTtrzdVNcO9biLGxyu6 ROnUhIyWKRBTUddSfkv3WRcy+9SEQqlSRJpQ9tGp6IqdQbYXuTuy30fPq+crrZd7 ccHCT2T3Uk0AMmVKBxZ/S1mZAFc0pKmWUdPrIuPLnoN/hhX9hGXRYJYsO8kFZgyj xaDTmgWxRKKfqy60uRHRyKYvhV/Jm0XL8GN7osVn5j0Zr3n3PHRDxqaTcnWkCtyM x5Fr0DZHAkpDC/NoWdwsvnlRNoXiVDQLenL5cnFim44qGsPJgj75RcnHX2BctOLI +ZdkzJmAvIRtOCsbbEUL/a9gebMH4RWaksg3bq4fHJoyUf2HuQXFTnsrMwAiAEU= =nE2+ -END PGP SIGNATURE- -- 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: [patch 0/2] [V4] block: Support online resize of disk partitions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/10/2012 9:57 AM, Vivek Goyal wrote:
> +static inline sector_t part_nr_sects_read(struct hd_struct *part)
> +{ +#if BITS_PER_LONG==32 && defined(CONFIG_LBDAF) &&
> defined(CONFIG_SMP) + sector_t nr_sects; +unsigned seq; + do { +
> seq = read_seqcount_begin(>nr_sects_seq); + nr_sects =
> part->nr_sects; + } while (read_seqcount_retry(>nr_sects_seq,
> seq)); + return nr_sects; +#elif BITS_PER_LONG==32 &&
> defined(CONFIG_PREEMPT)
Shouldn't this be BITS_PER_LONG==32 && defined(CONFIG_LBDAF) &&
defined(CONFIG_PREEMPT)? No sense disabling preemption when the
sector size is also 32 bits.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJP/Dh/AAoJEJrBOlT6nu75ussIANfCKaObXMJ6JhCNLSeiHUqr
FfBd6p2lJIFd73NSymyigZZ1/rPsy9TpMBlcMwpuFh2erxQ7q3rFnP0O52fEgm2+
20c9+oeUGkzYx62fh0KtfrzBpzhiHOivKR/muAZcfNbb75iKTGrZSZUFrdqAqHci
4zCuu8T37BRo4G9TGdIXD1WT3sltZ7yOk4I7RBhAIDkbt82vVakZ6mlW9hyWmyvD
/sMnXMmkNjwTDdhQj2ho9mn9SFcnDA+aAtJfPXjVAT0W9CKNDYbXw28ud+ARxo5T
rkTjoewdxKffZsBmkkSiNCuLWwpkZng+nTchQjyZbmp/pl4UPlQOfcUb6YxpDX4=
=1tUj
-END PGP SIGNATURE-
--
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: [patch 0/2] [V4] block: Support online resize of disk partitions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/10/2012 9:57 AM, Vivek Goyal wrote:
+static inline sector_t part_nr_sects_read(struct hd_struct *part)
+{ +#if BITS_PER_LONG==32 defined(CONFIG_LBDAF)
defined(CONFIG_SMP) + sector_t nr_sects; +unsigned seq; + do { +
seq = read_seqcount_begin(part-nr_sects_seq); + nr_sects =
part-nr_sects; + } while (read_seqcount_retry(part-nr_sects_seq,
seq)); + return nr_sects; +#elif BITS_PER_LONG==32
defined(CONFIG_PREEMPT)
Shouldn't this be BITS_PER_LONG==32 defined(CONFIG_LBDAF)
defined(CONFIG_PREEMPT)? No sense disabling preemption when the
sector size is also 32 bits.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJP/Dh/AAoJEJrBOlT6nu75ussIANfCKaObXMJ6JhCNLSeiHUqr
FfBd6p2lJIFd73NSymyigZZ1/rPsy9TpMBlcMwpuFh2erxQ7q3rFnP0O52fEgm2+
20c9+oeUGkzYx62fh0KtfrzBpzhiHOivKR/muAZcfNbb75iKTGrZSZUFrdqAqHci
4zCuu8T37BRo4G9TGdIXD1WT3sltZ7yOk4I7RBhAIDkbt82vVakZ6mlW9hyWmyvD
/sMnXMmkNjwTDdhQj2ho9mn9SFcnDA+aAtJfPXjVAT0W9CKNDYbXw28ud+ARxo5T
rkTjoewdxKffZsBmkkSiNCuLWwpkZng+nTchQjyZbmp/pl4UPlQOfcUb6YxpDX4=
=1tUj
-END PGP SIGNATURE-
--
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: [patch 0/2] [V4] block: Support online resize of disk partitions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2012 05:34 PM, vgo...@redhat.com wrote: > Phillip, do let me know if I should put your signed-off-by also in the > patch. Sure, kernel side looks good. My original util-linux patches also added a -u update mode to kpartx, which I think is the more useful interface than the lower level resizepart command, but I suppose I can rebase it to apply on top of this patch. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP+13DAAoJEJrBOlT6nu75cQIIAJvm6ZFxpNNvgkXq0I6blvIj Q3s5YbzJYecouHPZdy06UXIdfucHKO7WAaMvpmPnDk+JgtltNljVpA50d21NN2lY k2j2oU9mFHGEKLDnnYobnr6cO2UShaZkrcMtC29S4LaAdgAgPNyD8aTTWS9w0frv +p2ko+HKvp3neRpOBwfnYXq/rTBLUmOn0k7XsG8QjnNb3aMnMyYp/crV9Kzeb4YX uCbnIkzN++oDhmnqsLDGt82/VGXZdnA1umISbV9vZw+Q7FfeaiJVMneFxKe5w/FZ wiCixoCtGhbqtz1hSsUR+rs2ZaDozL0iygSB15Z71aLPim0TLumtRTpfpu+JR3w= =Vtl+ -END PGP SIGNATURE- -- 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: [patch 0/2] [V4] block: Support online resize of disk partitions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2012 05:34 PM, vgo...@redhat.com wrote: Phillip, do let me know if I should put your signed-off-by also in the patch. Sure, kernel side looks good. My original util-linux patches also added a -u update mode to kpartx, which I think is the more useful interface than the lower level resizepart command, but I suppose I can rebase it to apply on top of this patch. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP+13DAAoJEJrBOlT6nu75cQIIAJvm6ZFxpNNvgkXq0I6blvIj Q3s5YbzJYecouHPZdy06UXIdfucHKO7WAaMvpmPnDk+JgtltNljVpA50d21NN2lY k2j2oU9mFHGEKLDnnYobnr6cO2UShaZkrcMtC29S4LaAdgAgPNyD8aTTWS9w0frv +p2ko+HKvp3neRpOBwfnYXq/rTBLUmOn0k7XsG8QjnNb3aMnMyYp/crV9Kzeb4YX uCbnIkzN++oDhmnqsLDGt82/VGXZdnA1umISbV9vZw+Q7FfeaiJVMneFxKe5w/FZ wiCixoCtGhbqtz1hSsUR+rs2ZaDozL0iygSB15Z71aLPim0TLumtRTpfpu+JR3w= =Vtl+ -END PGP SIGNATURE- -- 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: [PATCH 1/2] block: add partition resize function to blkpg ioctl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What's the status of this patch? Forgotten, or are there still any outstanding concerns? On 03/02/2012 01:54 PM, Vivek Goyal wrote: > Hi Jens, > > Do you have concerns about this patch? If no, can you please consider > merging it. > > Thanks > Vivek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP95YUAAoJEJrBOlT6nu75A/kIAIEWs+MlA8Me05jjBGpSFQsn VigiYTF4UdWjA3bG0CNB41eqpzOKVl/B4vTBAy1YezuUXMamBRp1OD6hatEL/blO ps/M2S2NNPgFOzDmZBgfWIib6tnbCJvTowLdt4n4NnP0DoQRn+5bXopL/jcm4lwU XWheiqFFX1xSB5YgP+GMl4zVWZhyrHYcynqK/25EimbEXtjgTyR3Cy4wMfGgMdnI HkY7D0Kn420n+X6uRLXZW8hV3apATZCz3PGsxg7FI83gFi7Tc9rneOhwgRkAXHxq FcJ2NABK83dACAYOU0fhVTmxoumxuHNCmp7iRGiavnbNCBJWxLV2x1WhceX23lc= =1FUQ -END PGP SIGNATURE- -- 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: [PATCH 1/2] block: add partition resize function to blkpg ioctl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What's the status of this patch? Forgotten, or are there still any outstanding concerns? On 03/02/2012 01:54 PM, Vivek Goyal wrote: Hi Jens, Do you have concerns about this patch? If no, can you please consider merging it. Thanks Vivek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP95YUAAoJEJrBOlT6nu75A/kIAIEWs+MlA8Me05jjBGpSFQsn VigiYTF4UdWjA3bG0CNB41eqpzOKVl/B4vTBAy1YezuUXMamBRp1OD6hatEL/blO ps/M2S2NNPgFOzDmZBgfWIib6tnbCJvTowLdt4n4NnP0DoQRn+5bXopL/jcm4lwU XWheiqFFX1xSB5YgP+GMl4zVWZhyrHYcynqK/25EimbEXtjgTyR3Cy4wMfGgMdnI HkY7D0Kn420n+X6uRLXZW8hV3apATZCz3PGsxg7FI83gFi7Tc9rneOhwgRkAXHxq FcJ2NABK83dACAYOU0fhVTmxoumxuHNCmp7iRGiavnbNCBJWxLV2x1WhceX23lc= =1FUQ -END PGP SIGNATURE- -- 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: Device node - How does kernel know about it
Siva Prasad wrote: Hi, How do the device nodes work as an interface between user and kernel programs, and how to go debugging it? This is as part of my debugging effort on an embedded board. The filesystem sets specific bits in the mode mask and elsewhere in the inode to mark the file as a dev node, and which major/minor device number it should be linked to. The kernel device drivers register to handle a given device number. * It all started with the problem of "not printing" any thing that comes from ramdisk (echo and printf statements), while kernel printk's work perfectly fine. * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. So you did you pass the console=ttyS0 parameter to the kernel? Did you configure your inittab to spawn the getty on the serial port instead of /dev/ttyN? You might want to take a look at the Linux Serial Console HOWTO. -- 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: Device node - How does kernel know about it
Siva Prasad wrote: Hi, How do the device nodes work as an interface between user and kernel programs, and how to go debugging it? This is as part of my debugging effort on an embedded board. The filesystem sets specific bits in the mode mask and elsewhere in the inode to mark the file as a dev node, and which major/minor device number it should be linked to. The kernel device drivers register to handle a given device number. * It all started with the problem of not printing any thing that comes from ramdisk (echo and printf statements), while kernel printk's work perfectly fine. * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. So you did you pass the console=ttyS0 parameter to the kernel? Did you configure your inittab to spawn the getty on the serial port instead of /dev/ttyN? You might want to take a look at the Linux Serial Console HOWTO. -- 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: /dev/urandom uses uninit bytes, leaks user data
Andrew Lutomirski wrote: No, it's there, and if there's little enough entropy around it can be recovered by brute force. A little entropy is enough to prevent a brute force attack. You would have to have ZERO entropy after a cold boot so the attacker would know exactly the contents of the pool, AND know that one and ONLY one other task has read from /dev/urandom, AND exactly what time that task did so, AND how many bytes it read. Only then could the attacker read from urandom and based on those bytes and the previous known pool state, brute force the 3 bytes that came from some unknown location in the other task's memory. Step 1: Boot a system without a usable entropy source. Step 2: add some (predictable) "entropy" from userspace which isn't a multiple of 4, so up to three extra bytes get added. Step 3: Read a few bytes of /dev/random and send them over the network. Only root can do 1 and 2, at which point, it's already game over. Again, no. Root could do this accidentally. Step 1 happens all the time (see the comments on non-unique UUIDs). Step 2 just requires a It does not happen all the time. It happens on a system that has just been cold booted from read only distribution media with a broken cmos clock, no user keyboard interaction, and no hardware rng and that's it. Every other system is going to have some entropy from the last boot at least. -- 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: Why does reading from /dev/urandom deplete entropy so much?
Marc Haber wrote: On Tue, Dec 11, 2007 at 10:42:49AM -0500, Bill Davidsen wrote: The original point was that urandom draws entropy from random, and that it is an an inobvious and unintentional drain on the entropy pool. At least that's how I read it. And you are reading it correct. At least one of the major TLS libraries does it this way, putting unnecessary stress on the kernel entropy pool. While I now consider this a bug in the library, there surely are gazillions of similiarily flawed applications out there in the wild. It seems to me that reading from (u)random disturbs the entropy pool, so the more consumers reading from the pool in unpredictable ways, the better. As it is currently implemented, it lowers the entropy estimate, but the pool will have MORE entropy if several applications keep reading /dev/random periodically when they need random bytes instead of just reading it once to seed their own prng. IMHO, it is the entropy estimate that is broken, not the TLS library. -- 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: /dev/urandom uses uninit bytes, leaks user data
Andrew Lutomirski wrote: No, it's there, and if there's little enough entropy around it can be recovered by brute force. A little entropy is enough to prevent a brute force attack. You would have to have ZERO entropy after a cold boot so the attacker would know exactly the contents of the pool, AND know that one and ONLY one other task has read from /dev/urandom, AND exactly what time that task did so, AND how many bytes it read. Only then could the attacker read from urandom and based on those bytes and the previous known pool state, brute force the 3 bytes that came from some unknown location in the other task's memory. Step 1: Boot a system without a usable entropy source. Step 2: add some (predictable) entropy from userspace which isn't a multiple of 4, so up to three extra bytes get added. Step 3: Read a few bytes of /dev/random and send them over the network. Only root can do 1 and 2, at which point, it's already game over. Again, no. Root could do this accidentally. Step 1 happens all the time (see the comments on non-unique UUIDs). Step 2 just requires a It does not happen all the time. It happens on a system that has just been cold booted from read only distribution media with a broken cmos clock, no user keyboard interaction, and no hardware rng and that's it. Every other system is going to have some entropy from the last boot at least. -- 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: Why does reading from /dev/urandom deplete entropy so much?
Marc Haber wrote: On Tue, Dec 11, 2007 at 10:42:49AM -0500, Bill Davidsen wrote: The original point was that urandom draws entropy from random, and that it is an an inobvious and unintentional drain on the entropy pool. At least that's how I read it. And you are reading it correct. At least one of the major TLS libraries does it this way, putting unnecessary stress on the kernel entropy pool. While I now consider this a bug in the library, there surely are gazillions of similiarily flawed applications out there in the wild. It seems to me that reading from (u)random disturbs the entropy pool, so the more consumers reading from the pool in unpredictable ways, the better. As it is currently implemented, it lowers the entropy estimate, but the pool will have MORE entropy if several applications keep reading /dev/random periodically when they need random bytes instead of just reading it once to seed their own prng. IMHO, it is the entropy estimate that is broken, not the TLS library. -- 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 00/63] ide-cd: redux
Bartlomiej Zolnierkiewicz wrote: Hi, This patch series is a major rework of the ide-cd driver. Hi, in the future could you please post big patchbombs like this as replies to the first one so they fold nicely into one thread? IIRC, git-send-email does this by default 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: /dev/urandom uses uninit bytes, leaks user data
Andrew Lutomirski wrote: I understand that there's no way that /dev/random can provide good output if there's insufficient entropy. But it still shouldn't leak arbitrary bits of user data that were never meant to be put into the pool at all. It doesn't leak it though, it consumes it, and it then vanishes into the entropy pool, never to be seen again. Step 1: Boot a system without a usable entropy source. Step 2: add some (predictable) "entropy" from userspace which isn't a multiple of 4, so up to three extra bytes get added. Step 3: Read a few bytes of /dev/random and send them over the network. Only root can do 1 and 2, at which point, it's already game over. -- 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: /dev/urandom uses uninit bytes, leaks user data
Andrew Lutomirski wrote: I understand that there's no way that /dev/random can provide good output if there's insufficient entropy. But it still shouldn't leak arbitrary bits of user data that were never meant to be put into the pool at all. It doesn't leak it though, it consumes it, and it then vanishes into the entropy pool, never to be seen again. Step 1: Boot a system without a usable entropy source. Step 2: add some (predictable) entropy from userspace which isn't a multiple of 4, so up to three extra bytes get added. Step 3: Read a few bytes of /dev/random and send them over the network. Only root can do 1 and 2, at which point, it's already game over. -- 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 00/63] ide-cd: redux
Bartlomiej Zolnierkiewicz wrote: Hi, This patch series is a major rework of the ide-cd driver. Hi, in the future could you please post big patchbombs like this as replies to the first one so they fold nicely into one thread? IIRC, git-send-email does this by default 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: BUG: attempt to access beyond end of device
Oops, try that again with Jens' new address. Phillip Susi wrote: Thomas Meyer wrote: Hi, is somebody actually working on this bug? http://bugzilla.kernel.org/show_bug.cgi?id=9370 I don't want to be impolite, but it's now more than a month since the bug was opened. The bug still exists in v2.6.24-rc5-43-gda8cadb: Have you tried simply removing the line mentioned in the bug report from pktcdvd.c? rq->cmd_type = REQ_TYPE_BLOCK_PC; Maybe Jens can comment on if that would be correct since he is more familiar with the code than I. -- 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: attempt to access beyond end of device
Thomas Meyer wrote: Hi, is somebody actually working on this bug? http://bugzilla.kernel.org/show_bug.cgi?id=9370 I don't want to be impolite, but it's now more than a month since the bug was opened. The bug still exists in v2.6.24-rc5-43-gda8cadb: Have you tried simply removing the line mentioned in the bug report from pktcdvd.c? rq->cmd_type = REQ_TYPE_BLOCK_PC; Maybe Jens can comment on if that would be correct since he is more familiar with the code than I. -- 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: attempt to access beyond end of device
Thomas Meyer wrote: Hi, is somebody actually working on this bug? http://bugzilla.kernel.org/show_bug.cgi?id=9370 I don't want to be impolite, but it's now more than a month since the bug was opened. The bug still exists in v2.6.24-rc5-43-gda8cadb: Have you tried simply removing the line mentioned in the bug report from pktcdvd.c? rq-cmd_type = REQ_TYPE_BLOCK_PC; Maybe Jens can comment on if that would be correct since he is more familiar with the code than I. -- 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: attempt to access beyond end of device
Oops, try that again with Jens' new address. Phillip Susi wrote: Thomas Meyer wrote: Hi, is somebody actually working on this bug? http://bugzilla.kernel.org/show_bug.cgi?id=9370 I don't want to be impolite, but it's now more than a month since the bug was opened. The bug still exists in v2.6.24-rc5-43-gda8cadb: Have you tried simply removing the line mentioned in the bug report from pktcdvd.c? rq-cmd_type = REQ_TYPE_BLOCK_PC; Maybe Jens can comment on if that would be correct since he is more familiar with the code than I. -- 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] x86: Remove all definitions with fastcall
H. Peter Anvin wrote: Not just default, it's the only thing supported. -hpa What about va args? IIRC, fastcall fell back to stdcall after using up registers, so va args HAD to be cdecl. -- 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] x86: Remove all definitions with fastcall
Harvey Harrison wrote: It was a leftover from before regparm(3) became the default on x86-32. It doesn't have any use now. Harvey You mean the default calling convention is now fastcall instead of cdecl or stdcall? -- 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] x86: Remove all definitions with fastcall
Harvey Harrison wrote: It was a leftover from before regparm(3) became the default on x86-32. It doesn't have any use now. Harvey You mean the default calling convention is now fastcall instead of cdecl or stdcall? -- 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] x86: Remove all definitions with fastcall
H. Peter Anvin wrote: Not just default, it's the only thing supported. -hpa What about va args? IIRC, fastcall fell back to stdcall after using up registers, so va args HAD to be cdecl. -- 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] x86: Remove all definitions with fastcall
Harvey Harrison wrote: fastcall is always defined to be empty, remove it from arch/x86 Why is it always defined to be empty? Why isn't it used anymore? -- 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] x86: Remove all definitions with fastcall
Harvey Harrison wrote: fastcall is always defined to be empty, remove it from arch/x86 Why is it always defined to be empty? Why isn't it used anymore? -- 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: Why does reading from /dev/urandom deplete entropy so much?
Theodore Tso wrote: Note that even paranoid applicatons should not be using /dev/random for session keys; again, /dev/random isn't magic, and entropy isn't unlimited. Instead, such an application should pull 16 bytes or so, and then use it to seed a cryptographic random number generator. What good does using multiple levels of RNG do? Why seed one RNG from another? Wouldn't it be better to have just one RNG that everybody uses? Doesn't the act of reading from the RNG add entropy to it, since no one reader has any idea how often and at what times other readers are stirring the pool? -- 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: Why does reading from /dev/urandom deplete entropy so much?
Theodore Tso wrote: Note that even paranoid applicatons should not be using /dev/random for session keys; again, /dev/random isn't magic, and entropy isn't unlimited. Instead, such an application should pull 16 bytes or so, and then use it to seed a cryptographic random number generator. What good does using multiple levels of RNG do? Why seed one RNG from another? Wouldn't it be better to have just one RNG that everybody uses? Doesn't the act of reading from the RNG add entropy to it, since no one reader has any idea how often and at what times other readers are stirring the pool? -- 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: syslets v7: back to basics
Zach Brown wrote: The following patches are a substantial refactoring of the syslet code. I'm branding them as the v7 release of the syslet infrastructure, though they represent a signifiant change in focus. My current focus is to see the most fundamental functionality brought to maturity. To me, this means getting a ABI that is used by applications through glibc on x86 and PPC64. Only once that is ready should we distract ourselves with advanced complexity. I pulled from your tree to look over the patches, and noticed that it looks like several commits were merged improperly. It looks like they were auto merged or something from an email, and the commit message contains the email headers, rather than just the commit message in the body. This leads to the shortlog showing entries that start with "Return-Path:". I was hoping to find at least some initial information on the overall design in Documentation/ but don't see any. Have you written any yet that I could take a look at elsewhere maybe? Some of the things I was trying to figure out is does each syslet get its own stack, and schedule only at a few well defined points, and if so, would it then be fair to characterize them as kernel mode fibers? -- 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: syslets v7: back to basics
Zach Brown wrote: The following patches are a substantial refactoring of the syslet code. I'm branding them as the v7 release of the syslet infrastructure, though they represent a signifiant change in focus. My current focus is to see the most fundamental functionality brought to maturity. To me, this means getting a ABI that is used by applications through glibc on x86 and PPC64. Only once that is ready should we distract ourselves with advanced complexity. I pulled from your tree to look over the patches, and noticed that it looks like several commits were merged improperly. It looks like they were auto merged or something from an email, and the commit message contains the email headers, rather than just the commit message in the body. This leads to the shortlog showing entries that start with Return-Path:. I was hoping to find at least some initial information on the overall design in Documentation/ but don't see any. Have you written any yet that I could take a look at elsewhere maybe? Some of the things I was trying to figure out is does each syslet get its own stack, and schedule only at a few well defined points, and if so, would it then be fair to characterize them as kernel mode fibers? -- 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 guidance
Al Boldi wrote: When you read server, don't read it as localized; a server can be distributed. What distinguishes a server from an engine is that it has to handle a multi-user use-case. How that is implemented, locally or remotely or distributed, is another issue. And again, git handles both use cases, so what's your point? As explained before in this thread, replicating the git tree on the client still doesn't provide the required transparency. It has been pointed out to you that it DOES. Either that or nobody else understands your nebulous use of "transparency" so maybe you should define it like we've been asking you. Furthermore, the comment you replied to said nothing about transparency, nor did your comment it was in reply to; rather it was pointing out the fact that your statement that the git can not perform version control on the client is patently false. How is that different from what every SCM, including git, is doing today? The user needs to tell the scm when it's time to take a snapshot of the current state. Git is distributed though, so committing is usually not the same as publishing. Is that lack of a single command to commit and publish what's nagging you? If it's not, I completely fail to see what you're getting at, unless you've only ever looked at repositories without a worktree attached, or you think that git should work like an editor's "undo" functionality, which would be quite insane. You need to re-read the thread. Perhaps you should. We have been trying to get you to explain how you think git isn't "transparent" while at the same time pointing out how we think it is. You have failed to demonstrate any evidence to back up your claims, all of which have been shown to be false. -- 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 guidance
Al Boldi wrote: When you read server, don't read it as localized; a server can be distributed. What distinguishes a server from an engine is that it has to handle a multi-user use-case. How that is implemented, locally or remotely or distributed, is another issue. And again, git handles both use cases, so what's your point? As explained before in this thread, replicating the git tree on the client still doesn't provide the required transparency. It has been pointed out to you that it DOES. Either that or nobody else understands your nebulous use of transparency so maybe you should define it like we've been asking you. Furthermore, the comment you replied to said nothing about transparency, nor did your comment it was in reply to; rather it was pointing out the fact that your statement that the git can not perform version control on the client is patently false. How is that different from what every SCM, including git, is doing today? The user needs to tell the scm when it's time to take a snapshot of the current state. Git is distributed though, so committing is usually not the same as publishing. Is that lack of a single command to commit and publish what's nagging you? If it's not, I completely fail to see what you're getting at, unless you've only ever looked at repositories without a worktree attached, or you think that git should work like an editor's undo functionality, which would be quite insane. You need to re-read the thread. Perhaps you should. We have been trying to get you to explain how you think git isn't transparent while at the same time pointing out how we think it is. You have failed to demonstrate any evidence to back up your claims, all of which have been shown to be false. -- 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 guidance
Al Boldi wrote: Judging an idea, based on a flawed implementation, doesn't prove that the idea itself is flawed. It isn't the implementation that is flawed, it is the idea. The entire point of a change control system is that you explicitly define change sets and add comments to the set. The filesystem was designed to allow changes to be made willy-nilly. If your goal is to perform change control only with filesystem semantics, then you have a non starter as their goals are opposing. Requiring an explicit command command is hardly burdensome, and otherwise, a git tree is perfectly transparent to non git aware tools. Sure, you wouldn't want to change the git-engine update semantics, as that sits on the server and handles all users. But what the git model is currently missing is a client manager. Right now, this is being worked around by replicating the git tree on the client, which still doesn't provide the required transparency. It isn't missing a client manager, it was explicitly designed to not have one, at least not as a distinct entity from a server, because it does not use a client/server architecture. This is very much by design, not a work around. What transparency are you requiring here? You can transparently read your git tree with all non git aware tools, what other meaning of transparency is there? IOW, git currently only implements the server-side use-case, but fails to deliver on the client-side. By introducing a git-client manager that handles the transparency needs of a single user, it should be possible to clearly isolate update semantics for both the client and the server, each handling their specific use-case. Any talk of client or server makes no sense since git does not use a client/server model. If you wish to use a centralized repository, then git can be set up to transparently push/pull to/from said repository if you wish via hooks or cron jobs. -- 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 guidance
Al Boldi wrote: Judging an idea, based on a flawed implementation, doesn't prove that the idea itself is flawed. It isn't the implementation that is flawed, it is the idea. The entire point of a change control system is that you explicitly define change sets and add comments to the set. The filesystem was designed to allow changes to be made willy-nilly. If your goal is to perform change control only with filesystem semantics, then you have a non starter as their goals are opposing. Requiring an explicit command command is hardly burdensome, and otherwise, a git tree is perfectly transparent to non git aware tools. Sure, you wouldn't want to change the git-engine update semantics, as that sits on the server and handles all users. But what the git model is currently missing is a client manager. Right now, this is being worked around by replicating the git tree on the client, which still doesn't provide the required transparency. It isn't missing a client manager, it was explicitly designed to not have one, at least not as a distinct entity from a server, because it does not use a client/server architecture. This is very much by design, not a work around. What transparency are you requiring here? You can transparently read your git tree with all non git aware tools, what other meaning of transparency is there? IOW, git currently only implements the server-side use-case, but fails to deliver on the client-side. By introducing a git-client manager that handles the transparency needs of a single user, it should be possible to clearly isolate update semantics for both the client and the server, each handling their specific use-case. Any talk of client or server makes no sense since git does not use a client/server model. If you wish to use a centralized repository, then git can be set up to transparently push/pull to/from said repository if you wish via hooks or cron jobs. -- 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: Possibly SATA related freeze killed networking and RAID
Tejun Heo wrote: Surprise, surprise. There's no way to tell whether the controller raised interrupt or not if command is not in progress. As I said before, there's no IRQ pending bit. While processing commands, you can tell by looking at other status registers but when there's nothing in flight and the controller determines it's a good time to raise a spurious interrupt, there's no way you can tell. That dang SFF interface is like 15+ years old. But we can still make things pretty robust. We're working on it. Thanks. It sounds like you mean that you know the controller did NOT raise the interrupt ( intentionally/correctly ) if there was no command in progress, as opposed to not being able to tell. Unless there is some condition under which it is valid for the controller to raise an interrupt when it had no commands in progress? And if that's the case and there's know way to know WHY, that's a broken design. -- 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: Possibly SATA related freeze killed networking and RAID
Tejun Heo wrote: Surprise, surprise. There's no way to tell whether the controller raised interrupt or not if command is not in progress. As I said before, there's no IRQ pending bit. While processing commands, you can tell by looking at other status registers but when there's nothing in flight and the controller determines it's a good time to raise a spurious interrupt, there's no way you can tell. That dang SFF interface is like 15+ years old. But we can still make things pretty robust. We're working on it. Thanks. It sounds like you mean that you know the controller did NOT raise the interrupt ( intentionally/correctly ) if there was no command in progress, as opposed to not being able to tell. Unless there is some condition under which it is valid for the controller to raise an interrupt when it had no commands in progress? And if that's the case and there's know way to know WHY, that's a broken design. -- 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: Possibly SATA related freeze killed networking and RAID
Tejun Heo wrote: Because SFF ATA controller don't have IRQ pending bit. You don't know whether IRQ is raised or not. Plus, accessing the status register which clears pending IRQ can be very slow on PATA machines. It has to go through the PCI and ATA bus and come back. So, unconditionally trying to clear IRQ by accessing Status can incur noticeable overhead if the IRQ is shared with devices which raise a lot of IRQs. There HAS to be a way to determine if that device generated the interrupt, or the interrupt can not be shared. Since the kernel said nobody cared about the interrupt, that indicates that the sata driver checked the status register and realized the sata chip didn't generate the interrupt, and returned to the kernel letting it know that the interrupt was not for 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: Possibly SATA related freeze killed networking and RAID
Tejun Heo wrote: Because SFF ATA controller don't have IRQ pending bit. You don't know whether IRQ is raised or not. Plus, accessing the status register which clears pending IRQ can be very slow on PATA machines. It has to go through the PCI and ATA bus and come back. So, unconditionally trying to clear IRQ by accessing Status can incur noticeable overhead if the IRQ is shared with devices which raise a lot of IRQs. There HAS to be a way to determine if that device generated the interrupt, or the interrupt can not be shared. Since the kernel said nobody cared about the interrupt, that indicates that the sata driver checked the status register and realized the sata chip didn't generate the interrupt, and returned to the kernel letting it know that the interrupt was not for 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: Possibly SATA related freeze killed networking and RAID
Tejun Heo wrote: Agreed. Nobody cared on ATA controllers is usually very effective at taking the whole machine down. Is there any reason why we don't turn on irqpoll on turned off IRQs automatically? Why does a single spurious interrupt cause it to be shut down? I can see if the interrupt is stuck on and keeps interrupting constantly, but if it's just the occasional spurious interrupt, why not just ignore it and move on? - 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/
