ANSI C vs ISO C++

Q:
int x = 0;
int y = 0;
(1 ? x : y) = 4;


A:
This is not legal in ANSI C:
6.5.15/4

If an attempt is made to modify the result of a conditional operator
or to access it after the next sequence point, the behavior is undefined.

However, in C++ we have:
5.16/4

If the second and third operands are lvalues and have the same type,
the result is of that type and is an lvalue.

5.16/5

Otherwise, the result is an rvalue.

via linkedin.com, cpptrivia.blogspot.com

Google reader

Hello,
Just like you do, I have lots of subscriptions in google reader. Not a big deal. The thing
that freaks me out is that google have that brain damaged option:
- sort subscriptions list.

I mean, google offers you reading trends, subscription trends, how many times you
clicked and so on. The question arising is - why not sort subscriptions by demand
according to those stats? E.g. sort by "Items/Day", or by "% Read", "# Read".

And no, "sort alphabetically" or "sort by drug-and-drop" ain't a solution. Really.

Am I missing something?

acer aspire bios update

europe.pool.ntp.org (ntpdate executed nearly every second)

BIOS 1.13
adjust time server 80.96.120.252 offset 0.104322 sec
adjust time server 80.96.120.252 offset 0.099397 sec
adjust time server 80.96.120.252 offset 0.096243 sec
adjust time server 80.96.120.252 offset 0.091021 sec
adjust time server 80.96.120.252 offset 0.087349 sec
adjust time server 80.96.120.252 offset 0.087027 sec
adjust time server 80.96.120.252 offset 0.085541 sec
adjust time server 80.96.120.252 offset 0.082374 sec

BIOS 1.06
adjust time server 88.191.117.61 offset 0.002307 sec
adjust time server 88.191.117.61 offset 0.003218 sec
adjust time server 88.191.117.61 offset 0.003611 sec
adjust time server 88.191.117.61 offset 0.004132 sec
adjust time server 88.191.117.61 offset 0.004492 sec
adjust time server 88.191.117.61 offset 0.004967 sec
adjust time server 88.191.117.61 offset 0.005108 sec
adjust time server 88.191.117.61 offset 0.005881 sec
adjust time server 88.191.117.61 offset 0.006293 sec
adjust time server 88.191.117.61 offset 0.006553 sec
adjust time server 88.191.117.61 offset 0.007018 sec
adjust time server 88.191.117.61 offset 0.007411 sec
adjust time server 88.191.117.61 offset 0.007894 sec
adjust time server 88.191.117.61 offset 0.008193 sec
adjust time server 88.191.117.61 offset 0.008534 sec
adjust time server 88.191.117.61 offset 0.008972 sec
adjust time server 88.191.117.61 offset 0.008819 sec
adjust time server 88.191.117.61 offset 0.009721 sec
adjust time server 88.191.117.61 offset 0.010161 sec
adjust time server 88.191.117.61 offset 0.012594 sec
...To Infinity and Beyond!... CANCELLED

touch_(nmi|softlockup)_watchdog

Hello,

It is a mistake to think you can solve any major problems just with potatoes.
Douglas Adams

[   67.703556] BUG: using smp_processor_id() in preemptible [00000000] code
[   67.703563] caller is touch_nmi_watchdog+0x15/0x2c
[   67.703568] Call Trace:
[   67.703575]  [<ffffffff811f6bf1>] debug_smp_processor_id+0xc9/0xe4
[   67.703578]  [<ffffffff81092766>] touch_nmi_watchdog+0x15/0x2c
[   67.703584]  [<ffffffff81222950>] acpi_os_stall+0x34/0x40
[   67.703589]  [<ffffffff812398d2>] acpi_ex_system_do_stall+0x34/0x38
[   67.703591]  [<ffffffff81238396>] acpi_ex_opcode_1A_0T_0R+0x6d/0xa1
[   67.703595]  [<ffffffff8122e280>] acpi_ds_exec_end_op+0xf8/0x578
[   67.703598]  [<ffffffff812457f9>] acpi_ps_parse_loop+0x88a/0xa55
[   67.703604]  [<ffffffff81244a00>] acpi_ps_parse_aml+0x104/0x3c4
[   67.703607]  [<ffffffff81246198>] acpi_ps_execute_method+0x20f/0x2f3
[   67.703610]  [<ffffffff8124021f>] acpi_ns_evaluate+0x18b/0x2d2
[   67.703614]  [<ffffffff8123fad0>] acpi_evaluate_object+0x1b8/0x2fc
[   67.703617]  [<ffffffff8123e020>] ? acpi_get_sleep_type_data+0x21c/0x236
[   67.703620]  [<ffffffff8123d9fb>] acpi_enter_sleep_state_prep+0x61/0xd9
[   67.703623]  [<ffffffff81224205>] acpi_sleep_prepare+0x4f/0x56
[   67.703626]  [<ffffffff81224268>] __acpi_pm_prepare+0x13/0x2e
[   67.703629]  [<ffffffff81224448>] acpi_pm_prepare+0xe/0x1f
[   67.703632]  [<ffffffff81224466>] acpi_hibernation_pre_snapshot+0xd/0x1e
[   67.703637]  [<ffffffff81071b80>] hibernation_snapshot+0xaf/0x258
[   67.703641]  [<ffffffff81074dca>] snapshot_ioctl+0x25c/0x547
[   67.703645]  [<ffffffff81056efc>] ? __srcu_read_unlock+0x3b/0x57
[   67.703649]  [<ffffffff810e7f7d>] vfs_ioctl+0x31/0xa2
[   67.703652]  [<ffffffff810e88dc>] do_vfs_ioctl+0x47c/0x4af
[   67.703655]  [<ffffffff8125ee3c>] ? n_tty_write+0x0/0x35e
[   67.703659]  [<ffffffff8100203a>] ? sysret_check+0x2e/0x69
[   67.703662]  [<ffffffff810e8960>] sys_ioctl+0x51/0x75
[   67.703665]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
[...]
[   67.703668] BUG: using smp_processor_id() in preemptible [00000000] code
[   67.703670] caller is touch_softlockup_watchdog+0x15/0x2b
[   67.703674] Call Trace:
[   67.703677]  [<ffffffff811f6bf1>] debug_smp_processor_id+0xc9/0xe4
[   67.703680]  [<ffffffff8109273b>] touch_softlockup_watchdog+0x15/0x2b
[   67.703682]  [<ffffffff81092779>] touch_nmi_watchdog+0x28/0x2c
[...]


Sometimes things are way much complicated than you may think at first.
The solution is pretty obvious... and pretty wrong at the same time.

Frederic Weisbe wrote:

[..]
It is buggy by nature.
[..]
The problem is on the caller. Considering such udelays loop:

* if it's in a irq disabled section, call touch_nmi_watchdog(), because this
  could prevent the nmi watchdog irq from firing
* if it's in a non-preemptable section, call touch_softlockup_watchdog(), because
  this could prevent the softlockup watchdog task from beeing scheduled
* if it's from a preemptable task context, this should call cond_resched() to
  avoid huge latencies on !CONFIG_PREEMPT

But acpi_os_stall() seem to be called from 4 different places, and these places
may run in different context like the above described.

It means that get_cpu()/put_cpu() are just masking the problem, despite the fact that what we actually need is to fix the problem. And it wasn't obvious to me (little, silly me).

So, we have git reset to previous code in touch_(nmi|softlockup)_watchdog.

thermal_throttle_add_dev

Hello,

[13874.228704] BUG: using smp_processor_id() in preemptible [00000000] code: bash/10661
[13874.228715] caller is thermal_throttle_add_dev+0x20/0xa4
[13874.228721] Pid: 10661, comm: bash Not tainted 2.6.36-rc0-git11-07631-gfa34556-dirty #109
[13874.228725] Call Trace:
[13874.228738]  [<ffffffff811f6285>] debug_smp_processor_id+0xc9/0xe4
[13874.228744]  [<ffffffff8136ccac>] thermal_throttle_add_dev+0x20/0xa4
[13874.228750]  [<ffffffff8136cd82>] thermal_throttle_cpu_callback+0x52/0xb5
[13874.228759]  [<ffffffff81057198>] notifier_call_chain+0x32/0x5e
[13874.228767]  [<ffffffff8103c818>] ? cpu_maps_update_begin+0x12/0x14
[13874.228774]  [<ffffffff810571e3>] __raw_notifier_call_chain+0x9/0xb
[13874.228780]  [<ffffffff8103c6db>] __cpu_notify+0x1b/0x2d
[13874.228786]  [<ffffffff8136eeb2>] _cpu_up+0x6b/0xe9
[13874.228792]  [<ffffffff8136ef7a>] cpu_up+0x4a/0x57
[13874.228799]  [<ffffffff813638b7>] store_online+0x41/0x6e
[13874.228807]  [<ffffffff8129186b>] sysdev_store+0x1b/0x1d
[13874.228816]  [<ffffffff8113188e>] sysfs_write_file+0x103/0x13f
[13874.228824]  [<ffffffff810da5ff>] vfs_write+0xb1/0x14e
[13874.228830]  [<ffffffff810da898>] sys_write+0x45/0x6c
[13874.228840]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b

My first solution was quite simple - just don't use preemptible smp_processor_id().
In other words it was something like that:

--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -205,7 +205,9 @@ static int therm_throt_process(bool new_event, int event, int level)
 static __cpuinit int thermal_throttle_add_dev(struct sys_device *sys_dev)
 {
     int err;
-    struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
+    int cpu = get_cpu();
+    struct cpuinfo_x86 *c = &cpu_data(cpu);
+    put_cpu();

     err = sysfs_create_group(&sys_dev->kobj, &thermal_attr_group);
     if (err)

However, we know the exact cpu when we are about to call thermal_throttle_add_dev.
So smp_processor_id()/get_cpu() - put_cpu() is sort of redundant here. Here we are
with the second solution:

--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -202,11 +202,12 @@ static int therm_throt_process(bool new_event, int event, int level)

 #ifdef CONFIG_SYSFS
 /* Add/Remove thermal_throttle interface for CPU device: */
-static __cpuinit int thermal_throttle_add_dev(struct sys_device *sys_dev)
+static __cpuinit int thermal_throttle_add_dev(struct sys_device *sys_dev,
+                unsigned int cpu)
 {
     int err;
-    struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
-
+    struct cpuinfo_x86 *c = &cpu_data(cpu);
+   
     err = sysfs_create_group(&sys_dev->kobj, &thermal_attr_group);
     if (err)
         return err;
@@ -251,7 +252,7 @@ thermal_throttle_cpu_callback(struct notifier_block *nfb,
     case CPU_UP_PREPARE:
     case CPU_UP_PREPARE_FROZEN:
         mutex_lock(&therm_cpu_lock);
-        err = thermal_throttle_add_dev(sys_dev);
+        err = thermal_throttle_add_dev(sys_dev, cpu);
         mutex_unlock(&therm_cpu_lock);
         WARN_ON(err);
         break;
@@ -287,7 +288,7 @@ static __init int thermal_throttle_init_device(void)
 #endif
     /* connect live CPUs to sysfs */
     for_each_online_cpu(cpu) {
-        err = thermal_throttle_add_dev(get_cpu_sysdev(cpu));
+        err = thermal_throttle_add_dev(get_cpu_sysdev(cpu), cpu);
         WARN_ON(err);
     }
 #ifdef CONFIG_HOTPLUG_CPU


Good news everyone:

Subject: [tip:x86/urgent] x86, hwmon ...
Commit-ID:  51e3c1b558b31b11bf5fc66d3c6f5adacf3573f7

Thanks.


P.S. by the way:
LKML-Reference: <20100820073634.GB5209@swordfish.minsk.epam.com>

I'll ask epam for bonus... $10,000... cash. If you know what I mean. Yeah!

Michael Jordan VS Bill Gates

via  this blog rules

click

reiserfs evict inode

Hi,

2.6.36-rc0-git11-07128-g4104046-dirty

[ 2213.717957] ------------[ cut here ]------------
[ 2213.719401] kernel BUG at fs/inode.c:298!
[ 2213.720821] invalid opcode: 0000 [#7] PREEMPT SMP
[ 2213.722248] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:13/PNP0C0A:00/power_supply/BAT0/status
[ 2213.723692] CPU 0
[ 2213.729816]
[..]
[ 2213.753445] Stack:
[ 2213.754980]  ffff880135abfde8 ffff880117474610 ffff880135abfe58 ffffffff8113a1f8
[ 2213.755021] <0> ffff880155543800 0000000000000000 0000000000000000 0000000000000000
[ 2213.756590] <0> 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[ 2213.759677] Call Trace:
[ 2213.761205]  [<ffffffff8113a1f8>] reiserfs_evict_inode+0x13c/0x151
[ 2213.762736]  [<ffffffff810ebcac>] evict+0x22/0x92
[ 2213.764248]  [<ffffffff810ec884>] iput+0x1c8/0x228
[ 2213.765746]  [<ffffffff810e3ca1>] do_unlinkat+0x107/0x15a
[ 2213.767393]  [<ffffffff810e1654>] ? path_put+0x2c/0x30
[ 2213.768909]  [<ffffffff8136d760>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 2213.770368]  [<ffffffff810e5004>] sys_unlink+0x11/0x13
[ 2213.771806]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
[ 2213.773246] Code: 02 00 00 00 74 02 0f 0b 48 8d 87 e0 02 00 00 48 39 87 e0 02 00 00 74 02 0f 0b 48 8b 87 30 03 00 00 a8 20 75 02 0f 0b a8 40 74 02 <0f> 0b a8 80 74 1d 48 8d bf 30 03 00 00 b9 02 00 00 00 48 c7 c2
[ 2213.776684] RIP  [<ffffffff810ebc58>] end_writeback+0x3b/0x6d
[ 2213.778296]  RSP <ffff880135abfdd8>
[ 2213.798230] ---[ end trace 4b833f744d46ce1f ]---


The problem is that:
reiserfs_evict_inode calls end_writeback two times hitting
kernel BUG at fs/inode.c:298 because inode->i_state is I_CLEAR already.

---

diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
index ae35413..87e11d2 100644
--- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -83,7 +83,8 @@ void reiserfs_evict_inode(struct inode *inode)
        dquot_drop(inode);
        inode->i_blocks = 0;
        reiserfs_write_unlock_once(inode->i_sb, depth);
-
+       return;
+
 no_delete:
        end_writeback(inode);
        dquot_drop(inode);


Al Viro wrote:
Applied, thanks.

scheduling while atomic

At first I was like
uname -a
Linux 2.6.36-rc0-git9-06241-g2ba110e-dirty

but then I was like
[    0.010045] BUG: scheduling while atomic: swapper/0/0x10000002
[    0.010140] no locks held by swapper/0.
[    0.010219] Modules linked in:
[    0.010356] Pid: 0, comm: swapper Not tainted 2.6.36-rc0-git9-06241-g2ba110e-dirty #99
[    0.010455] Call Trace:
[    0.010535]  [] __schedule_bug+0x72/0x77
[    0.010622]  [] schedule+0xdc/0x8f2
[    0.010707]  [] __cond_resched+0x13/0x1f
[    0.010792]  [] _cond_resched+0x29/0x30
[    0.010878]  [] acpi_ps_complete_op+0x2c6/0x2db
[    0.010965]  [] ? acpi_ds_load1_end_op+0x51/0x249
[    0.011052]  [] acpi_ps_parse_loop+0x8b8/0xa55
[    0.011139]  [] ? trace_hardirqs_on+0xd/0xf
[    0.011224]  [] acpi_ps_parse_aml+0x104/0x3c4
[    0.011310]  [] acpi_ns_one_complete_parse+0x125/0x142
[    0.011399]  [] ? acpi_os_signal_semaphore+0x5f/0x6f
[    0.011482]  [] acpi_ns_parse_table+0x49/0x8e
[    0.011567]  [] acpi_ns_load_table+0x78/0x114
[    0.011652]  [] acpi_load_tables+0xa1/0x18e
[    0.011736]  [] acpi_early_init+0x6c/0xf7
[    0.011821]  [] start_kernel+0x3fd/0x40d
[    0.011905]  [] x86_64_start_reservations+0xb1/0xb5
[    0.011990]  [] x86_64_start_kernel+0xf8/0x107


UPD:

 #define ACPI_PREEMPTION_POINT() \
  do { \
-  if (!in_atomic_preempt_off() && !irqs_disabled()) \
+  if (!irqs_disabled()) \
    cond_resched(); \
  } while (0)
+#endif