yright ownership over this code then there are a
great many other people you must contact and convince first.
I would encourage you to talk privately with the Software Freedom
Conservancy before sending more patches of this nature.
Cheers,
Kyle Moffett
> diff --git a/drivers/target/target_co
exclusive copyright ownership over this code then there are a
great many other people you must contact and convince first.
I would encourage you to talk privately with the Software Freedom
Conservancy before sending more patches of this nature.
Cheers,
Kyle Moffett
diff --git a/drivers/target
ated bug-fix^Wdirty hack
for sky2 to reset the PHY a second time during netif-up after enabling
interrupts; otherwise the immediate "link up" interrupt gets lost.
Once I get approval from the company I will patch the post itself for
review.
I look forward to your comments and suggestions
time during netif-up after enabling
interrupts; otherwise the immediate link up interrupt gets lost.
Once I get approval from the company I will patch the post itself for
review.
I look forward to your comments and suggestions
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line
t(void)
{
write_lock_bh(_policy_lock);
flow_cache_ignore = 0;
write_unlock_bh(_policy_lock);
}
Cheers,
Kyle Moffett
BEGIN QUOTED CODE INVOLVING flow_cache_genid:
include/net/flow.h:94:
extern atomic_t flow_cache_genid;
net/core/flow.c:39:
atomic_t flow_cache_genid = ATOMIC_INIT(0)
t;, possibly with
"dm-userspace" patched into the kernel to allow you to handle
non-mapped blocks in your userspace daemon when somebody tries to
access them. If you don't need that ability then straight dm-loop and
dm-linear will work.
Cheers,
Kyle Moffett
--
To unsubscribe from th
ad_pre(void)
{
write_lock_bh(_policy_lock);
flow_cache_genid++;
flow_cache_ignore = 1;
write_unlock_bh(_policy_lock);
}
void selinux_xfrm_notify_policyload_post(void)
{
write_lock_bh(_policy_lock);
flow_cache_ignore = 0;
write_unlock_bh(_policy_lock);
}
C
++;
flow_cache_ignore = 1;
write_unlock_bh(xfrm_policy_lock);
}
void selinux_xfrm_notify_policyload_post(void)
{
write_lock_bh(xfrm_policy_lock);
flow_cache_ignore = 0;
write_unlock_bh(xfrm_policy_lock);
}
Cheers,
Kyle Moffett
BEGIN QUOTED CODE INVOLVING flow_cache_genid
tries to
access them. If you don't need that ability then straight dm-loop and
dm-linear will work.
Cheers,
Kyle Moffett
--
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
ant.
For maximum readability and cleanliness I recommend that you leave off
the "extern" on the function declarations; it makes the lines much
longer without obvious gain.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
and cleanliness I recommend that you leave off
the extern on the function declarations; it makes the lines much
longer without obvious gain.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
ibly respond in kind with documentation patches).
Cheers,
Kyle Moffett
--
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/
with documentation patches).
Cheers,
Kyle Moffett
--
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/
(depending on the filesystem) so that troubled or frequently-rebooted
systems are more frequently verified. The end result is that I
almost never have the dreaded 4-hour-fsck-on-boot problem. A drive
has certainly been fscked within the last few weeks of operation, and
I will only ever ha
failure; you might fail to fully sync a FUSE filesystem because its
daemon is asleep waiting on something (possibly even just sitting in
a "sleep(1)" call with all signals masked). You simply need to
make sure that all tasks are asleep outside of driver critical
sections
(possibly even just sitting in
a sleep(1) call with all signals masked). You simply need to
make sure that all tasks are asleep outside of driver critical
sections so that you can properly suspend your device tree.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line
bugged, but under Linux it's effectively impossible
Cheers,
Kyle Moffett
--
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/
the appropriate
instructions, and then changes a 0 to a 1 (or vice versa) before
the conditional branch. On Windows it's vaguely practical (albeit
crash-prone) to load a kernel hack which prevents your program from
being debugged, but under Linux it's effectively impossible
Cheers,
Kyle
be not. But it
*is* an actual use of the API in a real app.
We weren't looking for "actual uses", especially not in binary-only
apps. What we are looking for is optimal uses of sched_yield(); ones
where that is the best alternative. This... certainly isn't.
Cheers,
Kyle Moffett
--
looking for actual uses, especially not in binary-only
apps. What we are looking for is optimal uses of sched_yield(); ones
where that is the best alternative. This... certainly isn't.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
be implemented in user-space or with small
modifications to existing UDP/TCP networking.
Cheers,
Kyle Moffett
--
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/
where we break locks
already for printk()), and I doubt any of the callers would notice
the serialization since they're already serialized on the printk buffer.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
for printk()), and I doubt any of the callers would notice
the serialization since they're already serialized on the printk buffer.
Cheers,
Kyle Moffett
--
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
/TCP networking.
Cheers,
Kyle Moffett
--
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/
in whatever fashion they desire. Typically if you price
your software reasonably people will be willing to pay for multiple
copies but there are no foolproof technical measures to enforce that
they do so.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe lin
software reasonably people will be willing to pay for multiple
copies but there are no foolproof technical measures to enforce that
they do so.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Nov 30, 2007, at 13:40:07, H. Peter Anvin wrote:
Kyle Moffett wrote:
With that said, there is a significant performance penalty as all
Objective-C method calls are looked up symbolically at runtime for
every single call.
GACK!
At least C++ has vtables.
In a tight loop there is a way
kernel though, there are many
codepaths where *every* *single* instruction counts; that could be a
serious performance hit.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On Nov 30, 2007, at 13:40:07, H. Peter Anvin wrote:
Kyle Moffett wrote:
With that said, there is a significant performance penalty as all
Objective-C method calls are looked up symbolically at runtime for
every single call.
GACK!
At least C++ has vtables.
In a tight loop there is a way
where *every* *single* instruction counts; that could be a
serious performance hit.
Cheers,
Kyle Moffett
-
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
use the appropriate commands, same as every
other VCS on the planet.
Cheers,
Kyle Moffett
-
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
commands, same as every
other VCS on the planet.
Cheers,
Kyle Moffett
-
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
hooks into Xen code very precisely to create and preserve the "No
pending page table updates" state that you care about. It will be
more work in the short term but it's the only maintainable solution
in the long term IMO.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the l
at
could be fixed with a few VFS and blockdev hooks which hierarchically
flush and "freeze" block devices and filesystems before actually
disabling devices much the way that device-mapper can pause a device
to take a snapshot and end up with a clean journal on the filesys
and blockdev hooks which hierarchically
flush and freeze block devices and filesystems before actually
disabling devices much the way that device-mapper can pause a device
to take a snapshot and end up with a clean journal on the filesystem
afterwards.
Cheers,
Kyle Moffett
-
To unsubscribe
the No
pending page table updates state that you care about. It will be
more work in the short term but it's the only maintainable solution
in the long term IMO.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
Kyle Moffett wrote:
Actually, a fully-secured strict-mode SELinux system will have no
unconfined_t processes; none of my test systems have any.
Generally "unconfined_t" is used for situations similar to what
AppArmor wa
On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote:
Kyle Moffett wrote:
Actually, a fully-secured strict-mode SELinux system will have no
unconfined_t processes; none of my test systems have any.
Generally unconfined_t is used for situations similar to what
AppArmor was designed for, where
ty to take any action on any object by
rules in the policy, and it typically still falls under a few MLS
labeling restrictions even in the targeted policy.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
still falls under a few MLS
labeling restrictions even in the targeted policy.
Cheers,
Kyle Moffett
-
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
r embedded architectures have very similar problems. Some may
provide an "unaligned data access" exception, but offer insufficient
information to repair the damage and resume execution.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
have very similar problems. Some may
provide an unaligned data access exception, but offer insufficient
information to repair the damage and resume execution.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
be expensive, but I believe the cost would
be reasonable for many applications and it would allow traditional
atomic ops on the mapped pages to take and release futexes in the
uncontended case.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
be expensive, but I believe the cost would
be reasonable for many applications and it would allow traditional
atomic ops on the mapped pages to take and release futexes in the
uncontended case.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
d possibly other configuration parameters.
I'm not really that much of an expert in this particular area,
though, so it's entirely possible that one of the above-mentioned
scheduler head-honchos will poke holes in my argument and give a
better explanation or a possible patch.
Cheers,
Ky
configuration parameters.
I'm not really that much of an expert in this particular area,
though, so it's entirely possible that one of the above-mentioned
scheduler head-honchos will poke holes in my argument and give a
better explanation or a possible patch.
Cheers,
Kyle Moffett
-ASCII, change ctype.c to ignore such characters
completely (the way they were before). Linus seems to think this is
a good thing, and he's the one that wrote the code in the first place.
Signed-off-by: Kyle Moffett <[EMAIL PROTECTED]>
---
On Nov 06, 2007, at 10:53:08, Linus Torvalds
-ASCII, change ctype.c to ignore such characters
completely (the way they were before). Linus seems to think this is
a good thing, and he's the one that wrote the code in the first place.
Signed-off-by: Kyle Moffett [EMAIL PROTECTED]
---
On Nov 06, 2007, at 10:53:08, Linus Torvalds wrote
rnal text format of the kernel is
UTF-8 as that encoding can represent any character in any other
encoding and it is backwards-compatible with traditional ASCII.
Cheers,
Kyle Moffett-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
UTF-8. (It doesn't work on special UTF-8 space
characters like nonbreaking space and similar, but handling those is
significantly more complicated).
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
UTF-8. (It doesn't work on special UTF-8 space
characters like nonbreaking space and similar, but handling those is
significantly more complicated).
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
of the kernel is
UTF-8 as that encoding can represent any character in any other
encoding and it is backwards-compatible with traditional ASCII.
Cheers,
Kyle Moffett-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
rded, but for the bash builtin it hangs around in the buffer
for a while and ends up getting prepended to the following echo
statement. There's actually multiple ways to make this fail; this is
just the simplest.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscri
for a while and ends up getting prepended to the following echo
statement. There's actually multiple ways to make this fail; this is
just the simplest.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
not
properly check the result of setuid() and just assumed it had
succeeded. So instead of running as "smtpd" it was running as
"root". Not a happy memory.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Oct 24, 2007, at 17:21:10, Matthew Wilcox wrote:
On Wed, Oct 24, 2007 at 04:59:48PM -0400, Kyle Moffett wrote:
This seems unlikely to work reliably as the various "v*printf"
functions modify the va_list argument they are passed. It may
happen to work on your particular ar
ably actually want to
make a copy of the varargs list for the first vsnprintf call.
Example below:
va_list argscopy;
va_copy(argscopy, args);
[...]
size = vsnprintf(s, sb->alloc - sb->len, format, argscopy)
[...]
s += sb->len - size;
vsprintf(s, format, args);
[...]
va_
On Oct 24, 2007, at 17:21:10, Matthew Wilcox wrote:
On Wed, Oct 24, 2007 at 04:59:48PM -0400, Kyle Moffett wrote:
This seems unlikely to work reliably as the various v*printf
functions modify the va_list argument they are passed. It may
happen to work on your particular architecture
not
properly check the result of setuid() and just assumed it had
succeeded. So instead of running as smtpd it was running as
root. Not a happy memory.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
of the varargs list for the first vsnprintf call.
Example below:
va_list argscopy;
va_copy(argscopy, args);
[...]
size = vsnprintf(s, sb-alloc - sb-len, format, argscopy)
[...]
s += sb-len - size;
vsprintf(s, format, args);
[...]
va_end(argscopy);
Cheers,
Kyle Moffett
-
To unsubscribe
On Oct 12, 2007, at 01:37:23, Al Boldi wrote:
Kyle Moffett wrote:
This isn't really necessary any more with the new CFS scheduler.
If you want to prevent excess memory usage then you limit memory
usage, not process count, so just set the system max process count
to something absurdly high
s one user and several thousand busy-loops as another user and
get almost picture perfect 50% CPU distribution between the users.
To me that seems a much better DoS-prevention system than limits
which don't scale based on how many people are requesting resources.
Cheers,
Kyle Moffett
-
To unsubs
On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
[snipped]
I'm still waiting to see the proposed SELinux policy that does what
Smack does.
That *is* the SELinux policy which does what Smack does. I keep
having bugs in the perl-scri
nnot directly implement without additional code, even
the "CAP_MAC_OVERRIDE" bit. If the semantics don't seem quite right,
please provide details about how you think the models differ and I
will try to address the concerns.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: se
o a
year or so.
Cheers,
Kyle Moffett
-
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/
m what we've done
for a while. You might want to do a git-blame on this bit of code to
see who the last person to modify it was and ask them to test or
confirm the patch first. The same general questions apply to the
other logical-op bugs.
Cheers,
Kyle Moffett
-
To unsubscribe from this lis
the last person to modify it was and ask them to test or
confirm the patch first. The same general questions apply to the
other logical-op bugs.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
to a
year or so.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to address the concerns.
Cheers,
Kyle Moffett
-
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/
On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
[snipped]
I'm still waiting to see the proposed SELinux policy that does what
Smack does.
That *is* the SELinux policy which does what Smack does. I keep
having bugs in the perl-script I'm
and several thousand busy-loops as another user and
get almost picture perfect 50% CPU distribution between the users.
To me that seems a much better DoS-prevention system than limits
which don't scale based on how many people are requesting resources.
Cheers,
Kyle Moffett
-
To unsubscribe from
On Oct 12, 2007, at 01:37:23, Al Boldi wrote:
Kyle Moffett wrote:
This isn't really necessary any more with the new CFS scheduler.
If you want to prevent excess memory usage then you limit memory
usage, not process count, so just set the system max process count
to something absurdly high
mes a noticeably
invalid __attribute__((__attribute__((__pure__
Cheers,
Kyle Moffett
-
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/
((__attribute__((__pure__
Cheers,
Kyle Moffett
-
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/
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett <[EMAIL PROTECTED]> writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is generally
incomprehensible I don't know which. Or someone long ago would
have said a bette
ing out what seems too
complicated in SELinux and making it simpler. Probably a fair amount
of that just means better tools.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
and making it simpler. Probably a fair amount
of that just means better tools.
Cheers,
Kyle Moffett
-
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
On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
Kyle Moffett [EMAIL PROTECTED] writes:
On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
SElinux is not all encompassing or it is generally
incomprehensible I don't know which. Or someone long ago would
have said a better way
enough...
Well actually, I believe you could just do:
struct kprint_block {
const int loglevel;
[...];
};
Then cast away the constness to actually set it initially:
*((int *)) = LOGLEVEL;
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe
is actually
smart enough...
Well actually, I believe you could just do:
struct kprint_block {
const int loglevel;
[...];
};
Then cast away the constness to actually set it initially:
*((int *)block.loglevel) = LOGLEVEL;
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send
e made useful, so perhaps it's not the
greatest idea.
I think the primary importance for this functionality is:
* Autorenaming of symlinks according to the name format string
when target or one of its ancestors is renamed or moved. This
only applies when new interface is used.
Nice.
Cheers,
lly always the latest Debian stable).
Cheers,
Kyle Moffett
-
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/
the latest Debian stable).
Cheers,
Kyle Moffett
-
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/
not the
greatest idea.
I think the primary importance for this functionality is:
* Autorenaming of symlinks according to the name format string
when target or one of its ancestors is renamed or moved. This
only applies when new interface is used.
Nice.
Cheers,
Kyle Moffett
-
To unsubscribe from
st going to burn a
bunch of CPU anyways
(B) It really is extremely unlikely that it fails (Think physical
hardware failure)
Anything else is just bogus.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
ry component of *EVERY* open/chdir-ish syscall,
you are still going to be easily worked around through many different
methods.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
On Sep 26, 2007, at 06:27:38, David Newall wrote:
Kyle Moffett wrote:
David, please do tell myself and Adrian how "locking down" chroot
() the way you want will avoid letting root break out through any
of the above ways?
As has been said, there are thousands of ways to
On Sep 26, 2007, at 06:27:38, David Newall wrote:
Kyle Moffett wrote:
David, please do tell myself and Adrian how locking down chroot
() the way you want will avoid letting root break out through any
of the above ways?
As has been said, there are thousands of ways to break out of a
chroot
component of *EVERY* open/chdir-ish syscall,
you are still going to be easily worked around through many different
methods.
Cheers,
Kyle Moffett
-
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
anyways
(B) It really is extremely unlikely that it fails (Think physical
hardware failure)
Anything else is just bogus.
Cheers,
Kyle Moffett
-
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
se SELinux or capabilities, in which
case you could just take away the CAP_SYS_CHROOT capability in the
first place!
Cheers,
Kyle Moffett
-
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.
east until better group-scheduling tools are produced.
Cheers,
Kyle Moffett
-
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/
group-scheduling tools are produced.
Cheers,
Kyle Moffett
-
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/
or capabilities, in which
case you could just take away the CAP_SYS_CHROOT capability in the
first place!
Cheers,
Kyle Moffett
-
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
into memory. Kernel is stock Debian and
hardly has enough built-in to spit at you, let alone find network/
disks, but it manages to load everything it needs off the
automagically-generated initramfs.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe
where they were
called from).
Proper fix is to give __kmalloc a "void *caller" parameter and have
all of the various wrapper functions pass in the value of
__builtin_return_address() appropriately. I believe that even works
properly for inline functions which may or may not be inl
-level allocations of IPv4 space:
http://xkcd.com/195/
Cheers,
Kyle Moffett
-
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 FA
-level allocations of IPv4 space:
http://xkcd.com/195/
Cheers,
Kyle Moffett
-
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
is to give __kmalloc a void *caller parameter and have
all of the various wrapper functions pass in the value of
__builtin_return_address() appropriately. I believe that even works
properly for inline functions which may or may not be inlined.
Cheers,
Kyle Moffett
-
To unsubscribe from this list
into memory. Kernel is stock Debian and
hardly has enough built-in to spit at you, let alone find network/
disks, but it manages to load everything it needs off the
automagically-generated initramfs.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line unsubscribe linux
1 - 100 of 716 matches
Mail list logo
