On 9/10/18, Levente Polyak via arch-general <arch-general@xxxxxxxxxxxxx> wrote: > On 9/10/18 1:43 PM, Carsten Mattner wrote: >> On 9/10/18, Levente Polyak via arch-general <arch-general@xxxxxxxxxxxxx> >> wrote: >>> Just a crazy idea but how about contributing back instead of just >>> complaining? People on the bug tracker always help guiding how to report >>> upstream or finding relevant commits. Yeah, i know it takes a while to >>> compile, but it's not that complicated: >>> - take a look at the panic in hardened >>> - peek the code around it to find out which of the protective config >>> values may have triggered it (if not already obvious from the panic) >>> - reproduce on stock/vanilla kernel by building it including the >>> responsible configs >>> - report upstream using the gathered information of the vanilla kernel >>> - bonus points for git bisecting the commit that broke it >>> >>> This would not only contribute to make hardened run on your or similar >>> setups, all vanilla linux users would benefit by helping to fix a bug >>> that can or does result in a corruption. >> >> I did and do. I have open bugs in freedesktop and kernel bugzilla which >> are not resolved and in NEW state for months and years. These are usually >> regressions in drivers due to the Linux driver packaging model and >> insufficient testing on supported hardware configurations. What happens >> is that a driver that works flawlessly on hardware rev-1.8 suddenly >> starts >> misbehaving with a newer kernel that has seen improvements, refactorings, >> and support for newer hardware. It's most prominent in the graphics >> stack, >> which is complex, hard to test, and easy to break. I don't blame the >> developers for having a hard time, I'm discouraged stable drivers for >> old hardware get regressions and stop being tested as well as hardware >> of years -2/+2 years. >> >> Therefore, I hope you don't mind if my frustration level with the issues >> I'm tracking right now is high enough that I'm not in the mood to debug >> and track issues I can avoid by using a different stable kernel branch. >> > > Nice to hear that you do or at least did, bear with me for > overgeneralizing in in your case. I'm glad my response didn't result in an unfriendly counter, I was a little anxious what your reply will be :). > However, the point of my whole response was that you are most > definitively triggering/encountering the very same bug on the stock > kernel, stock variant just tries to go ahead instead of panic, which > means it may result in corruption and possibly killing kittens. Whatever > is encountered there is at least a "regular regression" and possibly > could provide surface for exploitation. > > If you are not using linux-lts you are pretty much using the very same > stable branch/tag in linux-hardened that vanilla linux uses so there is > no "different stable kernel branch". If former is the case you can > pretty much blame vanilla linux package to an equal amount as the > hardened variant for being buggy. Maybe someday I can use 4.19, after switching to AMD or AMD+nVidia.... On my primary machine I use LTS 4.4. It also has the graphics regressions introduced with 4.2 and later for Intel GPUs, but it's not as bad as later LTS branches. If I need to stress the GPU, I need to sidestep to LTS 3.16 because there's no other LTS release after LTS 4.1 was EOL'd. GPU hangs and ring timeouts are most frequent issues, in addition to other bugs. Somewhere in the last 3 or 4 years, something happened in Intel's GPU team, and they introduced enough regressions that I started wondering how I never thought about Intel GPU drivers before 4.2, when stuff just worked if the GPU was documented to be supported. I don't want to bore you with GPU driver complaints, it's not your responsibility. Planning to use newer Ryan APUs for iGPU case and dedicated GPU, ignoring Intel completely, in desktop machines, when I upgrade hardware.
