Bug#676360: [Xen-devel] [PATCH] thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE\
Hi, On Mon, Jun 11, 2012 at 03:27:38PM -0400, Konrad Rzeszutek Wilk wrote: Nice. Andrew, any chane you could test this patch on the affected Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?) hypervisor or is it really only on Linode and Amazon EC2? Originally, I was able to reproduce the issue easily with a RHEL5 host. Now, with this patch it's fixed. OK, so Tested-by: Andrew Jones.. and from my perspective it looks good - so Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Thanks for testing and reviews. Andrea, any chance you can respin this patch and send it to Linus for 3.5 please? Andrew merged it in -mm last Friday, so I would expect it to go upstream soon through the -mm flow (I assume everyone has been rightfully waiting a bit of time for testing and reviews to be sure). Andrea -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120611194113.gh3...@redhat.com
Bug#676360: xen: oops at atomic64_read_cx8+0x4
On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote: Sergio Gelato wrote[1]: That 3.4.1-1~experimental.1 build (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux) is even less well-behaved under Xen: I'm getting a kernel OOPS at EIP: [c1168e54] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c The top of the trace message unfortunately scrolled off the console before I could see it, and the message doesn't have time to make it to syslog (either local or remote). [...] Non-Xen boots proceed normally. Yeah, apparently[2] that's caused by commit 26c191788f18 Author: Andrea Arcangeli aarca...@redhat.com Date: Tue May 29 15:06:49 2012 -0700 mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition which was also included in Debian kernel 3.2.19-1. [1] http://bugs.debian.org/676360 [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4 Oops, sorry I didn't imagine atomic64_read on a pmd would trip. Unfortunately to support pagetable walking with mmap_sem hold for reading, we need an atomic read on 32bit PAE if CONFIG_TRANSPARENT_HUGEPAGE=y. The only case requiring this is 32bit PAE with CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work around this as I optimized the code in a way to avoid an expensive cmpxchg8b. I guess if Xen can't be updated to handle an atomic64_read on a pmd in the guest, we can add a pmd_read paravirt op? Or if we don't want to break the paravirt interface a loop like gup_fast with irq disabled should also work but looping + local_irq_disable()/enable() sounded worse and more complex than a atomic64_read (gup fast already disables irqs because it doesn't hold the mmap_sem so it's a different cost looping there). AFIK Xen disables THP during boot, so a check on THP being enabled and falling back in the THP=n version of pmd_read_atomic, would also be safe, but it's not so nice to do it with a runtime check. Thanks, Andrea -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120607103355.ga21...@redhat.com
Bug#676360: [Xen-devel] xen: oops at atomic64_read_cx8+0x4
Hi, On Thu, Jun 07, 2012 at 11:56:47AM -0400, Konrad Rzeszutek Wilk wrote: then the high part. Why that would trip the hypervisor is not clear to me. Perhaps in the past it only read the That is the CONFIG_TRANSPARENT_HUGEPAGE=n case and in fact it doesn't trip the hypervisor. That was tested too, it should work fine. The problem is with the atomic64_read version, that one uses cmpxchg8b to read the contents of the pmdp. Ah, by just skipping the thing if the low bits are zero. Yep. didn't like somebody reading the high and low bit, but isn't the pmdval_t still 64-bit ? So I would have thought this would The pmd format is unchanged, that's hardware. The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora 17 dom0. So it looks like this is reading high part is fixed on the newer hypervisors, but now with the older ones. And the older one is Amazon EC2 so some .. hack to workaround older hypervisors could be added. The insn oopsing is cmpxchg8b and it's not reading the low/high part in two separate insn but reading it in a single insn, which means the kernel oopsing was built with CONFIG_TRANSPARENT_HUGEPAGE=y. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120607161704.ge21...@redhat.com
Bug#676360: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
Hi,
this should avoid the cmpxchg8b (to make Xen happy) but without
reintroducing the race condition. It's actually going to be faster
too, but it's conceptually more complicated as the pmd high/low may be
inconsistent at times, but at those times we're going to declare the
pmd unstable and ignore it anyway so it's ok.
NOTE: in theory I could also drop the high part when THP=y thanks to
the barrier() in the caller (and the barrier is needed for the generic
version anyway):
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
u32 *tmp = (u32 *)pmdp;
ret = (pmdval_t) (*tmp);
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
if (ret) {
/*
* If the low part is null, we must not read the high part
* or we can end up with a partial pmd.
*/
smp_rmb();
ret |= ((pmdval_t)*(tmp + 1)) 32;
}
+#endif
return (pmd_t) { ret };
}
But it's not worth the extra complexity. It looks cleaner if we deal
with good pmds if they're later found pointing to a pte (even if we
discard them and force pte_offset to re-read the *pmd).
Andrea Arcangeli (1):
thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
arch/x86/include/asm/pgtable-3level.h | 30 +-
include/asm-generic/pgtable.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1339102833-12358-1-git-send-email-aarca...@redhat.com
Bug#676360: [PATCH] thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding
the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
contents under Xen.
So instead of dealing only with consistent pmdvals in
pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
where the low 32bit and high 32bit could be inconsistent (to avoid
having to use cmpxchg8b).
The only guarantee we get from pmd_read_atomic is that if the low part
of the pmd was found null, the high part will be null too (so the pmd
will be considered unstable). And if the low part of the pmd is found
stable later, then it means the whole pmd was read atomically
(because after a pmd is stable, neither MADV_DONTNEED nor page faults
can alter it anymore, and we read the high part after the low part).
In the 32bit PAE x86 case, it is enough to read the low part of the
pmdval atomically to declare the pmd as stable and that's true for
THP and no THP, furthermore in the THP case we also have a barrier()
that will prevent any inconsistent pmdvals to be cached by a later
re-read of the *pmd.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
arch/x86/include/asm/pgtable-3level.h | 30 +-
include/asm-generic/pgtable.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/pgtable-3level.h
b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..cb00ccc 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
* they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
* operations.
*
- * Without THP if the mmap_sem is hold for reading, the
- * pmd can only transition from null to not null while pmd_read_atomic runs.
- * So there's no need of literally reading it atomically.
+ * Without THP if the mmap_sem is hold for reading, the pmd can only
+ * transition from null to not null while pmd_read_atomic runs. So
+ * we can always return atomic pmd values with this function.
*
* With THP if the mmap_sem is hold for reading, the pmd can become
- * THP or null or point to a pte (and in turn become stable) at any
- * time under pmd_read_atomic, so it's mandatory to read it atomically
- * with cmpxchg8b.
+ * trans_huge or none or point to a pte (and in turn become stable)
+ * at any time under pmd_read_atomic. We could read it really
+ * atomically here with a atomic64_read for the THP enabled case (and
+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we
+ * only return an atomic pmdval if the low part of the pmdval is later
+ * found stable (i.e. pointing to a pte). And we're returning a none
+ * pmdval if the low part of the pmd is none. In some cases the high
+ * and low part of the pmdval returned may not be consistent if THP is
+ * enabled (the low part may point to previously mapped hugepage,
+ * while the high part may point to a more recently mapped hugepage),
+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
+ * of the pmd to be read atomically to decide if the pmd is unstable
+ * or not, with the only exception of when the low part of the pmd is
+ * zero in which case we return a none pmd.
*/
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
@@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
return (pmd_t) { ret };
}
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
-{
- return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
-}
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
{
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index ae39c4b..0ff87ec 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -484,6 +484,16 @@ static inline int
pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
/*
* The barrier will stabilize the pmdval in a register or on
* the stack so that it will stop changing under the code.
+*
+* When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
+* pmd_read_atomic is allowed to return a not atomic pmdval
+* (for example pointing to an hugepage that has never been
+* mapped in the pmd). The below checks will only care about
+* the low part of the pmd with 32bit PAE x86 anyway, with the
+* exception of pmd_none(). So the important thing is that if
+* the low part of the pmd is found null, the high part will
+* be also null or the pmd_none() check below would be
+* confused.
*/
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
barrier();
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe
Bug#474648: seccomp is zero runtime overhead
On Thu, Apr 10, 2008 at 09:28:24AM +0200, Sven Luther wrote: What about non-x86 architectures, well i guess ia64 and powerpc/powerpc64 are the most interesting candidates. It should be zero cost there too if it has been implemented correctly. The only feature that initially generated a minimum overhead to the scheduler was present on x86 (the TIF_NOTSC removed that overhead from the fast path completely). This is because disabling the tsc was mostly an issue for Intel hyperthreading and not for anything else so all other archs should have seccomp implementations that have always been zero cost like in x86-64. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474648: seccomp is zero runtime overhead
Hello, The story about seccomp is that as long as there are users CPUShare will support it because it's a more efficient and more secure computing model. About the seccomp overhead, that is zero. It adds zero overhead to the fast path of the scheduler. It never added any overhead on x86-64. For x86 I added a tsc_disable feature that wasn't zero overhead initially and so that was used as argument against seccomp (despite it really had little to do with the seccomp core), it is zero overhead now that I optimized that little tsc_disable feature. So you can always enable seccomp on x86-64 without performance worries (I guess it only adds an hundred byte of .text). On x86 you can enable seccomp as safely as on x86-64 if you find a TIF_NOTSC implemented in your x86 32bit kernel. TIF_NOTSC is zerocost and so after implementing TIF_NOTSC, I changed seccomp to use it to avoid any overhead in all archs. In the latest kernels the only overhead generated by seccomp is a bit larger .text image, everything else is false or obsolete. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sun, Jan 08, 2006 at 08:31:50AM +0100, Sven Luther wrote: You are not interested in recordying the debian abi number, or the flavour as a subset of the architecture used ? This seems like interesting info. KLive wasn't originally designed to track distro packages, but mainline or/and self-built kernels. So at the moment there's simply no place to store this debian info in the db. I store the uname -m which provides some interesting info too. I could of course add abi and flavour, but I'd prefer to try to add stuff that can work for other distro too, so it needs more thoughts. Right now your /proc/version allows to reliably identify the branch (i.e. Debian) and the package version, so it's already very useful (and I already fixed the server code to parse it correctly ;). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sun, Jan 08, 2006 at 08:48:20AM +0100, Sven Luther wrote: You could simply add the two distro-specific information, the full package name (2.6.14-2-amd64-k8) and the distro version number (2.6.14-7). I guess in additional often-intrusive patches, and will probably use a meaningful name. it will be embedded in the uname -r name too, probably as version-abi-subarch-flavour. I already store the 'uname -r' as `kernel_release` and the debian package version is now stored as `kernel_group`, and 'Debian' string is the `branch`. I simply don't yet split the info in the kernel_release into abi/flavour, but thinking about it I can make it visible in the local column (still not splitted but that's ok). The place where to put it was more a problem in the visualization than in the storage (since I store /proc/version so no useful info can get lost ;). The local column is what I use to show the git tag for example with mainline. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Wed, Sep 14, 2005 at 05:02:18PM +0200, Sven Luther wrote:
On Wed, Sep 14, 2005 at 04:46:04PM +0200, Andrea Arcangeli wrote:
On Wed, Sep 14, 2005 at 11:18:46AM +0200, Sven Luther wrote:
On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote:
On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote:
Not a good idea. Why clutter the namespace of versions in order to
adapt to
non-debian needs. ? What is it you intent to do anyway ?
Thanks to Bastian Blank, code was added to make your life easier,
/proc/version now shows the debian version after the kernel version as :
(Debian 2.6.13-1)
For example, not yet in released packages, and will not account for self
compiled kernels from the debian sources, but it should be usefull to you.
Yes, that's nice thanks!
Could you show me a full /proc/version?
10:49 waldi Linux version 2.6.13-1-powerpc64 (Debian 2.6.13-1)
([EMAIL PROTECTED]) (gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6))
#1 SMP Wed Sep 14 09:28:56 UTC 2005
I enabled the parsing in KLive protocol 1 of the /proc/version according
to the above format.
As always in my code I'm paranoid and I added some overkill debugging
runtime check, and (as usual) they triggered.
See the SMS the server sent me:
File /home/klive/klive/server/regexp.py, line 69, in
select_kernel_group_and_branch
raise 'corrupted proc version', (version.groups(), kernel_release,
kernel_proc_version)
corrupted proc version: (('2.6.14-2-amd64-k8', 'Debian', '2.6.14-7'),
'2.6.14-2-amd64-k8', 'Linux version 2.6.14-2-amd64-k8 (Debian 2.6.14-7)
([EMAIL PROTECTED]) (gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5))
#2 Fri Dec 30 06:24:03 CET 2005\n')
The debugging check is this:
if version.group(1)[:len(version.group(3))] != version.group(3):
raise 'corrupted proc version', (version.groups(),
kernel_release, kernel_proc_version)
(originally it was:
assert version.group(1)[:len(version.group(3))] == version.group(3)
but I changed it to be more verbose after I noticed it was firing
exceptions and rejecting packets)
In short the above assert is verifying that 2.6.14-7 is a substring of
2.6.14-2-amd64-k8. Clearly something went wrong in the debian kernel
build process if somebody has a uname -r == 2.6.14-2-amd64-k8 but the
kernel group is 2.6.14-7.
Note, I can as well delete this check from the server, but then kernels
with uname -r == 2.6.14-2-amd64-k8 will be classified under the group
2.6.14-7 which sounds wrong. Currently the packet is rejected right
away by twisted when the unhandled exception is fired by the assert.
Please let me know if I can help solving this.
Thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sun, Jan 08, 2006 at 08:04:33AM +0100, Sven Luther wrote: -1 was both the abi number and the debian revision. I guess you need to fix your script again :) The client sends a plain /proc/version, so fixing this is very easy to fix this on the server side. And none of those is really a subset of the other, altough the debian package version is clearly the most unique and maps uniquely to both the kernel version and the abi (but not the flavour). The main objective of this whole info was to drop the flavour, so I think taking the debian package version is correct. All kernels with the same debian package version will be then accounted together. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Wed, Sep 14, 2005 at 11:18:46AM +0200, Sven Luther wrote: On Sat, Sep 10, 2005 at 05:19:07PM +0200, Andrea Arcangeli wrote: On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote: Not a good idea. Why clutter the namespace of versions in order to adapt to non-debian needs. ? What is it you intent to do anyway ? Thanks to Bastian Blank, code was added to make your life easier, /proc/version now shows the debian version after the kernel version as : (Debian 2.6.13-1) For example, not yet in released packages, and will not account for self compiled kernels from the debian sources, but it should be usefull to you. Yes, that's nice thanks! Could you show me a full /proc/version? It's unfortunate my current client isn't logging /proc/version yet, so I should update the client soon. Logging /proc/version is a good idea anyway to know the compiler used. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sun, Sep 11, 2005 at 07:35:02AM +0200, Sven Luther wrote: and report data ? If so, you may look into the popularity context package ? Does that work for all distro out there? Could you post the url of the equivalent of a klive.cpushare.com chart so we can compare? (google pointed me to the package, not to the chart) If you can improve this regexp (which seems the way to go for now) you're very welcome: 'Debian' : re.compile(r'^(\d+)\.(\d+)\.(\d+)(?:-git(\d+)|\.(\d+)|-rc(\d+))?-(\d+)-(?:[3456]86|k7|generic|amd64-k8)') Right now I only added the basics to catch the most frequent archs in klive unknown listing, it's true I can't catch all 12 archs if somebody would be running klive on top of them. Well, i guess i would not do it like you do ? Why have only a single regext, instead of a case switch for example, or better yet two case switches, one matching uname -m, and then going for uname -r. Why should I go for uname first? I want all archs to fit in the single uname -r. If you click on 2.6.13 it will show internally all different archs. If you're interested in a single arch just click the filter at the top, click on x86-64 and you'll see the stats only for x86-64 (see NR going down etc..). Why should I care about uname -m, when I've the filter at the top? I still think you are taking the wrong approach here, maybe you shouild propose a speacial patch, which each distribution could apply and fill a data with distribution info, and which would then appear in /proc/version, and not try to get distributions to polute the version namespace. That is a fine solution too. I proposed to polute the version namespace first because that sounded the right thing to do to me, despite you didn't like it. I'd rather keep it separated from /proc/version but that's just an implementation detail. Notice also, that on a debian system, you may find the exact sert of patches applied in : /usr/src/patches :) Sorry but I'd rather not depend on people not messing /usr/src and more important I'd rather avoid distro dependent details. Since the ubuntu kernel seems to be very different from debian kernel, I wonder how I can detect it with uname -r, I guess I can't right now. Like said, wrong approach. Keep in mind this was written for the mainline kernels running on all sort of userland (where most people normally don't mess with localversion before compiling), what you see online (i.e. probably mixing ubuntu and debian) seems the best thing I can do right now. Well, i even doubt it will work well for mainline, since people can and will modify the version to suite them best, or apply a random set of patches. well, as a matter of fact it works pretty well already, count the number of mainline entries compared to the number of unknown entries. It's possible somebody patched the kernel, but it doesn't need to be perfect, and even if they patched the kernel, they're still testing the 2.6.13 codebase so it's not that bad (just like what Andres said about debian, that you don't apply many patches, so ideally you could be accounted like mainline kernels, but for ubuntu this is not the case and currently I can't even detect the difference between ubuntu and Debian ;). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sun, Sep 11, 2005 at 06:10:47PM +0200, Sven Luther wrote: Nope,; it works for debian packages. But you can match that to kernels. not quite, you never know what kernel the system is running if you don't call uname -r sorry. Note that klive is written for _mainline_ kernels, see the homepage (without screening args). Adding the debian screen is just a minor feature that I could as well remove if they remain undetectable. Klive has nothing to do with debian or suse or any other distro, it was made for the mainline kernels only. But apparently a number of people is running it in combination with the distro kernels, and in turn I'm trying to be nice and detect them (or at least filter them out of the homepage without args). arch basis, especially as it might be that two flavours on two different arches share the same name. Not sure if this is the case right now. So the mess is even higher than what I originally thought... If different flavours of debian can have the same uname -r means the uname -r is meaningless on debian, you could call it foo and it'd be the same. That doesn't mean it doesn't work at runtime, it just means there's no way to know what flavour is running by checking uname -r. Well, possibly, but i have some doubt of the values of it. Actually, there is a sure way of doing this, you could simply get a database of all the ubuntu or debian kernels out there (they are all archived), and then simply match their md5sum against the md5sum of the installed kernel (which is /boot/vmlinu[zx]-`uname -r`). That way, you have no doubts ay all :) Using the database is attractive as an heuristic for the names (and I can match the uname -m as well if needed), but I'm unsure about the md5 way. You can call the kernel name as you want, you can call it /boot/foo and set grub to /boot/foo, and the uname -r may well be 2.6.13-something. So it's not certain which image in /boot we'd need to take the snapshot of. It may even be deleted by the time the client runs. Amittedly those are corner cases, but if I've to make substantial changes I'd prefer something really reliable. Assume debian by default :) I am not sure, but i guess ubuntu and debian use another set of flavours even, but if you really want to do it right, the most sure way is the md5sum database. I feel that adding a /proc/branch or something like that is easier and completely reliable, its only disavantage is that it requires (trivial) kernel changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote: Not a good idea. Why clutter the namespace of versions in order to adapt to non-debian needs. ? What is it you intent to do anyway ? My intent is to be able to tell the branch of the kernel based on `uname -r` (per subject). So if I see 2.6.13-whatever-debian it means it was a kernel patches by the debian patchset. If I see 2.6.16-3-ppc64 I don't know for sure where it comes from. -mm adds -mm, -ck adds -ck, ac adds ac, fedora adds FC, RT adds -rt, basically anybody who makes substantial changes is already doing the thing you call cluttering the namespace. So it doesn't sound such a terrible thing from my point of view. I don't see what's the bad thing about marking -debian or -deb the kernels that you _modify_ with your set of patches. I'm not saying that you have to add -deb if you _don't_ modify the kernel source, infact I believe you shouldn't add -deb unless you change the kernel source. But if you apply your own patches (like -mm,-ck,-ac,FC,EL,etc..etc..) then what's wrong at being able to identify which patchset was applied like it's already possible for many other branches? more /proc/version Linux version 2.6.12-1-powerpc ([EMAIL PROTECTED]) (gcc version 4.0.2 20050806 (prerelease) (Debian 4.0.1-4)) #1 Tue Aug 16 20:08:54 UTC 2005 That's the compiler, I'm not tracking the compiler. In theory I could, but then it would get wrong if I would grab a debian kernel and compile it under suse. However if I fail to idenfiy the branch of the kernels based on `uname -r`, I agree the fallback would be to use the compiler to identify the branch (even if it's not completely reliable). Personally I also see as pointless to add 686 or k7 in the name, why don't you simply enable /proc/config.gz that will tell the user a _lot_ more than just the cpu compilation selection? But that's quite offtopic, my intent was only to try to identify the kernel vendor/branches. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sat, Sep 10, 2005 at 05:33:29PM +0200, Sven Luther wrote: Sure, i am not stupid, i perfectly noticed that, now my question is why do you want to know that ? That's for the klive project, I added two links in the first email just check it again. Sure, it is a debian system, running a debian kernel, and that's it. If you want you can look at the uname -r output, then look at /lib/modules/version and look in your dpkg database to match it to a package, something like that : dpkg -S /lib/modules/`uname -r` Or even : if dpkg -S /lib/modules/`uname -r` ; then echo DEBIAN; else echo NOT DEBIAN; fi I don't want to call dpkg or rpm, I was hoping to get it from uname -r, if I were to create an universal package management knowledge for all distro out there, I wouldn't be asking to add the name in the uname -r. Sure, you have a debian system, you should have a debian kernel, if you don't I disagree, you can run the mainline or other distro kernels as well, what's wrong with that? Do you deviate from the mainline kernel API to the point of requiring a debian kernel on a debian userland? I certainly hope not. flavours, which are not compatible with each other) ? Also notice that /boot/config-`uname -r` will give you all the info you need about the running kernel's config file. Unless you're running a kernel from an other distro that collides with your uname -r which apparently can happen. Anyway the way you answered, it sounds like it wasn't good idea about asking here so just forget my email, I feel nothing is going to change and that my little project or collisions in /boot/config-`uname -r` won't be nearly enough arguments to add the branch name to the kernel (like -mm/-ck/FC/etc..). So I'll stick with the regexp mess that can identify quite some debian kernel already even if it's unreliable (cause it's still simpler than dealing with dpkg/rpm or /etc in all different distro flavours, which would require frequent client updates too). Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sat, Sep 10, 2005 at 05:35:56PM -0400, Andres Salomon wrote: Quite honestly, I don't think we deviate enough from the mainline kernels enough to warrant such a thing. The main patches we include are the stable kernel patches, misc fixes backported from linus' git repo, architecture patches (that don't affect 99% of our users, as 99% of our users are using x86 or x86_64 kernels), and legacy feature/modularization patches that we're trying to get rid of. When we upgrade to the latest linus release, we end up dropping the majority of our patches. Our goal is to get as close to mainline as possible, so that we're not maintaining a huge set of patches. Ok fine, so the main reason for a different uname -r from mainline seems to be to allow installing more than one kernel compiled with different options on the same system (or other buildsystem details), right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Sat, Sep 10, 2005 at 09:42:17PM +0200, Sven Luther wrote: On Sat, Sep 10, 2005 at 08:02:38PM +0200, Sven Luther wrote: On Sat, Sep 10, 2005 at 05:57:12PM +0200, Andrea Arcangeli wrote: On Sat, Sep 10, 2005 at 05:33:29PM +0200, Sven Luther wrote: Sure, i am not stupid, i perfectly noticed that, now my question is why do you want to know that ? That's for the klive project, I added two links in the first email just check it again. Also, your list is bogus, debian supports actually 12 architectures, and you only list x86 flavours. Mmm, rereading me this sounds a bit too aggresive, which was not my intention, The reason klive don't list all 12 archs is primarly because there are no klive users coming from all those 12 archs. See the unknown list. If you can improve this regexp (which seems the way to go for now) you're very welcome: 'Debian' : re.compile(r'^(\d+)\.(\d+)\.(\d+)(?:-git(\d+)|\.(\d+)|-rc(\d+))?-(\d+)-(?:[3456]86|k7|generic|amd64-k8)') Right now I only added the basics to catch the most frequent archs in klive unknown listing, it's true I can't catch all 12 archs if somebody would be running klive on top of them. Since the ubuntu kernel seems to be very different from debian kernel, I wonder how I can detect it with uname -r, I guess I can't right now. Anyway klive was made primarly for mainline, so I don't care that much if I can't differentiate between debian and ubuntu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how to detect a debian kernel from `uname -r`
Hello everyone, I'm trying to detect a debian kernel from uname -r. My suggestion would be to add a -debian at the end of the localversion of kernels _patched_/modified by debian, and to leave the localversion completely _empty_ (or an unchanged localversion compared to the mainline defconfig) for unmodified mainline kernels shipped by debian (if you ship them in the first place). I also wonder how to detect ubuntu kernels, perhaps they're the same as debian I don't know. If they're the same from a sourcecode standpoint then I guess it's better to call them -debian too at the end of the extraversion. Note: I don't care about which userland is running, I only care to detect the kernel branch that is running (i.e. mainline/mm/ac/debian/suse/fedora etc..), so trying to detect the distro in userland is not an option (plus I suspect it would be even less standard). Currently I'm using this regexp and it still can't detect everything, plus I hope I'm not marking as debian kernels that are identical to mainline from a sourcecode standpoint (I'm not tracking _who_ compiled it): 'Debian' : re.compile(r'^(\d+)\.(\d+)\.(\d+)(?:\.?(\d+)?|-rc(\d+))(?:-git(\d+))?-(\d+)-(?:[3456]86|k7|generic|amd64-k8)'), Full GPL'd sourcecode of the regexp is here: http://klive.cpushare.com/downloads/klive-0.7.tar.bz2 see the branch_regexp in klive/server/web.py. You can see the results of the current regexp here: http://klive.cpushare.com/?branch=Debian but I can't detect everything, for example in unknown there are still debian kernels very strangely called -p4-2 (google tells me it comes from some .deb package): http://klive.cpushare.com/?branch=unknown No idea what the -2 at the end stands for (perhaps it's compiled with max_cpus=2?). Suggestions are welcome. Thanks! PS. I'm off-list so please make sure to include me in CC if the list software adds a reply-to: to the email. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
