Re: [kernel-hardening] [PATCH v4 02/10] asm/nospec, array_ptr: sanitize speculative array de-references
Jann Horn writes:
>> +/*
>> + * If idx is negative or if idx > size then bit 63 is set in the mask,
>> + * and the value of ~(-1L) is zero. When the mask is zero, bounds check
>> + * failed, array_ptr will return NULL.
>> + */
>> +#ifndef array_ptr_mask
>> +static inline unsigned long array_ptr_mask(unsigned long idx,
>> unsigned long sz)
>> +{
>> + return ~(long)(idx | (sz - 1 - idx)) >> (BITS_PER_LONG - 1);
>> +}
>> +#endif
>
> Nit: Maybe add a comment saying that this is equivalent to
> "return ((long)idx >= 0 && idx < sz) ? ULONG_MAX : 0"?
That's only true when sz < LONG_MAX, which is documented below but not
here; it's also different from the asm version, which doesn't do the idx
<= LONG_MAX check. So making the constraint explicit would be a good idea.
>From a bit of experimentation, when the top bit of sz is set, this
expression, the C version and the assembler version all have different
behaviour. For example, with 32-bit unsigned long:
index= size=8001: expr= c= asm=
index=8000 size=8001: expr= c= asm=
index= size=a000: expr= c= asm=
index=0001 size=a000: expr= c= asm=
index=fffe size=: expr= c= asm=
It may be worth noting that:
return 0 - ((long) (idx < sz));
causes GCC, on ia32 and amd64, to generate exactly the same cmp/sbb
sequence as in Linus's asm. Are there architectures where this form
would allow speculation?
Thanks,
--
Adam Sampson <http://offog.org/>
[PATCH v2] ASoC: sun4i-codec: use consistent names for PA controls
The power amplifier for the headphone output is called "the PA" and "the
headphone amplifier" in Allwinner's documentation for the A10 and A20.
sun4i-codec calls it "PA" in some places and "Pre-Amplifier" (which
isn't really accurate) in others, leading to user-visible controls with
different names referring to the same device.
When this driver implements audio input, it'll also need to expose
controls for the line and mic input preamps, so just referring to "the
Pre-Amplifier" will be ambiguous.
Change it to use "Power Amplifier" consistently for the power
amplifier's controls.
Signed-off-by: Adam Sampson
---
Changes in v2:
- use "Power Amplifier" rather than "PA"
---
sound/soc/sunxi/sun4i-codec.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index bcbf4da..1bb896d 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -2,6 +2,7 @@
* Copyright 2014 Emilio López
* Copyright 2014 Jon Smirl
* Copyright 2015 Maxime Ripard
+ * Copyright 2015 Adam Sampson
*
* Based on the Allwinner SDK driver, released under the GPL.
*
@@ -404,7 +405,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
- SOC_SINGLE_TLV("PA Volume", SUN4I_CODEC_DAC_ACTL,
+ SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
sun4i_codec_pa_volume_scale),
};
@@ -452,12 +453,12 @@ static const struct snd_soc_dapm_widget
sun4i_codec_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("Mixer Enable", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_MIXEN, 0, NULL, 0),
- /* Pre-Amplifier */
- SND_SOC_DAPM_MIXER("Pre-Amplifier", SUN4I_CODEC_ADC_ACTL,
+ /* Power Amplifier */
+ SND_SOC_DAPM_MIXER("Power Amplifier", SUN4I_CODEC_ADC_ACTL,
SUN4I_CODEC_ADC_ACTL_PA_EN, 0,
sun4i_codec_pa_mixer_controls,
ARRAY_SIZE(sun4i_codec_pa_mixer_controls)),
- SND_SOC_DAPM_SWITCH("Pre-Amplifier Mute", SND_SOC_NOPM, 0, 0,
+ SND_SOC_DAPM_SWITCH("Power Amplifier Mute", SND_SOC_NOPM, 0, 0,
&sun4i_codec_pa_mute),
SND_SOC_DAPM_OUTPUT("HP Right"),
@@ -480,16 +481,16 @@ static const struct snd_soc_dapm_route
sun4i_codec_dapm_routes[] = {
{ "Left Mixer", NULL, "Mixer Enable" },
{ "Left Mixer", "Left DAC Playback Switch", "Left DAC" },
- /* Pre-Amplifier Mixer Routes */
- { "Pre-Amplifier", "Mixer Playback Switch", "Left Mixer" },
- { "Pre-Amplifier", "Mixer Playback Switch", "Right Mixer" },
- { "Pre-Amplifier", "DAC Playback Switch", "Left DAC" },
- { "Pre-Amplifier", "DAC Playback Switch", "Right DAC" },
+ /* Power Amplifier Routes */
+ { "Power Amplifier", "Mixer Playback Switch", "Left Mixer" },
+ { "Power Amplifier", "Mixer Playback Switch", "Right Mixer" },
+ { "Power Amplifier", "DAC Playback Switch", "Left DAC" },
+ { "Power Amplifier", "DAC Playback Switch", "Right DAC" },
- /* PA -> HP path */
- { "Pre-Amplifier Mute", "Switch", "Pre-Amplifier" },
- { "HP Right", NULL, "Pre-Amplifier Mute" },
- { "HP Left", NULL, "Pre-Amplifier Mute" },
+ /* Headphone Output Routes */
+ { "Power Amplifier Mute", "Switch", "Power Amplifier" },
+ { "HP Right", NULL, "Power Amplifier Mute" },
+ { "HP Left", NULL, "Power Amplifier Mute" },
};
static struct snd_soc_codec_driver sun4i_codec_codec = {
--
2.1.4
--
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] ASoC: sun4i-codec: use consistent names for PA controls
The power amplifier for the headphone output is called "the PA" and "the
headphone amplifier" in Allwinner's documentation for the A10 and A20.
sun4i-codec calls it "PA" in some places and "Pre-Amplifier" (which
isn't really accurate) in others, leading to user-visible controls with
different names referring to the same device.
When this driver implements audio input, it'll also need to expose
controls for the line and mic input preamps, so just referring to "the
Pre-Amplifier" will be ambiguous.
Change it to use "PA" consistently for the power amplifier.
Signed-off-by: Adam Sampson
---
sound/soc/sunxi/sun4i-codec.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index bcbf4da..ff3304d 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -2,6 +2,7 @@
* Copyright 2014 Emilio López
* Copyright 2014 Jon Smirl
* Copyright 2015 Maxime Ripard
+ * Copyright 2015 Adam Sampson
*
* Based on the Allwinner SDK driver, released under the GPL.
*
@@ -452,12 +453,12 @@ static const struct snd_soc_dapm_widget
sun4i_codec_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("Mixer Enable", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_MIXEN, 0, NULL, 0),
- /* Pre-Amplifier */
- SND_SOC_DAPM_MIXER("Pre-Amplifier", SUN4I_CODEC_ADC_ACTL,
+ /* Headphone output power amplifier */
+ SND_SOC_DAPM_MIXER("PA", SUN4I_CODEC_ADC_ACTL,
SUN4I_CODEC_ADC_ACTL_PA_EN, 0,
sun4i_codec_pa_mixer_controls,
ARRAY_SIZE(sun4i_codec_pa_mixer_controls)),
- SND_SOC_DAPM_SWITCH("Pre-Amplifier Mute", SND_SOC_NOPM, 0, 0,
+ SND_SOC_DAPM_SWITCH("PA Mute", SND_SOC_NOPM, 0, 0,
&sun4i_codec_pa_mute),
SND_SOC_DAPM_OUTPUT("HP Right"),
@@ -480,16 +481,16 @@ static const struct snd_soc_dapm_route
sun4i_codec_dapm_routes[] = {
{ "Left Mixer", NULL, "Mixer Enable" },
{ "Left Mixer", "Left DAC Playback Switch", "Left DAC" },
- /* Pre-Amplifier Mixer Routes */
- { "Pre-Amplifier", "Mixer Playback Switch", "Left Mixer" },
- { "Pre-Amplifier", "Mixer Playback Switch", "Right Mixer" },
- { "Pre-Amplifier", "DAC Playback Switch", "Left DAC" },
- { "Pre-Amplifier", "DAC Playback Switch", "Right DAC" },
+ /* PA Mixer Routes */
+ { "PA", "Mixer Playback Switch", "Left Mixer" },
+ { "PA", "Mixer Playback Switch", "Right Mixer" },
+ { "PA", "DAC Playback Switch", "Left DAC" },
+ { "PA", "DAC Playback Switch", "Right DAC" },
/* PA -> HP path */
- { "Pre-Amplifier Mute", "Switch", "Pre-Amplifier" },
- { "HP Right", NULL, "Pre-Amplifier Mute" },
- { "HP Left", NULL, "Pre-Amplifier Mute" },
+ { "PA Mute", "Switch", "PA" },
+ { "HP Right", NULL, "PA Mute" },
+ { "HP Left", NULL, "PA Mute" },
};
static struct snd_soc_codec_driver sun4i_codec_codec = {
--
2.1.4
--
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: [RFQ] Rules for accepting patches into the linux-releases tree
Greg KH <[EMAIL PROTECTED]> writes: > - It must fix a problem that causes a build error (but not for things >marked CONFIG_BROKEN), an oops, a hang, or a real security issue. So a trivial patch that fixed a data corruption issue wouldn't be accepted? -- Adam Sampson <[EMAIL PROTECTED]><http://offog.org/> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
Linus Torvalds <[EMAIL PROTECTED]> writes:
> So let's simply disallow versions, author information, and "good status"
> messages, ok?
I'd be quite happy with this, if only for consistency's sake -- at the
moment we've got some kernel subsystems which print "yup, I've started
up" messages, and some which don't; it's mildly annoying when you're
trying to track down a problem that's stopping the kernel from
starting up correctly, because there's no guarantee that the last
message had anything to do with what was actually happening.
Being a geekish sort of person, I'd prefer it if on my system I could
make everything print a line saying what it is and what hardware it
found; perhaps it could be a kernel argument ("messages=full"; the
messages option would control which log prefixes printk would actually
print to the screen, and module startup messages would use a
predefined prefix). Might be handy for debugging.
--
Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/>
-
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: [OT] Threads, inelegance, and Java
Rob Landley <[EMAIL PROTECTED]> writes: > > However, the very concept of Java encourages not caring about > > "performance, system-design or any elegance whatsoever". > The same arguments were made 30 years ago about writing the OS in a high > level language like C rather than in raw assembly. 30 years ago we didn't have C compilers that produce better code than you can write by hand. ;) -- Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac15
Walter Hofmann <[EMAIL PROTECTED]> writes: > It hung when I tried to close a browser window after reading the > text in it for quite some time. No swapping was going on. I've just seen this as well (for the first time) with -ac15. I was playing music with madplay at the time, and then did a "find . -type f -print0 | xargs -0 chmod 644" on a large directory tree on a reiserfs partition. A few seconds after I started the command, I got a hang which lasted a few seconds, then another, then another just after the find finished. It hasn't happened again since. All I got in the kernel log was: 2001-06-20 20:15:52.260230500 warning: Sound: DMA (output) timed out - IRQ/DRQ config error? 2001-06-20 20:16:07.472837500 warning: Sound: DMA (output) timed out - IRQ/DRQ config error? which makes sense, since the sound paused at the same time... Memory stats at the moment (i.e. about five minutes after it happened, with exactly the same stuff running): (azz:~) free total used free sharedbuffers cached Mem:288240 286652 1588196 30348 224860 -/+ buffers/cache: 31444 256796 Swap: 1048784 52176 996608 (azz:~) vmstat procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 52184 1588 30348 224876 0 25362 153 400 68 10 22 .config available on request. -- Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/> - 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: [kbuild-devel] CML2 1.1.3 is available
"Eric S. Raymond" <[EMAIL PROTECTED]> writes:
> If there were already a library in ths stock Python distribution to
> digest .Xdefaults files I might consider this. Perhaps I'll write
> one.
No, please don't! .Xdefaults files as loaded by xrdb can contain cpp
directives which can depend on the arguments given to xrdb ("xrdb
-DBIGTERM .Xdefaults", for instance), so you can't assume that what
you read from .Xdefaults is the user's setup, even if you emulate
cpp. You also shouldn't assume that the user's HOME is on the machine
where they loaded their resources from (suppose I start an X session
on my workstation, then ssh over to a server and run CML2; it would
then read server:~/.Xdefaults rather than workstation:~/.Xdefaults).
It's much more sensible to use the normal X mechanisms for reading
resources from the X server.
CML2 looks good---keep up the good work.
--
Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/>
-
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/
VM balancing problems under 2.4.2-ac1
Hiya. The VM balancing updates in the recent ac kernels seem to have caused some interesting performance problems on my desktop machine. I've got 160Mb of RAM, and 2.4.2-ac1 appears to be using excessively large amounts of it for buffers and cache while pushing stuff out to swap. This means that Mozilla, for instance, runs significantly worse than under 2.4.0, since bits of it are being swapped in and out. After the machine had been sitting for a while not doing very much: procs memoryswap io system cpu r b w swpd free buff cache si sobibo in cs us sy id 1 0 0 97184 2116 12844 111768 5 61511 154 791 29 4 67 After some heavy reiserfs disk IO (deleting lots of small files): procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 102620 1796 85836 43880 100 025 0 190 587 12 3 85 -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2
=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FBCON_VGA_PLANES=y CONFIG_FBCON_VGA=y CONFIG_FBCON_HGA=m CONFIG_FBCON_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_FONT_SUN8x16=y CONFIG_FONT_SUN12x22=y CONFIG_FONT_6x11=y CONFIG_FONT_PEARL_8x8=y CONFIG_FONT_ACORN_8x8=y CONFIG_SOUND=m CONFIG_SOUND_EMU10K1=m CONFIG_SOUND_MAESTRO=m CONFIG_SOUND_MAESTRO3=m CONFIG_SOUND_ICH=m CONFIG_SOUND_OSS=m CONFIG_SOUND_DMAP=y CONFIG_SOUND_AD1816=m CONFIG_SOUND_SGALAXY=m CONFIG_SOUND_ADLIB=m CONFIG_SOUND_VMIDI=m CONFIG_SOUND_MSS=m CONFIG_SOUND_MPU401=m CONFIG_SOUND_PSS=m CONFIG_SOUND_SB=m CONFIG_SOUND_TVMIXER=m CONFIG_USB=m CONFIG_USB_DEVICEFS=y CONFIG_USB_OHCI=m CONFIG_USB_AUDIO=m CONFIG_USB_BLUETOOTH=m CONFIG_USB_STORAGE=m CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_HID=m CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_WACOM=m CONFIG_USB_DC2XX=m CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m CONFIG_USB_IBMCAM=m CONFIG_USB_OV511=m CONFIG_USB_DSBR=m CONFIG_USB_DABUSB=m CONFIG_USB_PLUSB=m CONFIG_USB_PEGASUS=m CONFIG_USB_NET1080=m CONFIG_USB_USS720=m CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_RIO500=m CONFIG_MAGIC_SYSRQ=y Incidentally, have the VM rebalancing changes that are in -ac20 been merged? I'm sort of hoping they haven't, since they cause my machine to go heavily into swap even when there's plenty of real memory free. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Crash using DRI with 2.4.0 and 2.4.1
Miguel Rodriguez Perez <[EMAIL PROTECTED]> writes: > Hi, I have a Matrox G200 card installed on an Ali motherboard. > Sometimes when I use any opengl program my box crashes. It is more > likely that it will crash if I have used the xvideo extension or the > matroxfb, but this is not a must, it simply increases the chance of > a crash, which is very high anyway. > I have tried both 2.4.0 and 2.4.1 kernels with Xfree 4.0.2 both with > the same results. Are you sure you get the same results with 2.4.1? I'm in the exact same position (G200 on a Gigabyte GA5AX with ALi M1541/3). There was a patch to properly support AGP on these boards which went in between 2.4.0 and 2.4.1 which solved the problem for me (at least in 2.4.0; I haven't tested DRI throughly in 2.4.1 yet). -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
Linus Torvalds <[EMAIL PROTECTED]> writes: > > [...] the drm modules have unresolved symbols: > > Does this fix it for you (do a "make clean" before re-building your tree)? Yep, that works for a modular mga.o (although it also results in drmlib.a being installed into /lib/modules, which makes depmod whinge). Thanks! Are there any plans to include Ian Hastie's ALi M1541 agpgart patches in 2.4.0? They appear to do the job here... -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
Linus Torvalds <[EMAIL PROTECTED]> writes: > Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some > last-minute stuff that needed fixing (ie the dirty page lists etc), and > the best I can do is make a prerelease. It appears to work (even with the reiserfs patch with the obvious Makefile tweak), but the drm modules have unresolved symbols: root# modprobe mga /lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o: unresolved symbol remap_page_range /lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o: unresolved symbol __wake_up /lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o: unresolved symbol mtrr_add /lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o: unresolved symbol __generic_copy_from_user /lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o: unresolved symbol schedule [...] -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible patch for reiserfs-3.6.22 against 2.4.0-test12
Steven Cole <[EMAIL PROTECTED]> writes: > Your patch will probably let journal.c get compiled, but it might be > dangerous to use considering what Chris said. I've just tried it and got filesystem corruption, so no, it doesn't work. I'll wait for someone else to provide a patch that works. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Possible patch for reiserfs-3.6.22 against 2.4.0-test12
Hiya.
The latest reiserfs patch on ftp.namesys.com causes compilation errors
against test12 due to the task queue changes. Does this look correct?
--- fs/reiserfs/journal.c.orig Wed Dec 13 00:13:00 2000
+++ fs/reiserfs/journal.c Wed Dec 13 00:40:52 2000
@@ -1762,7 +1762,7 @@
ct->p_s_sb = p_s_sb ;
ct->jindex = jindex ;
ct->task_done = NULL ;
- ct->task.next = NULL ;
+ INIT_LIST_HEAD(&ct->task.list);
ct->task.sync = 0 ;
ct->task.routine = (void *)(void *)reiserfs_journal_commit_task_func ;
ct->self = ct ;
@@ -1813,7 +1813,7 @@
lock_kernel() ;
while(1) {
-while(reiserfs_commit_thread_tq) {
+while(TQ_ACTIVE(reiserfs_commit_thread_tq)) {
run_task_queue(&reiserfs_commit_thread_tq) ;
}
It does at least compile with these changes, but I haven't yet tested
it. Looking at run_task_queue, it would appear that the while() is now
redundant, but could someone who knows confirm/deny this?
--
Adam Sampson
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: corruption on my ext2fs with 2.4.0-test10
Mircea Damian writes:
> ... file-utils like ls, rm say:
> root@invasion:/usr/src/perl-5.6.0/t# ls -sail
> /bin/ls: big: Value too large for defined data type
> total 8
> 10973604 drwx-- 2 504 1001 4096 Dec 3 13:43 ./
> 13549794 drwxr-xr-x 3 504 1001 4096 Dec 3 13:43 ../
The file's got holes in it (regions of zeros), so it doesn't occupy as
much space on disk as it claims to. The reason your normal tools can't
deal with it is that your C library has been built without LFS
support, so stat will fail on files larger than 2 gig.
You can remove it by just calling unlink.
int main(int argc, char **argv) {
unlink("mybigfile");
}
--
Adam Sampson
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux?
On Sun, Nov 05, 2000 at 06:01:29PM -0700, Tim Riker wrote: > In short the impact of adding code to gcc that is not copyright FSF is > minimal. Only the FSF copyrighted code would be defensible by the FSF. Any > other code GPL violations would be the responsibility of the copyright > owners to defend. Just as a minor point: pro64 _does_ use GCC code. It's effectively the GCC frontend stuck together with the SGI backend, with a translation layer in the middle to translate between the intermediate code formats that the two compilers use. There are some fairly entertaining "this is a gruesome hack" comments in the source code. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote: > Too bad nobody on this list works at an electronics design company... ;-P Doesn't Transmeta count as an electronics design company? ;) -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problems with 2.4.0-test8
On Tue, Oct 03, 2000 at 01:54:55PM -0300, Rik van Riel wrote: > > It always happens the same although I can't repeat it on demand. > > Start a kernel compile and go read mail. Somewhere upon > > switching mail folders in netscape it locks. Box is _never_ > > under swap when this occurs. Wish it would at least log > > _something_ to report. > > That sounds suspiciously like something going to sleep > and not being woken up again ... I had an interesting one yesterday (when I was running test9-pre7 with the reiserfs and Riel VM patches)---I came back to my machine which was running X to find that it had apparently locked (display had frozen, mouse and keyboard had no effect). I then tried the normal last-ditch Alt-SysRq-s to get it to sync, and it burst back to life as if nothing had happened... No messages in the syslog (other than the emergency sync, of course). On the plus side, test9-pre9 + reiserfs seems to be working nicely. Good job, guys. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ReiserFS PATCH] fs/Makefile changes in pre8
Hiya all. The fs/Makefile changes in pre8 mean that the newest reiserfs patch won't cleanly apply any more (meaning that reiserfs doesn't get built). The following patch appears to fix it here---can someone check that it's correct, and if so can the reiserfs maintainers modify their patch accordingly? --- linux/fs/Makefile.orig Mon Oct 2 21:27:28 2000 +++ linux/fs/Makefile Mon Oct 2 21:28:41 2000 @@ -60,6 +60,7 @@ subdir-$(CONFIG_ADFS_FS) += adfs subdir-$(CONFIG_DEVPTS_FS) += devpts subdir-$(CONFIG_SUN_OPENPROMFS)+= openpromfs +subdir-$(CONFIG_REISERFS_FS) += reiserfs obj-$(CONFIG_BINFMT_AOUT) += binfmt_aout.o -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Sun, Oct 01, 2000 at 10:48:41PM -0400, Albert D. Cahalan wrote: > I see you don't remember the original post. It argued in > favor of a large PID space "because the output of ps wouldn't > look nice otherwise"!!! (the poster wanted output sorted by > start time without using --sort=start to ask for it) Why not use 32-bit PIDs in the kernel, but make the number at which they wrap a configurable option? That way, most users can keep the numbers small for ease of management, and people who really need 100,000 processes can have them. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, Sep 26, 2000 at 08:23:04PM +0100, Adam Sampson wrote: > However, I'm probably not a useful datapoint, as I'm running 2.4.0-test8 + > reiserfs-3.9.16 + 2.4.0-t8-sched + 2.4.0-t8-vmpatch4. Just happened again with test9-pre7; looked like it was caused by gcc eating lots of memory and going into swap. -- Adam Sampson [EMAIL PROTECTED], [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre7
On Tue, Sep 26, 2000 at 03:29:40PM +0200, Helge Hafting wrote: > Unfortunately it still dies occationally. sysrq-Boot is the only thing > that work, > I have no more data as it happened in X and console switching didn't > work. > > Exactly the same behavior as VM crashes in test9-pre5 and earlier. > This is a UP machine with an ide drive, 128M ram and 96M swap. > The (memory) load was light when it crashed during a disk write, > although there were perhaps 20k in swap from some mozilla use > earlier. Exactly the same here. I've seen the same crash three times today (not having suffered from mysterious crashes here): - I do something (typically starting a program; the one I've just seen started this behaviour just as icecast started its extra threads) - The hard disk starts grinding (as if I were going deeply into swap), and my X session freezes - Hitting alt-sysrq-u might work if I'm lucky, but normally only alt-sysrq-b is available However, I'm probably not a useful datapoint, as I'm running 2.4.0-test8 + reiserfs-3.9.16 + 2.4.0-t8-sched + 2.4.0-t8-vmpatch4. The machine's a K6-2 450MHz with 160Mb of RAM, a few IDE disks and an NE2000 card, running XFree86 v4.0.1. Previous 2.4.0-test kernels have been rock solid for me, which is probably a good sign. -- Adam Sampson [EMAIL PROTECTED], [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
On Wed, Sep 13, 2000 at 03:08:27PM -0400, Horst von Brand wrote: > "Jeff V. Merkey" <[EMAIL PROTECTED]> said: > > [...] > > > I have concluded that Linux will only progress as fast as Linus does. > > Linux has forked twice now, and the new variants are not named "Linux" > > anymore, so these types of changes may occur more quickly since there > > will be independent paths. > > That is news to me. What are those "other Linuxes", and where do I find them? uCLinux (http://www.uclinux.org/) and Linux86 (u)? Or 2.0 and 2.2? -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple Keyboards in 2.2/2.4?
On Fri, Sep 08, 2000 at 08:17:29PM -0400, James Simmons wrote: > > > On the console level their are complex issues as well. Consider a > > > system with 4 VTs attached to one machine. What if one person pressed > > > Ctrl-Alt-Del. Anyone can bring the system down when multiple people depend > > > on it. > > > > That particular one is a userspace issue; you can simply tell init not to do > > anything when Ctrl-Alt-Del is pressed. (You'd also want to disable > > magic-sysrq for the same reason.) > > Don't forget about where printk goes to. Should it goe to every VT or just > one? IMHO, it shouldn't go to any consoles; it should go to syslog, which can then be distributed in userspace. > As for SysRq do users want the option to disable for everyone, have > it work for one VT or allow it for everyone? Do we want a all or nothing > policy? Eventually? It would be nice to have it only available on some consoles, as you say, but for now it's safe to just disable it everywhere. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple Keyboards in 2.2/2.4?
On Thu, Sep 07, 2000 at 10:00:05AM -0400, James Simmons wrote: > On the console level their are complex issues as well. Consider a > system with 4 VTs attached to one machine. What if one person pressed > Ctrl-Alt-Del. Anyone can bring the system down when multiple people depend > on it. That particular one is a userspace issue; you can simply tell init not to do anything when Ctrl-Alt-Del is pressed. (You'd also want to disable magic-sysrq for the same reason.) -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Thu, Sep 07, 2000 at 10:46:58AM +0200, Martin Dalecki wrote: > > I've done an implementation of some of the Win32 "system calls" in a kernel > > module in an attempt to speed up Wine. > > Please by no way don't include this patch into the official tree. > It's insane due to the following: > > 1. Linux is UNIX not NT... (in terms of API) I also don't think this patch should go into the official tree, but in my case it's because it's too closely related to the WINE userspace libraries; it should become part of the WINE tree instead. (Note that this is how other packages such as ALSA and lm_sensors are maintained.) However, I don't see any problems with having a kernel module to emulate a different API. We already have code to emulate different UNIX APIs in the IBCS system; having some support for emulating the Win32 system call interface could potentially be useful. > 2. WINE in itself is barely usefull - even in fact non existant, since > there is no official stable release out there. Flamebait, but I don't think this is true. WINE is very useful---plenty of apps and games run on it, and it can be a real lifesaver if you get thrown a self-extracting archive that unzip chokes on. (Note that Corel are using WINE for Wordperfect Office under Unix now.) WINE's still-ALPHA status reflects the caution of its developers rather than the quality of its code; note that plenty of other packages (lesstif, kbd, WindowMaker, ORBit, ALSA, bin86, esd, links etc.) still retain "alpha" (<1.0) version numbers despite being stable, reliable and widely-used. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
