Re: Is the new list working already?
On Mon, Dec 20, 2010 at 2:48 AM, loody wrote: > hi all: > > 2010/12/20 Paul Fisher : > > Testing new list... > > > > On Mon, Dec 20, 2010 at 1:02 AM, Anuz Pratap Singh Tomar > > wrote: > >> Hi all, > >> Sending this mail to check if the new list is operating properly. > >> > >> Regards > >> Anuz > >> > >> ___ > >> Kernelnewbies mailing list > >> Kernelnewbies@kernelnewbies.org > >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >> > >> > > > so we change from "Kernel Newbies" , to > kernelnewb...@kernelnewbies.org? > when will be the old mailing list abandon? > appreciate your help, > miloody > > I recall a recent "welcome to kernelnewbies list" I surmise (now) that the old list was fed into an auto-subscribe script ? > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Ad-hoc arm board
On Tue, Feb 8, 2011 at 5:47 AM, Andrea Gasparini wrote: > Hi, > Working on a custom arm based board, I'm currently juggling with mach-types > and machine IDs for our ARM boards, but perhaps it came the time to set > them in the right way... > > And moreover, do anyone has a pointer on documentation/articles/somewhat > on how to write a good board-*.c and how (and perhaps when) to handle > platform devices instead of a classical device driver? I'm currently going > by trying, and perhaps it's not the better method to achieve my purposes. > > theres also a lot of work going on currently in device-trees, which are splitting config data out from code, into text files. googling "linux device tree" found a lot of relevant stuff, there was also a recent LWN.net article on them. Looking at linux-next tree is also useful, there are a bunch of configs for a bunch of arm boards in there. good luck ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
getconf CLK_TCK and CONFIG_HZ
Im trying to do a little benchmarking of perl, and have patched its distro files to run perl's times() function on each of the ~1900 test files. perl's times() uses man 2 times internally, which I presume reduces to a system-call The standard distro can be run as: HARNESS_TIMER=1 make test but this counts only wall-clock time, and is thus sensitive to system load. times does better, Anyway, the 1st thing I noticed on the times numbers was that they all have 10ms granularity. This agrees with sysconf granularity : $ getconf CLK_TCK 100 but not with linux kernel HZ: $ grep _HZ /boot/config-`uname -r` CONFIG_RCU_FAST_NO_HZ=y CONFIG_NO_HZ=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 Confusingly, man 2 times says : NOTES The number of clock ticks per second can be obtained using: sysconf(_SC_CLK_TCK); In POSIX.1-1996 the symbol CLK_TCK (defined in ) is mentioned as obsolescent. It is obsolete now. but linux (fedora 13) seems to disagree : $ getconf _SC_CLK_TCK getconf: Unrecognized variable `_SC_CLK_TCK' So, the Questions: Why arent they the same ? or what am I missing wrt the relationship between sysconf(CLK_TCK) and kernel HZ ? Is it possible to coax the kernel into counting times in 1ms via some cmd-line option ? I searched Documentation/kernel-parameters.txt, found nothing. is it possible to compile kernel with different HZ options to get the 1ms resolution ? Why doesnt times() also count IO-wait states for a process (and children) ? I note that top reports it (as a system-wide measure) and System Monitor 2.30.0 displays it (same system-wide measure) hypothetically, if IO-wait numbers were collected by times (API/ABI change, so never gonna happen) would it be able to reveal anything ? Id expect it to show measure disk activity due to the process, and arguably be sensitive to system load, unlike user, sys, child-user, child-sys numbers but it still sounds useful. Could process specific IO-wait numbers reveal anything about cache performance ? Do cache misses contribute to IO-wait, or do they get counted in other ways ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: where is __memory_barrier in kernel ?
On Thu, Mar 10, 2011 at 8:13 AM, loody wrote: > hi > > 2011/3/8 piyush moghe : > > Yes what you are saying is also right, since in order to prevent the > > ordering all the pending memory operations should have completed > > hence as you mentioned processor stops and make sure all the memory > > operations are completed. > I am not sure whether all the memory operations are completed after > cpu stops running for a while. > I think there should be a more aggressive and precise instruction to > handle this behavior, right? > appreciate your kind help, > miloody a consolidated view of locking primitives is in linux-2.6.git/tools/perf/perf.h it defines rmb(), cpu_relax() for many architectures in a single place. the comment block here: http://lxr.free-electrons.com/source/arch/x86/include/asm/system.h#L357 lines 371-421, say that rmb is heavier than memory_barrier() or barrier(). I think the comment speaks to your "aggressive and precise" questions. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: getconf CLK_TCK and CONFIG_HZ
On Sun, Mar 13, 2011 at 1:20 AM, Mulyadi Santosa wrote: > Dear Jim... > > Allow me to help you by sharing what I know so far thanks Mulyadi >> This agrees with sysconf granularity : >> $ getconf CLK_TCK >> 100 >> but not with linux kernel HZ: >> $ grep _HZ /boot/config-`uname -r` >> CONFIG_HZ_1000=y >> CONFIG_HZ=1000 > > Not a surprise. I read somewhere that Linux ABI so far declares that > time clock granularity is always shown as 100 HZ or 10 ms. So it is > more due to "following the rule" and application in user space follow > this assumption, even though we know that most distros now shift into > 250 or 1000 HZ I cant help but be annoyed that my distro kernel is already built with HZ_1000, but im stuck with 10ms resolution. I did note that theres no setconf to go along with getconf. I note however that CLOCKS_PER_SEC seems to be what youre referring to as the fixed number. That its 10k faster than 10ms is probably unimportant, its a fixed ratio, and ripe for hard-coding :-( clock ticks - _SC_CLK_TCK The number of clock ticks per second. The corresponding vari‐ able is obsolete. It was of course called CLK_TCK. (Note: the macro CLOCKS_PER_SEC does not give information: it must equal 100.) Its also frustrating to read about the obsolete variable, and not know why it was obsoleted. Having getconf is a 1st step I suppose; its possible in theory to call sysconf(_SC_CLK_TCK) and then adjust your notion of how long 1 clock_t is, perhaps in the next decade this will happen in all apps, and then this ABI constraint can be relaxed. I presume the reason for HZ_1000 is RT-ish responsiveness ? that and the ever increasing clock rates, more is done in 1ms now than used to take 10ms :-) >> Why doesnt times() also count IO-wait states for a process (and children) ? > just to clarify, I meant count it separately - it may be aggregated in there. But I guess you read into that... > AFAIK, if you look closely into timing accounting and the way I/O code > path behaves, you shall see that most of the times I/O is done in > async style...and more over, you can't tell for sure that is it only > single I/O code path that runs or more than one that are currently > running (by either interleaving between them or executing them > simultaneously). > > That's why IMO, it's quite hard (but still possible) to account for > per process I/O wait...but still quite easy to do it system widely. > system calls are executed in kernel, but have process context, right ? meaning theres a PID to assign the costs to. I can understand that at some depth, the async nature means that those costs are no longer trackable to a pid, perhaps forex the block-layer work to service a file read... Does 1000_HZ mean that user jobs are scheduled out on 1ms boundaries ? They obviously can be scheduled out earlier if they hit a sleep / IOwait, and interrupts push user space (and other kernel tasks too) out. >> Could process specific IO-wait numbers reveal anything about cache >> performance ? > > I personally think,the main perfomance indicator of cache perfomance > is cache hit utilization. yeah, that makes sense. With the new perf tools, there are powerful ways to look at those numbers. > >> Do cache misses contribute to IO-wait, or do they get counted in other ways >> ? > > we're talking about page cache, right? > > then sure, cache misses would trigger hard/major page fault, assuming > it is file backed page. I wasnt really making the distinction - 3 kinds: 1 major page fault - page refetched from HD, 10s of ms wait, process sleeps, and gets scheduled out. fault is counted by hardware, and is available for measurement by perf, and accountable to process, but not counted by default. 2 minor page fault - page is in mem (perhaps shared) its added to faulting process' address space, page tables. How long does this typically take ? Does it result in a reschedule, context switch ? 3 L1..L3 cache miss. IIRC, this adds 10-20x cycles for each level out from registers. probably far less than context switch. kernel could perhaps switch to another thread in same process. does it ? Ive noticed how effective git pull is at pegging the cpu. Ive often wondered why its so good at it - whether it can be attributed to anything in particular. Like less cache-misses, or maybe less system-calls, and therefore more productive cpu cycles. I guess I should look at System Monitor 2.32.0 code, see how it measures and graphs these different things. It seems to provide info that times() does not. Maybe I'll run "perf stat -- git pull" next time, of course thats not entirely repeatable/comparable to anyone elses run. > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > thanks again, Jim ___ Kernelne
is git.kernel.org the best place for stable releases ?
OpenWrt is apparently using a stable release that isnt on kernel.org Bartman007 wrote: 23 November 2010 The OpenWrt Release Team would like to announce a fourth release candidate (RC4) for Backfire Interim Release 1 (10.03.1). Testing of this release candidate will allow further refinement of 10.03.1 * 2.6.32 targets updated from 2.6.32.16 to 2.6.32.25 OpenWrt 10.03 is running 2.6.32.10, which is still ahead of kernel.org http://git.kernel.org/?p=linux/kernel/git/smb/smb-2.6.32.y.git;a=commit;h=7f5e918e62cbc9ac27c2f47d3c3dd4b86f67ff0e 2010-02-23 Greg Kroah... Linux 2.6.32.9 master origin/HEAD origin/master v2.6.32.9 stefan.ba...@canonical.com is the branch/tree owner, ccd, FYI to kernelnewbies. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is git.kernel.org the best place for stable releases ?
ahh thanks. I searched, and stopped at the 1st hit. heres the correct one. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=summary linux/kernel/git/stable/linux-2.6.32.y.git 2.6.32-stable tree Greg Kroah-Hartman 2 months agosummary | shortlog | log | tree | git On Wed, Mar 16, 2011 at 1:53 PM, Greg KH wrote: > On Wed, Mar 16, 2011 at 01:47:28PM -0600, Jim Cromie wrote: >> OpenWrt is apparently using a stable release that isnt on kernel.org >> >> Bartman007 wrote: >> >> 23 November 2010 >> >> The OpenWrt Release Team would like to announce a fourth release >> candidate (RC4) for Backfire Interim Release 1 (10.03.1). Testing of >> this release candidate will allow further refinement of 10.03.1 >> >> * 2.6.32 targets updated from 2.6.32.16 to 2.6.32.25 >> >> >> OpenWrt 10.03 is running 2.6.32.10, which is still ahead of kernel.org >> >> >> http://git.kernel.org/?p=linux/kernel/git/smb/smb-2.6.32.y.git;a=commit;h=7f5e918e62cbc9ac27c2f47d3c3dd4b86f67ff0e >> >> 2010-02-23 Greg Kroah... Linux 2.6.32.9 master origin/HEAD >> origin/master v2.6.32.9 >> >> stefan.ba...@canonical.com is the branch/tree owner, ccd, >> FYI to kernelnewbies. > > Um, you are not looking at the correct stable kernel branch on > git.kernel.org. I just released 2.6.32.33 the other day, so it looks > like you are just looking at an older kernel tree that has not been > updated. > > good luck, > > greg k-h > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
maranello for staging ?
we have, at http://www.cs.umd.edu/projects/maranello/ Abstract In this project, we design, implement, and evaluate Maranello, a novel partial packet recovery mechanism for 802.11. In Maranello, the receiver computes checksums over blocks in corrupt packets and bundles these checksums into a negative acknowledgment sent when the sender expects to receive an acknowledgment. The sender then retransmits only those blocks for which the checksum is incorrect, and repeats this partial retransmission until it receives an acknowledgment. Successful transmissions are not burdened by additional bits and the receiver needs not infer which bits were corrupted. We implemented Maranello using OpenFWWF (open source firmware for Broadcom wireless cards) and deployed it in a small testbed. We compare Maranello to alternative recovery protocols using a trace-driven simulation and to 802.11 using a live implementation under various channel conditions. To our knowledge, Maranello is the first partial packet recovery design to be implemented in commonly-available firmware. This is cool stuff. Im probably jumping the gun a bit, but well, its cool, and I have a wrt54g router to eventually try it on. I dont however have both sides of a wifi connection, so I wont be able to actually test it. Ive taken the patches on the site, applied them to 2.6.29-rc2, and started working them a bit to make them suitable for inclusion. Naturally I have questions: I started with their patches verbatim, as this preserves their provenance, and limits my chances of screwing up and making an unmaintainable mess out of them. Does staging tree value the preservation of provenance ? Or does it want all patches in the set to be "proper" (at minimum passing checkpatch). If so, I should keep the style fixups separate, instead of folding them back in to make each patch (including the original maranello patches) pass the objective criteria. How do I balance these competing interests ? Also, I figure Im serving several different purposes (or audiences) here; - inclusion (2.6.4x ?) - maranello team (success would be them adopting this rework in progress) - OpenWRT development - serious pool of hackers and devices to test upon (10.03.1-rc4 is using 2.6.32.25 currently, I dont know future kernel plans) I have a github repo: https://github.com/jimc/linux-2.6 and have pushed the following to mx0a branch. jimc@chumly:~/projects/lx/linux-2.6$ git log --oneline 4bb61c8 maranello.h defines maranello_stats, use it. 856f571 add spaces after C keywords e1251f1 fixup C99 comments e663495 cleanfile drivers/net/wireless/b43/phy_common.h too 2c67a78 run cleanfile, fix whitespace problems added by original patches 07bc126 extract maranello common parts 1 04f010b patch -p0 < maranello_released_kernelpatches/b43.patch 59f4336 patch -p0 < maranello_released_kernelpatches/include.patch 6cc5022 patch -p0 < maranello_released_kernelpatches/mac80211.patch 1de9e8e Linux 2.6.29-rc2 I merged this branch up with 2.6.32, and found I had to do ~6 merge fixups. I tried merge --squash, in effort to catch the changes to a separate commit; but that puts the commit on the 'wrong' branch - and it ISTM that it doesnt catch just the conflict resolution diffs, but rather the sum of all the diffs in the other branch. I was hoping to do a series of merge --squashes, and adapt the branch by slowly working up the various commits of master; effectively climbing the ladder. Is this a sane, straightforward strategy ? I figured Id select merge-points with this: 'git log --oneline drivers/net/wireless/b43' Im not quite sure how to proceed with this, Ive refrained from sending to net...@kernel.org, I guess Id like advice and feedback 1st. thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux gpio
2011/3/29 Jürgen Lambrecht : > Hello, > > I am new to linux (coming from eCos). > My backlight driver does not start up because the reset gpio pin is not > correct specified. > How does gpio work in Linux? > theres no single way. the new way is in drivers/gpio/* , implemented in gpiolib.c defined in #include there are also char drivers, with which Im more familiar. ./char/nsc_gpio.c ./char/pc8736x_gpio.c ./char/scx200_gpio.c > I have 2 platforms that use the same backlight driver, under arm, for > freescale imx: imx31_3ds and imx27_3ds. > I don't think that matters, I just need to understand the linux gpio. > > The imx31 platform gives the number 88 as gpio number to the backlight > driver. > That number comes out of 'iomux-mx3.h'. > In 'iomux-mx27.h' the GPIO's are specified in an other way, the > "hardware" way, specifying bank and port. I think Linux GPIO needs a > sort of general gpio number. The problem here is that board IDs are somewhat arbitrary, whereas driver IDs are predictable. Take soekris 4801 as an example; it has gpio on the CPU-SOC (scx200_gpio), and on a peripheral chip (pc8736x_gpio) The board uses CPU pins for Leds (and reset button I think), but the GPIO exposed to connector is on pc87366 chip. The char drivers use major device numbers to select the chip & driver, and minor numbers to select the bank/pin on the chip. THis lets users create device files with suitable names / numbers. > But how do I calculate that number out of the datasheet? > In the imx31 datasheet, I cannot find that number 88 (or the other > numbers in 'iomux-mx3.h'). > what driver supports your boards ? is it a new gpio driver ? > Kind regards, > Jürgen > > -- > Jürgen Lambrecht > R&D Associate > Tel: +32 (0)51 303045 Fax: +32 (0)51 310670 > http://www.televic-rail.com > Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium > Company number 0825.539.581 - RPR Kortrijk > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: confused by char dev registration in a gpio driver
hi Robert,
On Tue, May 3, 2011 at 3:21 PM, Robert P. J. Day wrote:
>
> i'm sure i'm going to embarrass myself here but i was perusing the
> char drivers for nice examples, and i ran across this excerpt in
> pc8736x_gpio.c:
Thanks for taking a look, and questioning what looks wrong.
>
> = begin =
>
> if (major) {
> devid = MKDEV(major, 0);
> rc = register_chrdev_region(devid, PC8736X_GPIO_CT, DEVNAME);
> } else {
> rc = alloc_chrdev_region(&devid, 0, PC8736X_GPIO_CT, DEVNAME);
> major = MAJOR(devid);
> }
>
so major is set here, either before the if, or as result of the else.
> if (rc < 0) {
> dev_err(&pdev->dev, "register-chrdev failed: %d\n", rc);
> goto undo_request_region;
> }
so when we get here, rc==0, and major is set
FWIW, it looks like I poached the above code from LDD3,
which explains why it looks right up to here..
Id agree that theres something wrong/unclear below.
major = rc looks kinda rotten.
Given that the only purpose was to debug-print,
and the "dynamic" fact is wrong, I think I'll prep a patch to yank that crap.
Unless you beat me to it :-)
> if (!major) {
> major = rc;
> dev_dbg(&pdev->dev, "got dynamic major %d\n", major);
> }
>
> = end =
>
> i'm good with most of that -- if the (parameter) major is explicit,
> then a dev_t of "devid" is created and register_chrdev_region() is
> used.
>
> on the other hand, if major is zero, then alloc_chrdev_region() is
> used for *dynamic* allocation of the major number. in both cases, the
> return code "rc" is saved and, if it's < 0, we have an error. and
> that's where the confusion comes in.
>
> i always thought both of those routines returned a simple zero to
> indicate success. but look at those last few lines -- that return
> code is assigned to "major", at which point it's *that* value that's
> printed. wouldn't that just be zero all the time?
>
> and wouldn't it also print that this was a "dynamic" major even if
> the user specified an explicit major number at load time? this second
> point is more nitpicky, but what about that first point? wouldn't a
> successful registration always print an allocated major number of
> zero?
>
> rday
>
again, thanks.
~jimc
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: confused by char dev registration in a gpio driver
On Tue, May 3, 2011 at 4:06 PM, Greg KH wrote:
> On Tue, May 03, 2011 at 05:21:11PM -0400, Robert P. J. Day wrote:
>>
>> i always thought both of those routines returned a simple zero to
>> indicate success. but look at those last few lines -- that return
>> code is assigned to "major", at which point it's *that* value that's
>> printed. wouldn't that just be zero all the time?
>>
>> and wouldn't it also print that this was a "dynamic" major even if
>> the user specified an explicit major number at load time? this second
>> point is more nitpicky, but what about that first point? wouldn't a
>> successful registration always print an allocated major number of
>> zero?
>
> I think you are right in that this code is wrong.
>
> The chardev stuff is a mess, I keep meaning for years to clean it up.
> Any proposals on a sane interface for this stuff is greatly appreciated.
>
> thanks,
>
> greg k-h
lets start with a list of grumbles about current api ?
1 - register_chrdev_region() VS alloc_chrdev_region()
ISTM that these could be combined into 1 function:
dev_t devid = MKNOD(major, minor);
register_chrdev_numbers(&devid, count, name);
ie make &devid an in/out parameter, where in-value
distinguishes which alloc/register behavior is desired.
this looks like a minor variation on alloc_chrdev_region()
one downside is need to include kdev_t.h
2 - EXPORTs in drivers/char/char_dev.c
original version (~2.6.12-rc2) had no __double-under exports,
now have:
EXPORT_SYMBOL(__register_chrdev);
EXPORT_SYMBOL(__unregister_chrdev);
__register_chrdev() looks to be a higher level function;
it 1st calls __register_chrdev_region()
then does cdev, kobject stuff too.
Or, why does it have __ in the name ?
__ typically means not for external use, but its exported.
is it because it does the cdev_add "too early"
ie before the caller is really ready to handle service requests ?
theres no caveat mentioned in the /** comments
Are the insanities you alluded to of a different sort,
ie internal suboptimalities ?
- struct inefficiencies ?
struct cdev *cdev; /* will die */
why die ? not needed, or available in another struct ?
- in char_dev.c, there is
static struct char_device_struct {
...} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];
ie 255 elements.
This is == to legacy MAJOR number space,
and is scanned 255..0 to find unused MAJOR number.
It will need new const if MAJOR range increases,
but doesnt waste much memory currently
My 32bit laptop uses 48 devices, so ~200 major slots are
empty/wasted (800 bytes) and ISTM like over-engineering
to fix this preemptively if >255 is unneeded.
OTOH, a hash or rb-tree could use only whats needed.
is there a 'library' hash implementation in the kernel ?
thanks
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: rationale for sysfs attr store/show accepting kobj_attribute?
On Sun, May 8, 2011 at 3:23 AM, Robert P. J. Day wrote:
>
> more just a curiosity than anything else, but i'm perusing the
> kobject sample programs in the kernel source directory and in
> kobject-example.c, there's one thing about which i'm a bit puzzled.
>
> the kernel header file sysfs.h defines the basic attribute structure
> as:
>
> struct attribute {
> const char *name;
> mode_t mode;
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lock_class_key *key;
> struct lock_class_key skey;
> #endif
> };
>
> in other words, simply the attribute name and mode. no problem.
>
> however, the header file kobject.h defines a more informative
> kobj_attribute structure thusly:
>
> struct kobj_attribute {
> struct attribute attr;
> ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
> char *buf);
> ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
> const char *buf, size_t count);
> };
>
> as you can see, it's just a regular sysfs attribute, bundled with the
> respective show and store routines.
>
> what puzzles me is why those show() and store() routines are defined
> as being passed the larger kobj_attribute structure, rather than the
> simpler sysfs attribute structure. it doesn't seem as if there's much
> value in having the show() and store() callbacks getting those two
> extra pieces of information.
well, theyre passing pointers, so "larger" doesnt matter.
the larger structure just has more info available.
Now whether pointers to show & store are particularly useful
from inside a show / store routine is debatable, as you noted.
A quick grep didnt show me anything, but my eye isnt
as discerning as Id like.
>
> in fact, in the sample program kobject-example.c, in the more
> general example, the callback routine needs to check the name of the
> attribute to know how to process it properly so it has to use
> "attr->attr.name" to access the field of the simpler "struct
> attribute" anyway.
>
thats to be expected.
looking up the name is far better than having many separate show/store
routines, each doing essentially the same thing, for
in0, in1, in2 ...
hwmon drivers used to do that (multiple fns, defined via macros),
the situation is much improved now, though I think a few still remain.
FWIW, there are SENSOR_ATTRs, which extend/subclass plain-old
struct attrs (modulo capitalization, approximations),
maybe that possibility is what kobj_attributes are about.
static struct sensor_device_attribute fan_min[] = {
SENSOR_ATTR(fan1_min, S_IWUSR | S_IRUGO, show_fan_min, set_fan_min, 0),
SENSOR_ATTR(fan2_min, S_IWUSR | S_IRUGO, show_fan_min, set_fan_min, 1),
SENSOR_ATTR(fan3_min, S_IWUSR | S_IRUGO, show_fan_min, set_fan_min, 2),
};
hwmon-sysfs.h - hardware monitoring chip driver sysfs defines
struct sensor_device_attribute{
struct device_attribute dev_attr;
int index;
};
struct sensor_device_attribute_2 {
struct device_attribute dev_attr;
u8 index;
u8 nr;
};
in device.h:
struct bus_attribute {
struct attributeattr;
ssize_t (*show)(struct bus_type *bus, char *buf);
ssize_t (*store)(struct bus_type *bus, const char *buf, size_t count);
};
struct driver_attribute {
struct attribute attr;
ssize_t (*show)(struct device_driver *driver, char *buf);
ssize_t (*store)(struct device_driver *driver, const char *buf,
size_t count);
};
struct class_attribute {
struct attribute attr;
ssize_t (*show)(struct class *class, struct class_attribute *attr,
char *buf);
ssize_t (*store)(struct class *class, struct class_attribute *attr,
const char *buf, size_t count);
};
struct device_attribute {
struct attributeattr;
ssize_t (*show)(struct device *dev, struct device_attribute *attr,
char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count);
};
I dont fully grok it, but theres clearly a pattern here.
> long question short -- even though it's clearly an arbitrary
> decision, was there some rationale for having those callback show()
> and store() routines be passed a pointer to the larger attribute
> structure containing the show() and store() routine addresses
> themselves (in this case, kobj_attribute)? or is everything those
> callback routines might be interested in available in the simpler
> "struct attribute"?
>
> and, of course, if one wanted to get the enclosing attribute
> structure, there's always "container_of", but i'd just like to know if
> there was a reason for the choice that was made.
>
> rday
>
> --
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http
Re: confused by char dev registration in a gpio driver
On Tue, May 10, 2011 at 12:40 PM, Greg KH wrote:
> On Tue, May 10, 2011 at 11:26:59AM -0600, Jim Cromie wrote:
>> lets start with a list of grumbles about current api ?
>>
...
>> Are the insanities you alluded to of a different sort,
>> ie internal suboptimalities ?
>
> No, those you have listed are all things I was talking about.
>
> And yes, there are also some internal issues as well (see the kobject
> mapping stuff).
>> static struct char_device_struct {
>> ...} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];
>> ie 255 elements.
>>
>> This is == to legacy MAJOR number space,
>> and is scanned 255..0 to find unused MAJOR number.
>> It will need new const if MAJOR range increases,
>> but doesnt waste much memory currently
>>
>> My 32bit laptop uses 48 devices, so ~200 major slots are
>> empty/wasted (800 bytes) and ISTM like over-engineering
>> to fix this preemptively if >255 is unneeded.
>> OTOH, a hash or rb-tree could use only whats needed.
>> is there a 'library' hash implementation in the kernel ?
>
> The kobject map stuff should handle most of this, but really, 800 bytes
> isn't that much overhead for the speed you get, right? Changing the
> code to use something else would take more than 800 bytes from what I
> can see.
>
cool. Im pleased that I agree with you :-) regarding the 800 byte cost.
but is speed even an issue ?
registering char drivers isnt exactly a hot path.
of course, simplicity is good too..
> Let's get the api fixed up first, that's the most important thing as
> it's what people use all the time.
>
Ive gone and done this.
Im currently messing with coccinelle / spatch to try to automate
the API - user conversion.
will send when the spatch transforms are a bit more sane.
> I'm going to have some long-distance flights soon, so I'll try to work
> on this then, thanks for the great summary above, I appreciate it.
Hope Ive beaten you to it,
or hold off on actually doing the work
>
> thanks,
>
> greg k-h
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: rtc_ops structure
On Wed, May 11, 2011 at 11:08 AM, Vikram Narayanan wrote:
> Hi,
>
> Is the structure rtc_ops still used in rtc drivers in the new kernels?
> If not, what is the equivalent of it?
>
[jimc@groucho linux-2.6.git]$ grep -r rtc_ops drivers/ |wc
159 842 11646
heres one of them:
drivers/rtc/rtc-cmos.c:static const struct rtc_class_ops cmos_rtc_ops = {
drivers/rtc/rtc-cmos.c: &cmos_rtc_ops, THIS_MODULE);
So Id say "yes"
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
knewbies project? - updating LDD3 source
over at http://code.google.com/p/ldd3/ it says: The famous "Linux Device Drivers" released the sample code. but the code does not reflect the latest kernel updates, some of code cannot even compile. This project is to make it compatible with the current kernel. http://lwn.net/Kernel/LDD3/ http://examples.oreilly.com/9780596005900/ Neither the OReilly tarball, nor the googlecode's svn repo will compile for me on an updated F-14 box, neither against uname -r, or a local git-tree. So I pulled the svn-tree, and made these changes. I got a fair way to getting things to compile. Changes are quick-n-dirty, and some may be wrong, esp around workqueue stuff - I pretty much did what compiler told me, w/o any analysis. I didnt even get compilation on the aio/iovec users, on the changes from 2003. I havent really gotten my head around the whole conversion strategy; I know a loop over iovec elements is probably needed, but Im unclear where it should be. and Im unsure whether these functions are now cluttering up things. static void sculld_do_deferred_op(void *p) static int sculld_defer_op(int write, struct kiocb *iocb, const struct iovec *iov, size_t count, loff_t pos) I guess the point is Ive run out of time now, and am hoping for a dose of clarity, and further patches, to get LDD3 source compiling, up-to-date, and reflecting current best practices. GRUMBLING: its annoying that the googlecode web-page obfuscates the site owner, making it impossible to reach him. Username: guanzhi1...@gmail.com Is there another LDD3 repo somewhere, that a google search didnt reveal to me ? perhaps on kernel.org ?? Should there be ? Im attaching my svndiff, in hte hopes that folks here will apply it and improve upon it. thanks ~jimc ldd3-code.svndiff Description: Binary data ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
trouble with __aquires(lock) __releases(lock)
Im trying to use macros from include/linux/compiler.h
and theyre giving me warnings that dont look right.
after thrashing on my own hacks, I looked to well established uses for guidance.
But make C=1 fs/file.o also gives errors, similar to mine.
What am I missing ?
or has some bitrot set in ?
202static int expand_fdtable(struct files_struct *files, int nr)
203__releases(files->file_lock)
204__acquires(files->file_lock)
205{
206struct fdtable *new_fdt, *cur_fdt;
207
208spin_unlock(&files->file_lock);
209new_fdt = alloc_fdtable(nr);
210spin_lock(&files->file_lock);
...
247int expand_files(struct files_struct *files, int nr)
248{
...
268/* All good, so we try */
269return expand_fdtable(files, nr);
270}
CHECK /home/jimc/projects/lx/linux-2.6/fs/file.c
/home/jimc/projects/lx/linux-2.6/fs/file.c:32:5: warning: symbol
'sysctl_nr_open_min' was not declared. Should it be static?
/home/jimc/projects/lx/linux-2.6/fs/file.c:33:5: warning: symbol
'sysctl_nr_open_max' was not declared. Should it be static?
/home/jimc/projects/lx/linux-2.6/fs/file.c:416:21: warning: symbol
'init_files' was not declared. Should it be static?
/home/jimc/projects/lx/linux-2.6/include/linux/spinlock.h:325:2:
warning: context problem in 'expand_fdtable': '_raw_spin_unlock'
expected different context
/home/jimc/projects/lx/linux-2.6/include/linux/spinlock.h:325:2:
context 'lock': wanted >= 1, got 0
/home/jimc/projects/lx/linux-2.6/fs/file.c:269:23: warning: context
problem in 'expand_files': 'expand_fdtable' expected different context
/home/jimc/projects/lx/linux-2.6/fs/file.c:269:23:context
'file_lock': wanted >= 1, got 0
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
2 mods with same PCI-ID table, one installs, other fails modprobe
(aside - whats the correct ML? Ive used both suggested by my mail interface)
I have 2 modules with same modinfo alias,
one installs, the other gets -ENODEV.
Id expect them to both act the same.
What am I missing ?
root@voyage:~# modprobe geode-aes
root@voyage:~# lsmod |grep geode_aes
geode_aes 4229 0
root@voyage:~# modprobe geode-rng
dynamic_debug:ddebug_remove_module: removing module "geode_rng"
FATAL: Error inserting geode_rng
(/lib/modules/3.0.0-skc-dyndbg+/kernel/drivers/char/hw_random/geode-rng.ko):
No such device
root@voyage:~# modinfo geode-aes
filename:
/lib/modules/3.0.0-skc-dyndbg+/kernel/drivers/crypto/geode-aes.ko
license:GPL
description:Geode LX Hardware AES driver
author: Advanced Micro Devices, Inc.
alias: pci:v1022d2082sv*sd*bc*sc*i*
depends:
vermagic: 3.0.0-skc-dyndbg+ preempt mod_unload modversions GEODEGX1
root@voyage:~# modinfo geode-rng
filename:
/lib/modules/3.0.0-skc-dyndbg+/kernel/drivers/char/hw_random/geode-rng.ko
license:GPL
description:H/W RNG driver for AMD Geode LX CPUs
alias: pci:v1022d2082sv*sd*bc*sc*i*
depends:rng-core
vermagic: 3.0.0-skc-dyndbg+ preempt mod_unload modversions GEODEGX1
IE both have same alias, and (unsurprisingly) the same DEVICE_ID.
geode-rng's 1 dependency isnt the problem:
root@voyage:~# modprobe rng-core
root@voyage:~# lsmod |grep rng
rng_core3010 0
DEVICE-IDs:
jimc@chumly:~/projects/lx/linux-2.6/drivers/crypto$ grep PCI_DEV geode-aes.c
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_LX_AES), } ,
jimc@chumly:~/projects/lx/linux-2.6/drivers/crypto$ cd ../char/hw_random/
jimc@chumly:~/projects/lx/linux-2.6/drivers/char/hw_random$ grep
PCI_DEV geode-rng.c
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_LX_AES), 0, },
hmmm. is that trailing 0 important ?
Id think not, {..} is a literal constant assignment, 0 is only sensible default.
The apparent diff is how the __init is done.
static struct pci_device_id geode_aes_tbl[] = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_LX_AES), } ,
{ 0, }
};
MODULE_DEVICE_TABLE(pci, geode_aes_tbl);
static struct pci_driver geode_aes_driver = {
.name = "Geode LX AES",
.id_table = geode_aes_tbl,
.probe = geode_aes_probe,
.remove = __devexit_p(geode_aes_remove)
};
static int __init
geode_aes_init(void)
{
return pci_register_driver(&geode_aes_driver);
}
geode-rng does it the (older?) more manual way:
static int __init mod_init(void)
{
int err = -ENODEV;
struct pci_dev *pdev = NULL;
const struct pci_device_id *ent;
void __iomem *mem;
unsigned long rng_base;
for_each_pci_dev(pdev) {
ent = pci_match_id(pci_tbl, pdev);
if (ent)
goto found;
}
/* Device not found. */
goto out;
found:
...
Qs
1 - why do they differ in modprobe results ?
bug likely ??
2 - which is correct ? success or failure ?
FWIW, heres my PCI devices.
The CPU is an SC1100 - its a Geode, but not a Geode-GX or LX
(though the distinctions arent as clear as Id like :-/)
root@voyage:~# lspci -nn
00:00.0 Host bridge [0600]: Cyrix Corporation PCI Master [1078:0001]
00:06.0 Ethernet controller [0200]: National Semiconductor Corporation
DP83815 (MacPhyter) Ethernet Controller [100b:0020]
00:07.0 Ethernet controller [0200]: National Semiconductor Corporation
DP83815 (MacPhyter) Ethernet Controller [100b:0020]
00:08.0 Ethernet controller [0200]: National Semiconductor Corporation
DP83815 (MacPhyter) Ethernet Controller [100b:0020]
00:0a.0 Ethernet controller [0200]: Belkin Wireless PCI Card - F5D6001
[1799:6001] (rev 20)
00:0e.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
88W8361 [TopDog] 802.11n Wireless [11ab:2a02] (rev 03)
00:12.0 ISA bridge [0601]: National Semiconductor Corporation SC1100
Bridge [100b:0510]
00:12.1 Bridge [0680]: National Semiconductor Corporation SC1100 SMI &
ACPI [100b:0511]
00:12.2 IDE interface [0101]: National Semiconductor Corporation
SCx200, SC1100 IDE controller [100b:0502] (rev 01)
00:12.5 Bridge [0680]: National Semiconductor Corporation SC1100 XBus
[100b:0515]
00:13.0 USB Controller [0c03]: Compaq Computer Corporation ZFMicro
Chipset USB [0e11:a0f8] (rev 08)
Specifically, theres no AMD ID in the output
root@voyage:~# lspci -nn |grep 1022
root@voyage:~# lspci -nn |grep 100b
00:06.0 Ethernet controller [0200]: National Semiconductor Corporation
DP83815 (MacPhyter) Ethernet Controller [100b:0020]
>From all this, it seems that the failure to install is correct,
which suggests some bug in pci_register_driver,
but its hard to imagine that - otherwize its survived (well hidden)
for a long time
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Code Generator
On Mon, Sep 12, 2011 at 3:04 PM, mosta wrote: > Hey All, > > does somebody know of projects that use code generators to generate > kernel modules? I'm thinking about using a strongly typed language like > haskell with a code generator to generate kernel C-Code. I want to > achieve more secure kernel modules this way. Is this a silly idea? or > had someone already done that. > > hope for answers? So you want to write a haskell program to write source code : foo.c for a kernel module, maybe write a makefile for an out-of-tree module, then make, install that module. if you post a hello-world.ko generator, Id read the email ( haskell curiosity ) But I imagine youre looking towards more complex stuff. what advantages are you anticipating ? - correct-by-construction ? similar but different is coccinelle. it uses caml -> SmPL (the similar part) code to parse C code, looks for sequences matched by semantic patches, and rewrites that code. Its been used to find and repair numerous kernel programming errors, many with security ramifications. dozens of cocci scripts are in the kernel tree: ./scripts/coccinelle/*/*.cocci to detect newly committed errors. If security per se is your main motivation, then you should probably use coccinelle. If the haskell part is important too, maybe write an spatch generator. (Id read that too :) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
objdump -S for a different dir.
hi folks, out of habit, I build my kernels to a build tree ie use make O=../build-foo just once, then cd ../build-foo, and thereafter run make there this doesnt play nice with objdump -S --source Display source code intermixed with disassembly, if possible. Implies -d. it seems its not possible unless the source and obj are in the same file. GDB manages to find the source, whats missing in objdump ? FWIW, Id love a micro-tutorial on this, anyone know how to display, dissect the obj file, debuginfo etc ? or can recommend some on-line tome that gets into it at some breadth and depth ? many many search hits are for quick Q&A that doesnt get deeper than a puddle. thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Fwd: kernel 3.2rc4 hangs if I use allyesconfig
should have gone to list.. -- Forwarded message -- From: rajaneesh acharya Date: Sat, Dec 10, 2011 at 2:48 AM Subject: Re: kernel 3.2rc4 hangs if I use allyesconfig To: Jim Cromie Hi Jim, allmodconfig and config borrowed from debian distro works fine Regards Rajaneesh as Srivatsa Bhat bhat pointed out, -rc4 probably has the bug fixed later whereas sufficiently old kernels dont. (before it was introduced) - Original Message - From: Jim Cromie To: rajaneesh acharya Sent: Sat, 10 Dec 2011 12:31:32 +0530 (IST) Subject: Re: kernel 3.2rc4 hangs if I use allyesconfig On Fri, Dec 9, 2011 at 11:14 PM, rajaneesh acharya wrote: > Hi Mulyadi, > > Please find the screenshot...There are no debug messages being thrown out... > > Ran this from qemu with command > > qemu-system-x86_64 -kernel /boot/vmlinuz-3.2.0 -initrd initramfs.gz > > > > Regards > Rajaneesh > have you tried allmodconfig, or a config borrowed from a distro build ? > > - Original Message - > From: Mulyadi Santosa > To: rajaneesh acharya > Cc: kernelnewbies@kernelnewbies.org > Sent: Sat, 10 Dec 2011 10:44:40 +0530 (IST) > Subject: Re: kernel 3.2rc4 hangs if I use allyesconfig > > On 09/12/2011, rajaneesh acharya wrote: >> Hi >> >> I created a kernel using the target as allyesconfig. The machine fails to >> bootup (just hangs with 100% cpu utilization) with message "Booting the >> kernel" >> If I use the config from a distro and create the kernel image, it boots >> fine.. > > Hi Rajanesh > > Could you post at least 20 lines of boot messages up to the time it > hangs? The clue is quite too few IMHO. > > AFAIK, it already passed the decompressing of kernel image, so at > least we know there is little chance kernel image got corrupted. > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > <>___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: objdump -S for a different dir.
On Sat, Dec 10, 2011 at 12:46 AM, Dave Hylands wrote: > Hi Jim, > > On Fri, Dec 9, 2011 at 10:59 PM, Jim Cromie wrote: >> >> hi folks, >> >> out of habit, I build my kernels to a build tree >> ie use make O=../build-foo just once, >> then cd ../build-foo, and thereafter run make there >> >> this doesnt play nice with objdump -S >> --source >> Display source code intermixed with disassembly, if >> possible. Implies -d. >> >> it seems its not possible unless the source and obj are in the same file. >> GDB manages to find the source, whats missing in objdump ? >> >> FWIW, Id love a micro-tutorial on this, >> anyone know how to display, dissect the obj file, debuginfo etc ? >> or can recommend some on-line tome that gets into it at some breadth and >> depth ? >> many many search hits are for quick Q&A that doesnt get deeper than a >> puddle. > > > So I normally do out of tree builds, but I always run make from the source > tree and specify the O= option. > > I'm using 3.0.1, and in menuconfig, I went into "Kernel hacking", enabled > "Kernel debugging" and then "Compile the kernel with debug info". > > The "Compile the kernel with debug info" option enables CONFIG_DEBUG_INFO > which cause the kernel source to be compiled with the -g option which adds > the debugging information needed to find the source from the objects. > > I normally cross compile for the ARM, so I then cd'd into my build tree and > tried arm-linux-gnueabi-objdump -S on a few object files and they all gave > intermingled C and assembler listings. > > I tried it using your method and it seemed to work fine for me as well. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.com Thanks Dave, Id have sworn that after I found -S to not work out-of-tree, I built in-tree using same .config and -S did work. But of course that in-tree build is gone and I cant verify. (it interferes with continued out-of-tree builds, which end with 'run make mrproper') Anyway, its certainly working now. It was probably a different config on a different box, built for a small CF. thanks again ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: What is use of apply_alternative function from alternative.c
On Tue, Mar 20, 2012 at 7:54 AM, Pritam Bankar wrote: > Hi, > Cal anyone help me in understanding alternative.c file from Linux source > code. > I want to learn function apply_alternative. AFAIK this code applies better > replacement to instruction set used by processor. > But I am not sure what exactly it is doing ? if you add "debug-alternatives" to boot args, you'll see something like this. basically it patches the kernel, inserting locks and synchronization so that the kernel can run on SMP / multi-core arches. Once this is done, the other cores can be started. There are also some helpful comments in the code :-O apply_alternatives: alt table 81d546a8 -> 81d54ccc alternatives_smp_module_add: locks 81d57000 -> 81d5a000, text 8100 -> 8149a3d2, name core kernel lockdep: fixing up alternatives. lockdep: fixing up alternatives. lockdep: fixing up alternatives. apply_alternatives: alt table 81a0363a -> 81a03652 alternatives_smp_module_add: locks a001115c -> a001117c, text a000f000 -> a0010ac0, name video alternatives_smp_module_add: locks a002f530 -> a002f598, text a002c000 -> a002efb4, name agpgart alternatives_smp_module_add: locks a005b1a4 -> a005b244, text a0039000 -> a004e508, name drm alternatives_smp_module_add: locks a007f634 -> a007f638, text a007b000 -> a007e6fc, name drm_kms_helper alternatives_smp_module_add: locks a0091a84 -> a0091abc, text a0087000 -> a008fab4, name ttm apply_alternatives: alt table a011ca28 -> a011ca40 alternatives_smp_module_add: locks a011c8f8 -> a011c974, text a00a1000 -> a010c104, name nouveau alternatives_smp_module_add: locks a006fc14 -> a006fc68, text a006b000 -> a006e340, name usb_storage alternatives_smp_module_add: locks a013d45c -> a013d474, text a0138000 -> a013c044, name autofs4 alternatives_smp_module_add: locks a0177b38 -> a0177c84, text a0141000 -> a0170380, name ipv6 alternatives_smp_module_add: locks a000d294 -> a000d2bc, text a000c000 -> a000d174, name uinput apply_alternatives: alt table a01d7b77 -> a01d7be3 alternatives_smp_module_add: locks a01d491c -> a01d4a00, text a01a2000 -> a01ccf6c, name kvm > > -- > > Pritam Bankar > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel IP Forwarding path
On Sun, Mar 25, 2012 at 2:02 PM, Suresh Kumar Subramanian wrote: > Hi, > > I am so interested to tune the kernel forwarding path. > > > My questions are, > > Is it possible, to expose some API to user space to manipulate the routing > table (Ex: add equal cost /unequal cost routes for load balancing? > Is it possible, to change the routing flow ( i want to add some custom module > before route look up) and expose some API to user space? > Is it possible , to influence the routing look up mechanism? > > I am not able to find the good docuements for this. > can some one share some good tutorial /link? netfilter.org, tc (traffic control userspace prog) maybe xtables > > Thanks > suresh > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Git info needed
On Sun, Mar 11, 2012 at 11:06 PM, trisha yad wrote: > Hi All, > > I want Info about how to get patches from private Git. > I have downloaded Catalin Marinas git(ARM). I want to know check to > support ARM 15 how many patches are added, so that we can analysis the > difference. > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary > > 1. I want to extract the patches. what command I will use for it with > reference to linus torvalds git. git clone URL (which is on that page) > 2. Also If i want to see on kernel version 3.1 which all patches are > added by catalin to make it work for ARM 15, How can I know. once youve cloned, you can branch from HEAD, and rebase the new branch to whatever new starting point you want. this is pretty basic git usage, you should find and read some of the tutorials iirc, one is "git in 20 commands" or something. > > > Thanks a lot. > Regards > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
modprobe succeeding despite mismatch on PCI-ID
hi all, I have a card which modprobes, despite a PCI-ID mismatch (though its a near match) root@voyage:~# lsmod | grep mwl8k mwl8k 30986 0 mac80211 261375 2 mwl8k,rtl8180 root@voyage:~# lsmod | grep mwl8k mwl8k 30986 0 mac80211 261375 2 mwl8k,rtl8180 cfg80211 123158 3 mwl8k,rtl8180,mac80211 root@voyage:~# modinfo mwl8k filename: /lib/modules/3.3.0-next-20120328-ske+/kernel/drivers/net/wireless/mwl8k.ko license:GPL author: Lennert Buytenhek version:0.13 description:Marvell TOPDOG(R) 802.11 Wireless Network Driver ... firmware: mwl8k/helper_8363.fw srcversion: 7DE0D6B47B634A3BAF6D101 alias: pci:v11ABd2A43sv*sd*bc*sc*i* alias: pci:v11ABd2A40sv*sd*bc*sc*i* alias: pci:v11ABd2A30sv*sd*bc*sc*i* alias: pci:v11ABd2A2Bsv*sd*bc*sc*i* alias: pci:v11ABd2A24sv*sd*bc*sc*i* alias: pci:v11ABd2A0Csv*sd*bc*sc*i* alias: pci:v11ABd2A0Asv*sd*bc*sc*i* that last alias is the closest to the cards ID, but this isnt horseshoes. Or is it ? root@voyage:~# lspci -vvnnk -s 00:e 00:0e.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] (rev 03) Subsystem: Marvell Technology Group Ltd. 88W8361 [TopDog] 802.11n Wireless [11ab:2a02] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: reboot.c and X86-64 architectures
On Tue, Apr 3, 2012 at 9:22 PM, Miles Fidelman wrote: > > Hello Folks, > > Perhaps someone here can help me understand the behavior of the kernel reboot > code. > > I've recently migrated from running a 32bit kernel to a 64bit one > (specifically Debian Lenny 32bit environment to 2.6.32-5-xen-amd64 on > top of xen-4.0-amd64 hypervisor build). > > This is a somewhat older, and apparently quirky, hardware box. I've > found that the only way to reboot it, short of power cycling, is jumping > through the bios - using the "reboot=bios" kernel option at boot time > works just fine for an X86_32 kernel. But... this doesn't work with the > 64bit kernel. > > Pouring through both the documentation and the code for > arch/x86/kernel/reboot.c yields the very specific admonition (in comments > describing command-line kernel options), that reboot=bios (Reboot by jumping > through the BIOS) only applies to X86_32 - and the case statements in the > code seem to align with the comment. > > None of the other available command line options seem to work with my > hardware, which leads to two questions: > > 1. What's the logic behind this? Why not enable a bios reboot for 64bit > kernels? Anybody know the history? > > 2. Anybody know a workaround, short of patching and compiling a custom > kernel? Are there other paths through the reboot code that can invoke a bios > reboot? (Note: None of the available command line options seem to work on > this particular box/bios combination, and kexec-reboot is not available > for this combination of kernel and hypervisor). > perhaps you should try a non-hypervisor kernel. I have no experience with one, but it could be the issue. Virtualization developers tend to have big fast modern boxes, and as you say, yours isnt so modern. It might be worth a bug report if it appears to be hypervisor related, but you are on an old kernel too. Is Lenny current, or is it Sarge ? maybe a debian upgrade is easier than a current (3.3) kernel build, but latter is pretty easy. > Thank you very much, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. Yogi Berra > > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
__initdata access at runtime
hi folks,
Ive written a pair of patches which have an issue with __initdata
[PATCH 1/3] bug.h: add BUILD_BUG_DECL, usable at file scope
[PATCH 2/3] bug.h: add test/demo module
1st one declares a BUILD_BUG_DECL(name, condition) which breaks
compile if the condition is true, much like the other *BUG* macros.
Its usable at file scope, which lets it verify that 2 arrays are the
same size:
int arr1[] = {1,2,3};
int arr2[] = {1,2,4};
BUILD_BUG_DECL(arr1_VS_arr2, ARRAY_SIZE(arr1) != ARRAY_SIZE( arr2));
heres the macro:
+#define BUILD_BUG_DECL(name, cond) \
+ static __initdata struct { \
+ int BUILD_BUG_DECL_ ## name[1 - 2*!!(cond)];\
+ } BUILD_BUG_DECL_ ##name[0] __attribute__((unused))
+
which expands the above like:
static __attribute__ ((__section__(".init.data"))) struct {
int BUILD_BUG_DECL_arr1_VS_arr1[1 - 2*!!(sizeof(arr1) != sizeof(arr2))];
} BUILD_BUG_DECL_arr1_VS_arr1[0] __attribute__((unused));
It works as pretty much as intended, but there are a few wrinkes, as
exposed by the run-time part of the test module (patch 2).
The macro attempts to create no storage (by sizing the array as [0]),
and put it into the .init.data section of the object code.
The test module does 3 things:
1 - proves the macro works. Remove the // on commented BUILD_BUG_DECL
statements to try for yourself.
2 - references the variable defined by the macro, during module_init.
Printing that value works, its always 0, why ?
I thought that the __attribute__((unused)) would have prevented or
warned about this access. I also tried __attribute__((nodref,
unused)), but compiler warned about it, so I pulled that out.
3 - references the variable defined by the macro, during runtime.
ie: $> cat /sys/module/build-asserts/cbint
That gets a paging error. This makes sense, as the .init.data has
been freed after module_init is done.
Why doesnt the compiler warn or error about referencing an __initdata
var from a non-__init function ?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 1/3] bug.h: add BUILD_BUG_DECL, usable at file scope
This adds BUILD_BUG_DECL, primarily to check sizes of file-scoped
arrays etc:
const char const *names[] = { "bart", "lisa", "homer", "marge" };
int a[] = {1,2,3,4}, b[] = {1,2,3,5}, c[] = {1,2}
long d[] = {1,2};
BUILD_BUG_DECL(Luke, sizeof(a) != sizeof(d)); // ok, but iffy
usage
BUILD_BUG_DECL(Han, sizeof(a) != sizeof(b)); // good
BUILD_BUG_DECL(Obi, ARRAY_SIZE(a) != ARRAY_SIZE(b)); // better
BUILD_BUG_DECL(Yoda, ARRAY_SIZE(a) != ARRAY_SIZE(names)); // good, on
different types
BUILD_BUG_DECL(Darth, sizeof(a) != sizeof(c));// compile err
example 1 expands as:
static __attribute__ ((__section__(".init.data"))) struct {
int BUILD_BUG_DECL_Luke[1 - 2*!!(sizeof(a) != sizeof(b))];
} BUILD_BUG_DECL_Luke[0] __attribute__((unused));
The name parameter distinguishes multiple uses in the same scope, but
is otherwise arbitrary. You can reuse the name of one of the checked
vars, or pick something easy to find on the rare occaision when the
assertion breaks the build.
example 5 yields:
error: size of array ‘BUILD_BUG_DECL_Darth’ is negative
Signed-off-by: Jim Cromie
---
include/linux/bug.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 72961c3..c76e6f6 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -17,6 +17,7 @@ struct pt_regs;
#define BUILD_BUG_ON_NULL(e) ((void*)0)
#define BUILD_BUG_ON(condition)
#define BUILD_BUG() (0)
+#define BUILD_BUG_DECL(name, condition)
#else /* __CHECKER__ */
/* Force a compilation error if a constant expression is not a power of 2 */
@@ -70,6 +71,20 @@ extern int __build_bug_on_failed;
__build_bug_failed(); \
} while (0)
+/**
+ * BUILD_BUG_DECL - check declared objects
+ * @name: distinguishes multiple uses at same scope.
+ * @cond: false expr, typically like sizeof(a) != sizeof(b)
+ *
+ * This works at file-scope too, and supports checks like:
+ * BUILD_BUG_DECL(foo, sizeof(a) != sizeof(b));
+ * BUILD_BUG_DECL(id_strings, ARRAY_SIZE(id_strings) != ARRAY_SIZE(id_vals));
+ */
+#define BUILD_BUG_DECL(name, cond) \
+ static __initdata struct { \
+ int BUILD_BUG_DECL_ ## name[1 - 2*!!(cond)];\
+ } BUILD_BUG_DECL_ ##name[0] __attribute__((unused))
+
#endif /* __CHECKER__ */
#ifdef CONFIG_GENERIC_BUG
--
1.7.8.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 2/3] bug.h: add test/demo module
add drivers/misc/build-asserts.c to test BUILD_BUG_DECL.
BUILD_BUG_DECL works as intended, but __attribute((unused)) appears to
be ineffective in the macro:
cmp_ints() run at __init time is able to reference the storage w/o
warnings (no section complaints, even though those functions are not
explicitly marked as __init - I guess thats inferred..).
cmp_ints() run from mod-param getter/setter callbacks pukes badly. I
guess this is to be expected, since __initdata is dropped once boot is
complete. But why no compile warnings ??
root@voyage:~# cat /sys/module/build_asserts/parameters/*
build_asserts.cbint_get: got bufp:c65cd000='' kp:c8bb967c
build_asserts.cbint_get: kp-name:cbint
build_asserts.cbint_get: kp-arg:c8bb9113
build_asserts.cbint_get: kp-ops:c8bb973c
build_asserts.cbint_get: kp-ops-set:c8bb9179
build_asserts.cbint_get: kp-ops-get:c8bb9000
build_asserts.cbint_get: cbint_get me:c8bb9000
BUG: unable to handle kernel paging request at c8bbb000
IP: [] cbint_get+0xd8/0x113 [build_asserts]
*pde = 06c76067 *pte =
Oops: [#1] PREEMPT
Modules linked in: build_asserts scx200_gpio scx200_hrt pc8736x_gpio nsc_gpio
pc87360 hwmon_vid scx200_acb acx_mac80211(O) arc4 rtl8180 mac80211 eeprom_93cx6
scx200 cfg80211 ohci_hcd pata_sc1200 [last unloaded: build_asserts]
Pid: 1364, comm: cat Tainted: G O 3.4.0-rc1-ske+ #24
EIP: 0060:[] EFLAGS: 00010282 CPU: 0
EIP is at cbint_get+0xd8/0x113 [build_asserts]
EAX: 0035 EBX: c65cd000 ECX: c745 EDX: 0003
ESI: c8bb967c EDI: c65cd000 EBP: c7451efc ESP: c7451ee0
DS: 007b ES: 007b FS: GS: 00e0 SS: 0068
CR0: 8005003b CR2: c8bbb000 CR3: 066b7000 CR4:
DR0: DR1: DR2: DR3:
DR6: 0ff0 DR7: 0400
Process cat (pid: 1364, ti=c745 task=c6524f80 task.ti=c745)
Stack:
c8bb945e c8bb96bc c8bb9000 c65cd000 c8bb967c c675c270 c7451f10
c012f536 c675c270 c8bb9790 c012f503 c7451f24 c012f35b c6507740 c60deb40
c043eb28 c7451f70 c02010d5 c6753680 c7451f44 c027fe90 c6753680
Call Trace:
[] ? 0xc8bb8fff
[] param_attr_show+0x33/0x57
[] ? __kernel_param_unlock+0x14/0x14
[] module_attr_show+0x21/0x26
[] sysfs_read_file+0x9e/0x154
[] ? security_file_permission+0x27/0x2b
[] ? rw_verify_area+0xd0/0xf2
[] vfs_read+0x8d/0xd3
[] ? sysfs_open_file+0x1fa/0x1fa
[] sys_read+0x42/0x63
[] syscall_call+0x7/0xb
Code: 04 24 3a 94 bb c8 89 44 24 08 e8 89 7c 87 f7 c7 44 24 08 00 90 bb c8 c7
44 24 04 bc 96 bb c8 c7 04 24 5e 94 bb c8 e8 6d 7c 87 f7 00 b0 bb c8 c7 44
24 04 bc 96 bb c8 89 44 24 0c 89 44 24 08
EIP: [] cbint_get+0xd8/0x113 [build_asserts] SS:ESP 0068:c7451ee0
CR2: c8bbb000
---[ end trace bfbcc6aee803d03b ]---
Signed-off-by: Jim Cromie
---
drivers/misc/Makefile|2 +
drivers/misc/build-asserts.c | 239 ++
2 files changed, 241 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/build-asserts.c
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 3e1d801..5aff6bb 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,3 +49,5 @@ obj-y += carma/
obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o
+
+obj-m += build-asserts.o
diff --git a/drivers/misc/build-asserts.c b/drivers/misc/build-asserts.c
new file mode 100644
index 000..4a051b5
--- /dev/null
+++ b/drivers/misc/build-asserts.c
@@ -0,0 +1,239 @@
+
+#define pr_fmt(fmt) KBUILD_MODNAME ".%s: " fmt, __FUNCTION__
+
+#include
+#include
+#include
+#include
+#include
+
+int a[] = {1,2,3,4};
+int b[] = {1,2,3,5};
+int c[] = {3,5};
+long d[] = {1,2};
+
+const char *names[] = { "bart", "lisa", "homer", "marge" };
+
+struct bridge {
+ int member_ids[4];
+ char *names[4];
+ char *snacks[3];// hungry ?
+} clubs[4];
+
+BUILD_BUG_DECL(foo, ARRAY_SIZE(a) != ARRAY_SIZE(b));
+BUILD_BUG_DECL(buz, sizeof(a) != sizeof(b)); // good
+// BUILD_BUG_DECL(a, sizeof(a) != sizeof(d)); // brittle
+BUILD_BUG_DECL(b, ARRAY_SIZE(a) != ARRAY_SIZE(names)); // good, on different
types
+
+// BUILD_BUG_DECL(d, ARRAY_SIZE(a) != ARRAY_SIZE(d)); // compile err, correct
+// BUILD_BUG_DECL(bonk, sizeof(a) != sizeof(names)); // breaks, correct
+// BUILD_BUG_DECL(ac, sizeof(a) != sizeof(c)); // err
+
+
+BUILD_BUG_DECL(joe, ARRAY_SIZE(a) != ARRAY_SIZE(clubs));
+BUILD_BUG_DECL(bob, ARRAY_SIZE(a) != ARRAY_SIZE(clubs[0].member_ids));
+BUILD_BUG_DECL(mike, ARRAY_SIZE(a) != ARRAY_SIZE(clubs[0].names));
+
+// BUILD_BUG_DECL(sue, ARRAY_SIZE(a) != ARRAY_SIZE(clubs[0].snacks));
+// cant use typeof like this
+// BUILD_BUG_DECL(ike, typeof(clubs[0].snacks) != typeof(clubs[0].names));
+
+union {
+ int a;
+ long b;
+ char c;
+ char *s;
+ int arr[4];
+} pba;
+
+// these cause warning at file scope,
Re: wrapfs sources
On Fri, Apr 6, 2012 at 2:24 AM, V.Ravikumar wrote: > Hi, > I ported latest wrapfs code compile against 2.6.18 kernel. > Now I'm able to build module ,but there my be bugs. > insmod of the file system module that was built was successful. insmod ? that doesnt take care of module dependencies. try modprobe, maybe preceded by depmod. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
please report distros with CONFIG_DYNAMIC_DEBUG, using ddebug_query= boot param
hi all, Ive been asked whether ddebug_query= boot param is used in any distros, I think the question seeks to determine a good deprecation schedule for it (its been obsoleted by dyndbg= in driver-core-next) Would you all be so kind as to check your favorite distros, and report the ones that have one or both ? Ubuntu 12.04 LTS lacks it: jimc@chumly:~/projects/lx/linux-2.6$ grep DYNAMIC_DEBUG /boot/config* /boot/config-3.0.0-17-generic:# CONFIG_DYNAMIC_DEBUG is not set /boot/config-3.2.0-24-generic:# CONFIG_DYNAMIC_DEBUG is not set Voyage linux also lacks it, (also debian based) Fedora-16 has config option: $ uname -a Linux groucho.jimc.earth 3.3.2-6.fc16.x86_64 #1 SMP Sat Apr 21 12:43:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ grep DYNAMIC_DEBUG /boot/config-3.3.* /boot/config-3.3.1-5.fc16.x86_64:CONFIG_DYNAMIC_DEBUG=y /boot/config-3.3.2-1.fc16.x86_64:CONFIG_DYNAMIC_DEBUG=y /boot/config-3.3.2-6.fc16.x86_64:CONFIG_DYNAMIC_DEBUG=y but its not used by default. I have modified my grub defaults: $ grep ddebug_query /etc/default/grub GRUB_CMDLINE_LINUX='quiet rhgb loglevel=8 ddebug_query="module params +p" dynamic_debug.verbose=1 nouveau.dyndbg nouveau.force_post=1 it87.dyndbg=+p nouveau.perflvl_wr=' FYI, the above usage will eventually be unsupported, it can be replaced in driver-core-next by either of: dyndbg="module params +p" params.dyndbg=+p params.dyndbg # defaults to +p the 2nd, 3rd forms also work for loadable modules (though params isnt one of them) thanks in advance Jim ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Incremental Linking
On Wed, May 23, 2012 at 10:51 AM, Sarbojit Ganguly
wrote:
> Hello Dave,
>
> I tried to explain this feature (no doubt you have explain it
> perfectly) but he is looking for _how_ kernel module gets loaded and
> somehow (I wonder how!) dubs the entire process as "incremental link"
> !
>
The easiest way to see the whole process happening is to turn on debug,
then modprobe a module. youll see lots of details.
If you build 3.5-rc0 (ie rc1 is not done yet), and turn on CONFIG_DYNAMIC_DEBUG,
you can enable the pr_debugs selectively, and narrow down to the info
that you want.
heres some of the info youll see:
jimc@jimc-desktop:~/projects/lx/linux-2.6$ grep pr_debug kernel/module.c
pr_debug("Failed to find symbol %s\n", name);
pr_debug("%s uses %s!\n", a->name, b->name);
pr_debug("%s does not use %s!\n", a->name, b->name);
pr_debug("Allocating new usage for %s.\n", a->name);
pr_debug("%s unusing %s\n", mod->name, i->name);
pr_debug("Looking at refcount...\n");
pr_debug("%s already dying\n", mod->name);
pr_debug("Found checksum %lX vs module %lX\n",
pr_debug("Common symbol: %s\n", name);
pr_debug("Absolute symbol: 0x%08lx\n",
pr_debug("Core section allocation order:\n");
pr_debug("\t%s\n", sname);
pr_debug("Init section allocation order:\n");
pr_debug("\t%s\n", sname);
pr_debug("\t%s\n", info->secstrings + symsect->sh_name);
pr_debug("\t%s\n", info->secstrings + strsect->sh_name);
pr_debug("final section addresses:\n");
pr_debug("\t0x%lx %s\n",
pr_debug("load_module: umod=%p, len=%lu, uargs=%p\n",
I dont recall if it gets into symbol-by-symbol linking, but it might.
Read Doc/dynamic_debug_howto for more usage info.
Daves simple example would be valuable to look at,
esp with readelf and objdump.
> On 23 May 2012 21:47, Dave Hylands wrote:
>> Hi Somanath,
>>
>> On Tue, May 22, 2012 at 2:56 AM, somanath sahoo
>> wrote:
>>> Hi,
>>>
>>> As newbie in linux kernel, I would like to understand the concept of
>>> "incremental linking " w.r.t to linux kernel module.
>>
>> Incremental linking is basically just taking some objects files,
>> linking them together to produce a larger object file. The object file
>> still has undefined references. It will also coalesce sections of the
>> same name. The kernel likes to use sections for storing pointers to
>> initcall functions and other things like that.
>>
>> Some people might also call this partial linking. The kernel uses this
>> technique for the main portion of the kernel as well. If you look
>> through your build directory, you will find a whole bunch of
>> built-in.o files. Each one of these is a partially linked object file
>> containing all of the object files from the current directory and
>> built-in.o files from directories below.
>>
>> With kernel modules, there are some special automatically generated C
>> files which also get linked in (IIRC that have a name like foo.mod.c)
>>
>> A kernel module is conceptually identical to a shared library (which
>> is also partially linked and may contain unresolved references).
>>
>> You can do incremental linking by doing:
>>
>> echo "int foo1(void) { return 1; }" > foo1.c
>> echo "int foo2(void) { return 2; }" > foo2.c
>> gcc -c foo1.c
>> gcc -c foo2.c
>> ld -r -o foo.o foo1.o foo2.o
>>
>> You'll now have foo.o which has both foo1.o and foo2.o partially
>> linked together, which you can see by using:
>>
>> nm foo.o
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel booting problem.
On Wed, Aug 29, 2012 at 10:06 PM, Sri Ram Vemulpali wrote: > Thanks for the replies again. > > This time the problem is in tty specification. > Kernel supports console=tty0 (virtual terminal), where as my inittab has > entry ::sysinit:/sbin/getty -L ttyS0 vt100. I have to change the ttyS0 to > tty0. > > Once I changed this, I got login prompt. > > But I do not understand how we tell kernel to use ttyS0 over tty0. > Because in kernel config I selected was ttyS0 but it is using tty0. try console on boot-line root@voyage:~# more /proc/cmdline root=LABEL=ROOT_FS console=ttyS0,115200n8 rootdelay=120 reboot=bios loglevel=8 dynamic_debug.verbose=1 > Weird? > > Thanks, > Sri. > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to understand the macro __init?
On Thu, Aug 16, 2012 at 12:39 PM, Amarnath Revanna wrote: > Just want to add a little more for better understanding: > > When I spoke about .init section of the final kernel image, please note that > this section is going to > contain all the __init data (and functions) coming from _All_ the drivers > and modules that were included > as part of the kernel image. Hence, after initialization when we look at the > print: > > " [1.011596] Freeing unused kernel memory: 664k freed " > > we see 664k bytes being freed. > > This is a significant amount of contiguous physical memory that we can see > being released by the kernel. > > The same cannot be held true for a single loadable module which may be > releasing just a few, virtually > contiguous memory. FWIW, theres no reason that the loadable module's __init section must be in the same allocation as the module code itself. The lifetime is certainly different, so "pre-fragmenting" it could leave fewer holes overall. I dont know if this is actually done (this way), but it seems reasonably likely, given that the per-module sections exist. $ readelf -a /lib/modules/3.6.0-rc3-cha-dyndbg-8-g6e433ac/kernel/drivers/usb/serial/pl2303.ko | grep init [ 4] .init.textPROGBITS 00197c 19 00 AX 0 0 1 [ 5] .rel.init.textREL 02a58c 20 08 44 4 4 1754 b702 R_386_PC32 __init_waitqueue_head Relocation section '.rel.init.text' at offset 0x2a58c contains 4 entries: ... > > Regards, > -Amar > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT
On Sun, Sep 27, 2015 at 8:52 AM, wrote:
> On Sun, 27 Sep 2015 15:08:57 +1300, vibnwis said:
>
> > Xenomai patching succeeded but when running one of is test apps,
> "latency"
> > showing
> > > > > > > > >> > 0"000.000| BUG in low_init(): [main] mlockall: Cannot
> > allocate
> > > > > > memory
> > And the mailing list member suggested the following
>
> Is that in dmesg, or output from the test program?
> Is there more output, or is that it?
>
> Personally, if TRACE_IRQFLAGS is causing an issue with mlock, I'd suspect
> a very buggy patch indeed. If it can't tolerate a trace function being
> turned on, there;s probably some very questionable coding in there.
>
>
FWIW, I think Xenomai is far better smelling than your quick sniff has told
your olfactory sensors
I first started using it (then called Adeos/ipipe also) shortly after
starting to build my own kernels,
I had it running on 2.4.27, on a i586mmx, before I had any clue how to hack
at linux.
If I could do it then, its not entirely difficult or crazy. Maybe I got a
little lucky,
maybe Id accumulated more experience by then than the OP.
main keepers are Phillipe Gerum, Gilles Chanterperdrix, Jan Kiska, they
have numerous patches in linux;
blackfin arch, canbus, arm iirc. I recognize Valdis' name too, I know my
only honest read on your talents is
`git log --oneline --author $_` for @names,
To me, youre all heavy hitters, and know WTH youre doing in the kernel.
Of course my impression is from almost a decade old, and mainline linux has
gotten huge RT improvements.
I know I never came close to proving I needed adeos/xenomai, so when the
extra steps got in the way,
I just stopped using it, and started actually hacking.
Back then, my notion was to get GPIO pins to emit a jitter free pulse train
to an RC servo.
I did get the GPIO written and accepted, but never got around to putting
interrupts into it
(I thought I might need that to read the pulse train coming from the radio,
using interrupts
to detect rising and falling edges while keep latency down, and polling
loops out)
Or the other things I didnt yet think of.
I still would like to get around to dragging nsc_gpio and scx200_gpio into
the gpiolib era.
I hope Im not forced to protest its removal and promise the upgrades before
my lazy-hobbyist-quality shipment of round-to-its arrive.
But I have to get a bootable image onto a CF for my soekris, havent tried
in years :-{
I never did grok what grub docs were telling me. I'll have to try lilo
next time.
I still think that reading and writing RC servo pulse trains out of a
generic kernel gpio hw/sw combo
is a reasonable technical goal, even though these days youd probably use a
panda/beagle/rpi board
to do it, iirc the rpi has some slick (arcane but flexible) counters/timers
that could modulate
a 0.5-3.5ms pulse in a 20ms period without much cpu load.
Anyway, I'll wrap up with a few connected (to me) points and questions.
if you, Valdis, take a careful look at xenomai, I think youll find it
better than you suggested,
and if you see anything wrong, I bet youd get a productive discussion.
With that in mind, I cc'd those guys.
I hope I can follow it, just a bit. It will be deep water for me.
(I also hope I didnt just do a gang tackle with all the ccs ;-)
do you think vanilla kernel and cheap-ass gpio hw can do an adequate job of
reading 2 channels of
cheap-ass RC servo signals from the RC reciever, and transcode them
(straight shot at 1st, then with kernel-modulation)
to 2 gpio outputs ? Its not the way one would do it, but it could still
be a useful model.
If so, is it a useful stake in the ground, a practical target for a
semi-skilled, not-yet-retired hobbyist ?
Whats the assemblage of modules that makes sense, and needed features of
them ?
If you want to get specific, talk about the scx200_* modules, I have a hope
of grokking them ;-)
at a high level, I thought Adeos was slick-as-snot thing, maybe a
micro-hypervisor (if such a notion makes sense)
only virtualizing the smallest surface for RT. The massive RT-kernel
improvements that have been integrated
over the last decade are in contrast sprinkled everywhere, by careful and
skilled magicians, very much a complementary approach. Using them together
and optimally is a high art (mixology?), and one that surely changes with
each new RT-kernel derived feature to hit mainline, as well as playing
poorly with other kernel hypervisors (OP did you do that ?)
feel free to rebrand this subject as you see fit, Im already WAY OT.
I hope it will be an illuminating thread, and one that gives me a coherent
picture of how to do it.
It will make starting easier, even (or especially) if it takes me 6 months
to do so.
jeez, Ive got work to do,
and reigniting an old hobby isnt it.
But obviously, the ghost of the itch is still there.
better get
missing /sys/class/drm/*
I just upgraded an old box to fedora 29 model name: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz when booted, none of these kernels has /sys/class/drm/* populated and all have trouble with graphical mode, I am causally linking these 2 facts, does that make sense? If so, it makes sense to file a bugzilla report, what else should it include ? lightdm/kde work the best, setting screen resolution at minimal VGA gdm fell over, never replaced the splash screen I built an rc3+ kernel, copied f29 config, make localmodconfig, It has /sys/class/drm/* and sets right resolution on boot. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
is there a macro symbol for strlen($LINUX_SOURCE_PATH)
in the kernel, there are a lot of usages of __FILE__ this means that there are a lot of copies of fully rooted paths, including all the varying ~/src/linux prefixes used by individual builders. Id hazard a guess that something like __RELPATH_FILE__ would work in many cases and perhaps even be more readable (by reducing long strings) in the generated output Do the macros exist to cobble this together for compile-time ? Does it warrant a short name ? either to wrap __FILE__ uses or replace them ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is there a macro symbol for strlen($LINUX_SOURCE_PATH)
On Wed, Sep 4, 2019 at 4:14 PM Varun Iyer wrote:
>
> On 19/09/04 03:42PM, jim.cro...@gmail.com wrote:
> > in the kernel, there are a lot of usages of __FILE__
> >
> > this means that there are a lot of copies of fully rooted paths,
> > including all the varying ~/src/linux prefixes used by individual builders.
>
> On gcc, `__FILE__` is the path of the file relative to the directory that the
> build is run from.
>
> Try something like
>
> #include
> #define testing() printf("%s\n", __FILE__)
> int main() { testing(); }
>
> and compile it from different directories to replicate this behaviour.
>
whoa. how long have I been out ?
per https://www.cprogramming.com/reference/preprocessor/__FILE__.html
__FILE__ is a preprocessor macro that expands to full path to the current file.
and thanks for that simple demo.
I shoulda done that myself, but I had no concept that such a change
might happen.
and its not the whole story.
when I rebuild from .. the __FILE__ value changes
[jimc@frodo play]$ make gcc/file.o
cc-c -o gcc/file.o gcc/file.c
[jimc@frodo play]$ make gcc/file
cc gcc/file.o -o gcc/file
[jimc@frodo play]$ gcc/file
gcc/file.c
so its build-path relative (which u pretty much said), but I doubt its
that simple either.
I presume it is also controllable / customizable using one or more
make variables or techniques.
linux/Makefile's $srctree variable looks to be involved
Perhaps this is (one more reason) why (shell-descent) recursive makes
are less than desirable ?
In any case I added a printk("__FILE__: %s\n", __FILE__)
to see for myself, and you are correct.
So I feel compelled to offer a fix for dynamic_debug, attached.
hopefully it explains adequately, I have some doubts..
maybe this should go to LKML now,
but I guess Id prefer to make my obvious thinkos less publicly.
Im happy to bikeshed the commit-msg or code.
From c7b8041928565786fc58fd20e80b278cc877bef4 Mon Sep 17 00:00:00 2001
From: Jim Cromie
Date: Thu, 5 Sep 2019 00:25:34 -0600
Subject: [PATCH 1/2] dynamic_debug: drop obsolete trim_prefix
Some time ago, __FILE__ on gcc kernel builds changed from a full path to
a source-root-relative path. Presumably this happened after
2b6783191da7 dynamic_debug: add trim_prefix() to provide source-root relative paths
That patch added trim_prefix() to improve readability by shortening
lines in control file, in vpr_info output, and to accept relative
filenames in ddebug_query(), improving ease of use.
At any rate, __FILE__ now yields source-root-relative names, so
trim_prefix() is worse than obsolete; it has code to skip common
prefixes where used (see above), which can hide bugs in adaptations
for 2 kinds of uses. Moreover, that code uses __FILE__ and was thus
unnaffected by the behavior change. Now it just obfuscates.
So remove fn, and 3 uses. The query case deserves a closer look.
Per Documentation/admin-guide/dynamic-debug-howto.rst:
file
The given string is compared against either the full pathname, the
src-root relative pathname, or the basename of the source file of
each callsite. Examples::
file svcsock.c
file kernel/freezer.c
file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
The 3rd use was the original form, and the least useful (except for
copy-paste of full-paths). It is not properly supported by current
code, as __FILE__ has already stripped ~/projects/linux.git/,
defeating the prefix-skip code on a "filename " search.
Since it already broken, lets just remove it. wildcard match added
since should help ease transition.
---
lib/dynamic_debug.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index c60409138e13..ba35199edd9c 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -67,17 +67,6 @@ static LIST_HEAD(ddebug_tables);
static int verbose;
module_param(verbose, int, 0644);
-/* Return the path relative to source root */
-static inline const char *trim_prefix(const char *path)
-{
- int skip = strlen(__FILE__) - strlen("lib/dynamic_debug.c");
-
- if (strncmp(path, __FILE__, skip))
- skip = 0; /* prefix mismatch, don't skip */
-
- return path + skip;
-}
-
static struct { unsigned flag:8; char opt_char; } opt_array[] = {
{ _DPRINTK_FLAGS_PRINT, 'p' },
{ _DPRINTK_FLAGS_INCL_MODNAME, 'm' },
@@ -162,9 +151,7 @@ static int ddebug_change(const struct ddebug_query *query,
if (query->filename &&
!match_wildcard(query->filename, dp->filename) &&
!match_wildcard(query->filename,
- kbasename(dp->filename)) &&
- !match_wildcard(query->filename,
- trim_prefix(dp->filename)))
+ kbasename(dp->filename)))
continue;
/* match against the function */
@@ -199,7 +186,7 @@ static int ddebug_change(const struct
sticky bits in /proc etc
Id like to ask about a possible new use for file and directory sticky bits, or setuid bits, to address the root-only use of /proc (etc) files this needs root echo module kvm +p > /proc/dynamic_debug/control how about this ? cat root-owned-readonly-file > /proc/dynamic_debug/control the root-owned-file can define a fixed set of dprintk enablements, and since its ro, its contents are controlled. is there some combination of special-bits on the source (ro root owned) and destination (root owned) that could safely allow joe-user to cat that file into control ? If it could fit here, it might then be a general workaround to root-shell access for /proc /sys manipulations ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: sticky bits in /proc etc
On Wed, Jun 10, 2020 at 9:37 PM Valdis Klētnieks wrote: > > On Wed, 10 Jun 2020 08:24:17 -0600, jim.cro...@gmail.com said: > > Id like to ask about a possible new use for file and directory sticky bits, > > or setuid bits, to address the root-only use of /proc (etc) files > > The sticky bit and setuid/gid bits already have meanings for directories, > and changing the semantics will break existing code. > ok, Id more or less expected this. the only escape might have been that those meanings pertain to a "real" FS, and might be irrelevant to a synthetic/virtual fs like /proc or /sys > > this needs root > > > > echo module kvm +p > /proc/dynamic_debug/control > > > > how about this ? > > > > cat root-owned-readonly-file > /proc/dynamic_debug/control > > Nope, doesn't work that way, because the file in /proc has no way to tell that > it's cat doing it from a root-owned file, versus cat doing it from a > hacker-owned file. As far as the /proc file is concerned, the "echo" and "cat" > commands are identical. > > If you have an actual need for non-root users to do this, there's always the > fact that 'sudo' can be restricted to specific commands for the user, and/or > the use of set-UID helper programs that validate the request and then issue it > on the user's behalf. > I have no actual need, more just wondering aloud. thanks Jim ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
replacing if-then-else strcmp ladders with switch cases
considering lib/dynamic_debug.c
we have
...
} else if (!strcmp(words[i], "module")) {
rc = check_set(&query->module, words[i+1], "module");
} else if (!strcmp(words[i], "format")) {
...
are there any built-in hash functions which would allow this ?
switch (keyword) {
case Hash("module"):
. break;
case Hash("format"):
break;
default: return -EINVAL
}
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: replacing if-then-else strcmp ladders with switch cases
On Fri, Jun 12, 2020 at 11:02 PM Valdis Klētnieks
wrote:
>
> On Fri, 12 Jun 2020 12:05:55 -0600, jim.cro...@gmail.com said:
> > considering lib/dynamic_debug.c
> > we have
> >
> > ...
> > } else if (!strcmp(words[i], "module")) {
> > rc = check_set(&query->module, words[i+1], "module");
> > } else if (!strcmp(words[i], "format")) {
> > ...
> >
> > are there any built-in hash functions which would allow this ?
> >
> > switch (keyword) {
> > case Hash("module"):
> > . break;
that should be:
/* 2 compatible implementations */
#define chash(keywd) simple_hash_computed_by_compiler ( keywd )
#define rhash(keywd) simple_hash_computed_at_runtime ( keywd )
switch ( rhash (keyword) ) {
case chash("module"):
... break;
> There's hash functions. But they're all cryptographic hashes that return
> things that are far too many bits to use as the index of a switch.
>
> Also, you have the problem that the cases of a switch have to be something
> that can be evaluated at compile time
ok, so they dont exist.
I suspect its doable, but needs big -fu, more than I got
that said, I could imagine a compile-time check to insure that
the simple-hash on a fixed dictionary yields no collision
DEFINE_DICTIONARY( "dyndbg.control.adverbs", "module", "file", "line", "func" )
but thats not essential, since if theyre in case:s,
the compiler would notice the collision,
and so chash() doesnt need to do collision detection either.
this would be slick, and I think usable more than once.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
modprobe rbtree-test nnodes=1000 gets soft lockup
hey fellow noobs/readers modprobe rbtree-test nnodes=1000 gets soft lockup timing seems semi-quadratic large sets seem to knock it over, I cut perf_loops in 1/10, expecting that to fix it, it didnt. does anyone else see this ? bash-5.0# modprobe rbtree_test [ 17.808044][ T233] rbtree testing [ 17.817992][ T233] -> test 1 (latency of nnodes insert+delete): 25770 cycles [ 17.829363][ T233] -> test 2 (latency of nnodes cached insert+delete): 25066 cycles [ 17.831705][ T233] -> test 3 (latency of inorder traversal): 2333 cycles [ 17.832994][ T233] -> test 4 (latency to fetch first node) [ 17.833931][ T233] non-cached: 21 cycles [ 17.834756][ T233] cached: 13 cycles [ 17.910160][ T233] augmented rbtree testing [ 17.931726][ T233] -> test 1 (latency of nnodes insert+delete): 55888 cycles [ 17.954803][ T233] -> test 2 (latency of nnodes cached insert+delete): 54948 cycles [ 18.052785][ T233] dynamic_debug:ddebug_remove_module: removing module "rbtree_test" modprobe: ERROR: could not insert 'rbtree_test': Resource temporarily unavailable bash-5.0# modprobe rbtree_test nnodes=500 [ 33.843314][ T235] rbtree testing [ 33.919317][ T235] -> test 1 (latency of nnodes insert+delete): 196957 cycles [ 34.002251][ T235] -> test 2 (latency of nnodes cached insert+delete): 209320 cycles [ 34.008807][ T235] -> test 3 (latency of inorder traversal): 12848 cycles [ 34.010039][ T235] -> test 4 (latency to fetch first node) [ 34.011065][ T235] non-cached: 24 cycles [ 34.011795][ T235] cached: 13 cycles [ 35.955906][ T235] augmented rbtree testing [ 36.099845][ T235] -> test 1 (latency of nnodes insert+delete): 373062 cycles [ 36.246031][ T235] -> test 2 (latency of nnodes cached insert+delete): 372324 cycles [ 38.821936][ T235] dynamic_debug:ddebug_remove_module: removing module "rbtree_test" modprobe: ERROR: could not insert 'rbtree_test': Resource temporarily unavailable bash-5.0# modprobe rbtree_test nnodes=1000 [ 46.987262][ T237] rbtree testing [ 47.157653][ T237] -> test 1 (latency of nnodes insert+delete): 441603 cycles [ 47.342749][ T237] -> test 2 (latency of nnodes cached insert+delete): 475413 cycles [ 47.355668][ T237] -> test 3 (latency of inorder traversal): 29168 cycles [ 47.356965][ T237] -> test 4 (latency to fetch first node) [ 47.357917][ T237] non-cached: 36 cycles [ 47.358638][ T237] cached: 13 cycles [ 55.581422][ T237] augmented rbtree testing [ 55.891384][ T237] -> test 1 (latency of nnodes insert+delete): 803375 cycles [ 56.200665][ T237] -> test 2 (latency of nnodes cached insert+delete): 796702 cycles [ 66.887909][ T237] dynamic_debug:ddebug_remove_module: removing module "rbtree_test" modprobe: ERROR: could not insert 'rbtree_test': Resource temporarily unavailable bash-5.0# modprobe rbtree_test nnodes=1500 [ 81.481918][ T239] rbtree testing [ 81.763810][ T239] -> test 1 (latency of nnodes insert+delete): 730506 cycles [ 82.066386][ T239] -> test 2 (latency of nnodes cached insert+delete): 778610 cycles [ 82.086648][ T239] -> test 3 (latency of inorder traversal): 48465 cycles [ 82.087706][ T239] -> test 4 (latency to fetch first node) [ 82.088728][ T239] non-cached: 61 cycles [ 82.089511][ T239] cached: 13 cycles [ 101.149656][ T239] augmented rbtree testing [ 101.622513][ T239] -> test 1 (latency of nnodes insert+delete): 1225584 cycles [ 102.112011][ T239] -> test 2 (latency of nnodes cached insert+delete): 1263990 cycles [ 127.491941][ T239] dynamic_debug:ddebug_remove_module: removing module "rbtree_test" modprobe: ERROR: could not insert 'rbtree_test': Resource temporarily unavailable bash-5.0# modprobe rbtree_test nnodes=2000 [ 147.626834][ T241] rbtree testing [ 148.032627][ T241] -> test 1 (latency of nnodes insert+delete): 1051510 cycles [ 148.439514][ T241] -> test 2 (latency of nnodes cached insert+delete): 1049853 cycles [ 148.465867][ T241] -> test 3 (latency of inorder traversal): 63728 cycles [ 148.466980][ T241] -> test 4 (latency to fetch first node) [ 148.468084][ T241] non-cached: 24 cycles [ 148.468941][ T241] cached: 13 cycles [ 172.494679][C0] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:241] [ 172.495922][C0] Modules linked in: rbtree_test(E+) crc32_pclmul(E) ghash_clmulni_intel(E) crct10dif_pclmul(E) crc32c_intel(E) serio_raw(E) [ 172.497859][C0] CPU: 0 PID: 241 Comm: modprobe Tainted: G E 5.8.0-rc3-00017-gcd430eec8fdf #190 [ 172.499592][C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 [ 172.501049][C0] RIP: 0010:__sanitizer_cov_trace_pc+0x30/0x60 [ 172.501937][C0] Code: 8b 14 25 40 7c 01 00 65 8b 05 7c ca d6 7e a9 00 01 ff 00 74 0f f6 c4 01 74 3c 8b 82 cc 19 00 00 85 c0 74 32 8b 82 a8 19 00 00 <83> f8 02 75 27 48 8b b2 b0 19 00 00 8b 92
[PATCH 1/3] dyndbg: WIP replace __dyndbg section with a zs-pool copy.
Consider the bloat in the __dyndbg linker section: 266 modules, 2542 entries and 10640 bytes in ddebug tables, 142352 bytes in __dyndbg section 2275 module repeats, 1045 func-repeats 2139 file-repeats The linker populates the __dyndbg section for us, limiting our ability to eliminate those repetitions structurally. So instead, lets copy the section into zram (maybe zswap later?), let a compressor handle the repetition, and map individual records in on-demand. Once the 3 users of struct _ddebug's members are converted to fetch the record from the zpool, we can retire the entire __dyndbg section. Since dynamic_debug is nice to have but rarely used, paying more for active logging to save in-kernel memory might be a worthwhile tradeoff. This is how: - At late_initcall time, ddebug_zpool_init() creates the zpool. This will likely play well with __initdata auto reclaim I tried postcore_initcall and others, got NULL ptrs, maybe revisit. - ddebug_add_module() now also calls ddebug_zpool_add() to copy the module's _ddebug records into the zpool, once its available. - ddebug_zpool_init() inits the zpool, and also calls ddebug_zpool_add() on behalf of all the builtin modules which couldnt be added to the pool because itit wasnt ready. - add zhandle into struct _ddebug. via 2 anonymous structs. white-space abusing, todo. outer struct needs to be a union to save any ram. The 3 struct _ddebug users; ddebug_proc_show(), dynamic_emit_prefix(), and ddebug_change(), are updated to use 2 new helpers: - ddebug_zrec_get(handle) - map the record in - ddebug_zrec_put(handle) - unmap ddebug_change() also gets s/continue/goto skipsite/g to cleanly unmap the record. Or I could abuse the forloop, this is better. ATM, the code works, at least enough to try some more design. It does not get any actual compression, and is just bigger right now. Next steps: s1- convert struct to union. this is close, has broken so far.. This is complicated by the need for the union to function properly for both early and post-late demands. So we also need a flag-bit of a sort to decide what kind of record is stored so we can use it (more cleverly than current zhandle checks). I briefly tried +1,-1 on zhandle to make it %2-odd, which things then, time to re-try. s2- split struct _ddebug, separate out flags and keys. We must split out at least flags, because non-JUMP_LABEL builds must check the 'p' flag for every callsite encountered (no NOOP-patchsite), so flags cannot be that expensive to access, ie not in zram. It would probably look a bit like: DYNAMIC_DEBUG_METADATA( .. ) static struct _dd_callsite __section(__dyndbg_callsite) name##_calls .. static struct _dd_flags __section(__dyndbg_flags)name##_flags .. static struct _dd_keys __section(__dyndbg_keys) name##_keys .. // composing struct _ddebug static struct _dd __section(__dyndbg) name .calls = &name##_calls .keys = &name##_keys .flags = &name##_flags Once we have this, the __dyndbg_callsite section can go to zram, and will perhaps be more readily compressible. (we get none atm). JUMP_LABEL builds will use keys only when changing 'p' flag and hot-patching that callsite; since this is rare, the keys could go into zram. non-JUMP builds won't use keys at all. s3- linker question The DYNAMIC_DEBUG_METADATA macro outlined above would fill 4 sections simultaneously. If we can rely on the linker to keep those sections in the same order, we can "invert" the struct _ddebug vector into separate vectors of members, each indexed by [N], and that "composing struct _ddebug" above can be dropped, fixing the space-cost, and leaving only the indexing costs. OTOH, I saw a CONFIG item recently that helped to prevent cross-section linkages, so theres some intereference possible. s4- fix the lack of compression Since the __dyndbg section is well sorted, a simple run-length encoding on 3 RO members (modname, file, function) could reclaim most of the (90%, 84%, 45%) repeated values. But this sounds like premature optimization, at least until standard compression is shown incapable. Also, the s2- split might fix the problem, by only applying compression to the callsite data. OTOH, pushing the current zpool (50 pages) out to swap makes non-compression arguably moot. Potential benefits: - compression - convert in-kernel mem to zram/etc - eventually swap it out entirely - map in the enabled callsites only TLDR Note also that the format pointer is kept 2x in dynamic-debug; once inside the struct _ddebug, and again as the fmt parameter in the *_dbg() functions and macro stack. I dont see how 'fixing' this is worthwhile. Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 4 ++ lib/dynamic_debug.c | 131 +++--- 2 files changed, 126 insertions(+
[PATCH 0/3] dyndbg: WIP semi-viable diet plan ?
dynamic-debug metadata is bloated; the __dyndbg linker section, filled by DYNAMIC_DEBUG_METADATA, has 3 fields with 90%, 84%, 45% repeated values, consuming ~150kb on my laptop. Instead of an arduous restructuring of the data, lets stuff it into zram, get whatever compression it gives us for free, and be able to map and unmap individual records on demand. Once map/unmap suffices for internal needs, the whole __dyndbg section can be reclaimed. >From this, it seems practical to push it into zswap, and then to keep active/enabled callsites mapped into ram, like a cache. But thats a lot of stuff I can only handwave about. Please fill in details or call BS. This patchset makes a decent start down that path, but theres a boatload of chatter in the commit-logs about options and maybes, and brave projections about whats possible. Blah Blah. Theres almost certainly some subtle/ornot thinkos. Please point them out. I probably have some terminology cleanup to do too. I punted with lazy names a lot & welcome better ones some // comments too - not for submission I'll try to summarize here. - The easiest thing is to stuff whole struct _ddebug contents, into an anonymous struct, along with a new zhandle, into a new zpool. This is done in patch 1. this defers the unionization, so it just enlarges the ram footprint. - patch 2 attempts to distinguish zhandles from pointers, by making zhandles odd, and testing with %2. This works fine before unionization, falls over afterwards. - The unionization is in patch 3, and it works, at least casually. The fix-on-2 is to add an explicit flag; is_zhandle, and drop the %2 test, which fails when it encounters an odd pointer in the __dyndbg section. the structs/unions must be reworked to actually save any ram - for non-JUMP_LABEL builds, putting whole struct _ddebug into zram is problematic; it means pulling out whole record just to check the am-i-printing flag, a horrible cost. - pulling flags into a separate flags vector would solve that, and would be 'tight' on ram; no paholes, good grouping of flags for callsites enabled with module=foo function=bar file=buz etc. But it creates new ones Im stuck on. - an 'opaque' descriptor might be the magic needed, but Im pretty clueless on how to proceed. Anyone got any pointers to good examples in the tree ? This patchset is on top of other dyndbg patches, which are now in gregkh's char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. Jim Cromie (3): dyndbg: WIP replace __dyndbg section with a zs-pool copy. dyndbg: zhandle+1 plus info tweaks, BUG_ONs dyndbg: fixup/correct assumptions re ptr-vals include/linux/dynamic_debug.h | 9 ++ lib/dynamic_debug.c | 172 -- 2 files changed, 171 insertions(+), 10 deletions(-) -- 2.26.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 3/3] dyndbg: fixup/correct assumptions re ptr-vals
The is_odd(dp->zhandle) property is apparently reliable;
BUG_ONs in HEAD~1 demonstrate it.
But is_odd(dp->modname) is also sometimes true, at least when it
points into the __dyndbg section, which has been packed by the linker.
This means the (dp->zhandle % 2) test couldnt distinguish between the
2 values shared in the union. Happily, it blew up, challenging
assumptions. 'gdb> p *dp' confirmed the odd pointer.
Breakpoint 1, dynamic_emit_prefix (dp=0x8276e190
<__UNIQUE_ID_ddebug429.11>,
buf=0xc9013d48 "߇]\201\377\377\377\377") at
../lib/dynamic_debug.c:598
598 *buf = '\0';
1: dp = (struct _ddebug *) 0x8276e190 <__UNIQUE_ID_ddebug429.11>
2: *dp = {{is_zhandle = 0, {zhandle = 18446744071599650201, {modname =
0x823d7599 "intel_idle",
function = 0x820d8b20 <__func__.7> "intel_idle_init",
filename = 0x823d75a4 "drivers/idle/intel_idle.c",
format = 0x823d74e8 "Please enable MWAIT in BIOS SETUP\n",
lineno = 1609, flags = 1, key = {
dd_key_true = {key = {enabled = {counter = 1}, {type =
18446744071600203817,
entries = 0x8245e829, next = 0x8245e829}}},
dd_key_false = {key = {enabled = {
counter = 1}, {type = 18446744071600203817, entries =
0x8245e829,
next = 0x8245e829
So instead, add an explicit flag-int: is_zhandle, to remember when the
union is changed to zhandle.
Again, we abuse indenting to minimize whitespace, and add an anonymous
outer struct to contain is_zhandle, and previous contents.
Maybe this flag can be hidden somewhere else; splitting struct _ddebug
into parts is still needed (flags cant be in zram for non-JUMP_LABEL
builds), so maybe it ends up there.
Or perhaps the linker can be convinced to be slightly less
parsimonious with the ram, making this is_odd() test viable.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 5 +
lib/dynamic_debug.c | 17 ++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index d23f283fff70..345e86e23bb9 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -13,6 +13,10 @@
*/
struct _ddebug {
struct {
+ int is_zhandle;
+ //
+ union {
+ //struct {
long unsigned int zhandle;
struct {
/*
@@ -48,6 +52,7 @@ struct _ddebug {
} key;
#endif
};}; // struct union
+ }; // struct
} __attribute__((aligned(8)));
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 96252ffacb77..6e93b19bf141 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -602,13 +602,22 @@ static char *dynamic_emit_prefix( struct _ddebug *dp,
char *buf)
if (!dp->zhandle) {
/* without union, happens until late-init */
pr_err("nul zhandle: %s.%s\n", dp->modname, dp->function);
- } else if (dp->zhandle % 2) {
+ }
+ else if (dp->is_zhandle) {
+ pr_err("is-zhandle:%d zhandle.mod2:%d\n", dp->is_zhandle,
(int)dp->zhandle % 2);
+ v3pr_info("get zhandle: %s.%s\n", dp->modname, dp->function);
+ desc = ddebug_zrec_get(dp->zhandle);
+ v3pr_info("got zhandle: %s.%s\n", desc->modname,
desc->function);
+ }
+ else if (dp->zhandle % 2) {
+ pr_err("odd zhandle get %lu %p\n", dp->zhandle,
(void*)dp->zhandle);
/* normal ops, after zpool filled
zhandle is odd to distinguish from pointer
- */
+
desc = ddebug_zrec_get(dp->zhandle);
v3pr_info("get zhandle: %s.%s\n",
desc->modname, desc->function);
+ */
} else
/* with union, happens until late-init */
pr_err("some transitional state: %s.%s %lu\n",
@@ -639,7 +648,7 @@ static char *dynamic_emit_prefix( struct _ddebug *dp, char
*buf)
if (!dp->zhandle) {
pr_err("Nul zhandle: %s.%s\n", desc->modname, desc->function);
- } else if (dp->zhandle % 2) {
+ } else if (dp->is_zhandle) {
v2pr_info("put zhandle: %s.%s\n", desc->modname,
desc->function);
ddebug_zrec_put(dp->zhandle);
}
@@ -1014,6 +1023,8 @@ static void ddebug_zpool_add(struct _ddebug *dp)
*/
dp->zhandle = handle + 1;
+ dp->is_zhandle = 1; /* sanity check on everything else */
+
cursor = (struct _ddebug *)
zs_map_object(dd_callsite_zpool, handle, ZS_MM_WO);
--
2.26.2
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 2/3] dyndbg: zhandle+1 plus info tweaks, BUG_ONs
In preparation for union between zhandle and callsite, add a +1 offset
to zhandle as its created & stored, and a corresponding -1 in the
get/put helper funcs which access it.
With the +1, the value cannot work as a pointer, so we'll get early
detonation if the union goes poorly. This relys on the 'fact' uhm
observation that zhandles were always even numbered. So far so good.
Also add BUG-ONs to track/assert invariants into ddebug_zpool_init
and the get/put inline helpers, and several debug prints.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 72 +++--
1 file changed, 50 insertions(+), 22 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index bb23d5d56116..96252ffacb77 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -145,13 +145,15 @@ static void vpr_info_dq(const struct ddebug_query *query,
const char *msg)
static inline struct _ddebug* ddebug_zrec_get(long unsigned int handle)
{
+ BUG_ON(!(handle % 2)); /* distinct from pointer */
return (struct _ddebug*)
- zs_map_object(dd_callsite_zpool, handle, ZS_MM_RW);
+ zs_map_object(dd_callsite_zpool, handle - 1, ZS_MM_RW);
}
static inline void ddebug_zrec_put(long unsigned int handle)
{
- zs_unmap_object(dd_callsite_zpool, handle);
+ BUG_ON(!(handle % 2)); /* distinct from pointer */
+ zs_unmap_object(dd_callsite_zpool, handle - 1);
}
/*
@@ -587,22 +589,31 @@ static int remaining(int wrote)
return 0;
}
-static char *dynamic_emit_prefix(const struct _ddebug *dp, char *buf)
+static char *dynamic_emit_prefix( struct _ddebug *dp, char *buf)
{
int pos_after_tid;
int pos = 0;
- struct _ddebug *desc;
+ struct _ddebug *desc = dp; /* updated if zhandle */
*buf = '\0';
+ BUG_ON(dp->zhandle == 1);
+
if (!dp->zhandle) {
- pr_err("Nul zhandle: %s.%s\n", dp->modname, dp->function);
- desc = dp;
- } else {
+ /* without union, happens until late-init */
+ pr_err("nul zhandle: %s.%s\n", dp->modname, dp->function);
+ } else if (dp->zhandle % 2) {
+ /* normal ops, after zpool filled
+ zhandle is odd to distinguish from pointer
+ */
desc = ddebug_zrec_get(dp->zhandle);
- v3pr_info("good zhandle: %s.%s\n",
+ v3pr_info("get zhandle: %s.%s\n",
desc->modname, desc->function);
- }
+ } else
+ /* with union, happens until late-init */
+ pr_err("some transitional state: %s.%s %lu\n",
+ desc->modname, desc->function, dp->zhandle);
+
if (desc->flags & _DPRINTK_FLAGS_INCL_TID) {
if (in_interrupt())
@@ -627,9 +638,9 @@ static char *dynamic_emit_prefix(const struct _ddebug *dp,
char *buf)
buf[PREFIX_SIZE - 1] = '\0';
if (!dp->zhandle) {
- pr_err("Nul zhandle\n");
- } else {
- v3pr_info("got zhandle\n");
+ pr_err("Nul zhandle: %s.%s\n", desc->modname, desc->function);
+ } else if (dp->zhandle % 2) {
+ v2pr_info("put zhandle: %s.%s\n", desc->modname,
desc->function);
ddebug_zrec_put(dp->zhandle);
}
@@ -898,7 +909,6 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
struct ddebug_iter *iter = m->private;
struct _ddebug *dp = p;
struct flagsbuf flags;
- long unsigned int handle;
if (p == SEQ_START_TOKEN) {
seq_puts(m,
@@ -906,16 +916,19 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
return 0;
}
- BUG_ON(!dp->zhandle);
- handle = dp->zhandle;
+ BUG_ON(!dp->zhandle); /* must be set by now */
- dp = ddebug_zrec_get(handle);
+ if (dp->zhandle == 1)
+ vpr_info("dp:%p mapping ?? h:%lu %s.%s\n", dp, dp->zhandle,
+iter->table->mod_name, dp->function);
+
+ dp = ddebug_zrec_get(dp->zhandle);
if (!dp) {
- pr_err("zs-map failed on %lu\n", handle);
+ pr_err("zs-map failed on %lu\n", dp->zhandle);
return 0; // bail
}
- v3pr_info("mapped h:%lu %s\n", handle, dp->function);
+ v3pr_info("mapped h:%lu %s\n", dp->zhandle, dp->function);
seq_printf(m, "%s:%u [%s]%s =%s \"",
trim_prefix(dp->filename), dp->lineno,
@@ -924,7 +937,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
CONFIG_KDB_KEYBOARD
.config - Linux/x86 5.8.0-rc7 Kernel Configuration > Kernel hacking > Generic Kernel Debugging Instruments > KGDB: kernel debugger KGDB_KDB: keyboard as input device \ │ CONFIG_KDB_KEYBOARD: │ KDB can use a PS/2 type keyboard for an input device │ I notice this excludes USB keyboard. does this mean it doesnt work early enough to be useful for early panics etc ? what does it mean for a panic right after starting 2nd CPUs ? [0.402982] smp: Bringing up secondary CPUs ... [0.403553] smp: Brought up 1 node, 1 CPU [0.404226] smpboot: Max logical packages: 1 [0.404552] smpboot: Total of 1 processors activated (5184.01 BogoMIPS) [0.406816] devtmpfs: initialized [0.408058] x86/mm: Memory block size: 128MB [0.416908] kthreadd invoked oom-killer: gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), order=0, oom_score_adj=0 [0.417551] CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.8.0-rc7-00023-gede6954dc460-dirty #101 [0.418541] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 [0.418541] Call Trace: [0.418541] dump_stack+0x91/0xc8 [0.418541] dump_header+0x105/0x710 [0.418541] out_of_memory+0x63a/0x760 [0.418541] ? get_page_from_freelist+0x10b/0x950 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: CONFIG_KDB_KEYBOARD
On Mon, Aug 3, 2020 at 11:48 AM Valdis Klētnieks wrote: > > On Mon, 03 Aug 2020 11:30:05 -0600, jim.cro...@gmail.com said: > > > I notice this excludes USB keyboard. > > > > does this mean it doesnt work early enough to be useful for early panics > > etc? > > Very early panics and hangs are always a royal pain to deal with. There's no > really good way to deal with it, because let's face it - if the operating > system hasn't gotten its act together yet, it's going to have a hard time > talking to you unless you can run it in a virtual machine or similar that has > the tooling to allow you to usefully explore the memory entrails. > > > what does it mean for a panic right after starting 2nd CPUs ? > > > [0.416908] kthreadd invoked oom-killer: > > gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GF > > gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), order=0, > > oom_score_adj=0 > > [0.417551] CPU: 0 PID: 2 Comm: kthreadd Not tainted > > 5.8.0-rc7-00023-gede6954dc460-dirty #101 > > [0.418541] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > 1.13.0-2.fc32 04/01/2014 > > Hitting the OOM killer on PID 2 in QEMU sounds suspiciously like you started > QEMU and specified an insanely small memory space for the image. > Ok, I will look for the relevant docs. FWIW, Im using virtme, in case youre familiar with it. it is using QEMU/KVM, virtme is my 1st foray into this kernel magic. If you see the relevant setting, please shout out. [jimc@frodo build-v2]$ krun -q=-s -q=-S ./.virtme_mods/lib/modules/0.0.0 /usr/bin/qemu-system-x86_64 -fsdev local,id=virtfs1,path=/,security_model=none,readonly -device virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -fsdev local,id=virtfs5,path=/usr/lib/python3.8/site-packages/virtme/guest,security_model=none,readonly -device virtio-9p-pci,fsdev=virtfs5,mount_tag=virtme.guesttools -machine accel=kvm:tcg -watchdog i6300esb -cpu host -parallel none -net none -echr 1 -serial none -chardev stdio,id=console,signal=off,mux=on -serial chardev:console -mon chardev=console -vga none -display none -kernel ./arch/x86/boot/bzImage -append 'virtme_link_mods=/home/jimc/projects/lx/linux.git/build-v2/.virtme_mods/lib/modules/0.0.0 earlyprintk=serial,ttyS0,115200 console=ttyS0 psmouse.proto=exps "virtme_stty_con=rows 26 cols 113 iutf8" TERM=xterm-256color rootfstype=9p rootflags=version=9p2000.L,trans=virtio,access=any raid=noautodetect ro nokaslr dynamic_debug.verbose=3 module.dyndbg=+pm init=/bin/sh -- -c "mount -t tmpfs run /run;mkdir -p /run/virtme/guesttools;/bin/mount -n -t 9p -o ro,version=9p2000.L,trans=virtio,access=any virtme.guesttools /run/virtme/guesttools;exec /run/virtme/guesttools/virtme-init"' -s -S Wrong EFI loader signature. early console in extract_kernel input_data: 0x027f33a8 input_len: 0x009eed25 output: 0x0100 output_len: 0x021afbb4 kernel_total_size: 0x01e2c000 needed_size: 0x0220 trampoline_32bit: 0x0009d000 KASLR disabled: 'nokaslr' on cmdline. Decompressing Linux... Parsing ELF... No relocation needed... done. Booting the kernel. [0.00] Linux version 5.8.0-rc7-00024-gb86020ac9dfd (jimc@frodo) (gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1), GNU ld version 2.34-4.fc32) #21 SMP Mon Aug 3 13:35:05 MDT 2020 [0.00] Command line: virtme_link_mods=/home/jimc/projects/lx/linux.git/build-v2/.virtme_mods/lib/modules/0.0.0 earlyprintk=serial,ttyS0,115200 console=ttyS0 psmouse.proto=exps "virtme_stty_con=rows 26 cols 113 iutf8" TERM=xterm-256color rootfstype=9p rootflags=version=9p2000.L,trans=virtio,access=any raid=noautodetect ro nokaslr dynamic_debug.verbose=3 module.dyndbg=+pm init=/bin/sh -- -c "mount -t tmpfs run /run;mkdir -p /run/virtme/guesttools;/bin/mount -n -t 9p -o ro,version=9p2000.L,trans=virtio,access=any virtme.guesttools /run/virtme/guesttools;exec /run/virtme/guesttools/virtme-init" [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' ... btw, Id be happy to post the code here, hopefully fix it with advice/help, and eventually submit it. so thanks in advance ;-) Jim ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 5/8] dyndbg: WIP replace __dyndbg_callsite section with a zs-pool copy.
HEAD~1 split struct _ddebugs into heads & bodies, linked accross 2 ELF
sections. Lets now store copies of the bodies into a zs_pool, and
relink head to the new body. This should allow recycling the section
soon.
The strategy is to let a compression algo handle the repetition, and
map individual records in when needed. If that works, we only need
one record at a time, so the 3:1 zram compression applys to 99.9% of
callsites, ie to 98120 bytes below:
dyndbg: 259 modules, 2453 entries and 10360 bytes in ddebug tables, 98120
bytes in __dyndbg section, 98120 bytes in __dyndbg_callsites section
dyndbg: 2453 entries. repeated entries: 2193 module 2058 file 981 func
Since dynamic_debug is nice to have but rarely used, paying more for
active logging to save in-kernel memory might be a worthwhile tradeoff.
This is how:
ddebug_zpool_init(), at late_initcall time, creates the zpool.
Existing ddebug_add_module() now also calls ddebug_zpool_add(), which
copies the module's _ddebug records into the zpool, once it is ready.
For builtins, added early, the pool is not ready yet.
So ddebug_zpool_init() also calls ddebug_zpool_add() for all those
builtin modules already _add()ed.
ddebug_zpool_add() does, foreach _ddebug:
- zs_mallocs and saves to .zhandle,
- zs_maps and saves .site to it
- zs_unmaps it, triggering write to zram
- .site=0, detaching __dyndbg_callsites[item]
which later triggers zs_map
So we leave late-init with a full zram copy,
and __dyndbg_callsites ready to reclaim.
run-time access for 3 existing users is entirely via helpers;
ddebug_callsite_get(), ddebug_callsite_put(). These 3 uses are all
with ddebug_lock held.
_get() returns .site 1st, or maps zrec to it and returns it.
_put() always unmaps, minimizing online ram (see 1 below)
ddebug_change() also gets s/continue/goto skipsite/g to cleanly unmap
the record at the bottom of the loop.
Next steps:
1. dont always unmap in _put(), leave enabled pr_debugs mapped.
This would make the set of zs_mapped recs work like a cache, reducing
zs_mappings to a trickle, and only for <>control.
2. adapt struct _ddebug to unionize .site and .zhandle
We currently use !!.site and !!.zhandle tests to keep state, we have
bits available in flags to replace these tests, making union possible.
A crazy alt is to create a "restricted" zpool, which limits pool size
to 2**N handles, and returned handles to an (N+ck)-bit number, which
would fit beside our 8-bit flags, inside an 8-byte pointer. This
would be cool, but isnt necessary, since union looks practical.
3. move key from struct _ddebug into _ddebug_callsite
key doesnt exactly fit semantically (and its not RO), but its use is
super rare, and is never needed without also needing all the other
callsite data. Getting it out of head saves on-line ram. But it
broke in HEAD~1 when I tried it, with asm goto errors.
4. linker question
DECLARE_DYNAMIC_DEBUG_METADATA macro fills 2 sections simultaneously.
If we can rely on the linker to keep those records in identical order,
we can 'index' both _dyndbg & _callsites (& keys) with [N-opaque] and
drop the .site pointer.
5. improve compression ?
Im seeing 3:1 pages_per_zspage:
# cut -c1-12,40-77,85-90 $SKD/zsmalloc/dyndbg_callsites/classes | head -n3
class sizebj_allocated obj_used pages_used pagzspage
032 0 0 0 1
1482816 2605 33 3
Since the __dyndbg_callsite section is well sorted, a simple
run-length encoding on 3 RO members (modname, file, function) could
reclaim most of the (90%, 84%, 45%) repeated values. That said, a
standard compressor should be able to compete, and there are several
to try.
Lastly, this whole zram block is RO after late-init (maybe, if we
split into 2 zpools, for builtins and loadable modules). So
compression can be biased towards costly but excellent compression
(esp for RO zpool) and good small block decompression for random-ish
access.
6. we could add a ram_reclaim(), to walk the dt-list, check each
_ddebug, and unmap the mapped ones. This presumes 1. is done, and
there are sometimes memory pressures to respond to.
Potential benefits:
- convert in-kernel mem to zram/etc
- zram compression
- eventually swap it out entirely
- map in the enabled callsites only
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 1 +
lib/dynamic_debug.c | 140 +++---
2 files changed, 129 insertions(+), 12 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 1bf52952df69..693911920a32 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -29,6 +29,7 @@ struct _ddebug_callsite {
struct _ddebug {
struct _ddebug_callsite *site;
+ long unsigned int zhandle;
/*
* The flags field controls the behaviour at the callsite.
diff --git a/lib/dynamic_debug
[PATCH 0/8] dyndbg: WIP diet plan
dynamic-debug metadata is bloated; the __dyndbg linker section is effectively an array of struct _ddebugs, its 1st 3 members are highly repetetive, with 90%, 84%, 45% repeats. Total reported usage ~150kb for ~2600 callsites on my laptop config. This patchset is one diet plan. it all holds together nicely until the "cache" commit, when it blows up starting init (or right after freeing unused kernel image, which Im hoping to do...). The following commit tweaks locking in an attempt to recover, but fails. [0.737936] Freeing unused kernel image (initmem) memory: 1196K [0.740173] Write protecting the kernel read-only data: 22528k [0.743555] Freeing unused kernel image (text/rodata gap) memory: 2040K [0.744984] Freeing unused kernel image (rodata/data gap) memory: 256K [0.75] Run /bin/sh as init process q[1.029548] Kernel panic - not syncing: Requested init /bin/sh failed (error -14). [1.034582] CPU: 0 PID: 1 Comm: sh Not tainted 5.8.0-00026-g9a06159192d6 #14 [1.036068] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 [1.037885] Call Trace: [1.038444] dump_stack+0x5e/0x7a [1.039172] ? memcpy_orig+0x100/0x10f [1.039917] panic+0xf6/0x2b7 [1.040573] ? rest_init+0xa0/0xa0 [1.041314] kernel_init+0xaa/0x100 [1.041956] ret_from_fork+0x22/0x30 [1.042668] Kernel Offset: disabled [1.043216] ---[ end Kernel panic - not syncing: Requested init /bin/sh failed (error -14). ]--- QEMU 4.2.1 monitor - type 'help' for more information (qemu) q Im sending to kernelnewbies 1st, to see if theres any low-speed test-crashes I can get post-mortems of, before I take it to the races. Id appreciate any reviews, tests, or opinions you all might offer (in that order). I built for and tested on a virtme instance, 4/5 configs build and test sane as described, the 5th is probly dead from too many hacks. if you use git, and wanna just try it, you can find it here: git remote add .. # u dont need full clone https://github.com/jimc/linux.git dyndbg-diet branch I had good success with virtme, -q=-s -q=-S, and gdb target remote, all newbies should try it. These are on top of 5.8.0 +18 others, which GregKH added to his char-misc-testing &next trees. Jim Cromie (8): dyndbg: give %3u width in pr-format, cosmetic only dyndbg: motivate a diet plan dyndbg: select ZPOOL in Kconfig.debug dyndbg: split struct _ddebug in 2, creating _ddebug_callsite dyndbg: WIP replace __dyndbg_callsite section with a zs-pool copy. dyndbg: ddebug_zpool_remove dyndbg: enable 'cache' of active pr_debug callsites dyndbg: add locking around zpool-add loop in zpool-init include/asm-generic/vmlinux.lds.h | 4 + include/linux/dynamic_debug.h | 39 -- lib/Kconfig.debug | 1 + lib/dynamic_debug.c | 223 +- 4 files changed, 223 insertions(+), 44 deletions(-) -- 2.26.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 6/8] dyndbg: ddebug_zpool_remove
add ddebug_zpool_remove() to undo ddebug_zpool_add(), and call it from
ddebug_remove_module().
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 049299027fb3..102f47b2a439 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1007,6 +1007,18 @@ static void ddebug_zpool_add(struct _ddebug *dp)
zs_unmap_object(dd_callsite_zpool, handle);
}
+static void ddebug_zpool_remove(struct _ddebug *dp)
+{
+ if (dp->site) {
+ pr_warn("zhandle shouldnt be mapped now\n");
+ zs_unmap_object(dd_callsite_zpool, dp->zhandle);
+ }
+ if (!dp->zhandle)
+ pr_err("zhandle already cleared !\n");
+ else
+ zs_free(dd_callsite_zpool, dp->zhandle);
+}
+
/*
* Allocate a new ddebug_table for the given module
* and add it to the global list.
@@ -1104,6 +1116,13 @@ int ddebug_remove_module(const char *mod_name)
mutex_lock(&ddebug_lock);
list_for_each_entry_safe(dt, nextdt, &ddebug_tables, link) {
if (dt->mod_name == mod_name) {
+
+ unsigned int n = dt->num_ddebugs;
+ struct _ddebug *dp = dt->ddebugs;
+
+ for (; n; n--, dp++)
+ ddebug_zpool_remove(dp);
+
ddebug_table_free(dt);
ret = 0;
break;
--
2.26.2
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 1/8] dyndbg: give %3u width in pr-format, cosmetic only
Specify the print-width so log entries line up nicely.
no functional changes.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 1d012e597cc3..01b7d0210412 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -947,7 +947,7 @@ int ddebug_add_module(struct _ddebug *tab, unsigned int n,
list_add(&dt->link, &ddebug_tables);
mutex_unlock(&ddebug_lock);
- v2pr_info("%u debug prints in module %s\n", n, dt->mod_name);
+ v2pr_info("%3u debug prints in module %s\n", n, dt->mod_name);
return 0;
}
--
2.26.2
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 8/8] dyndbg: add locking around zpool-add loop in zpool-init
summary: no fix here.
Locking review:
ddebug_zpool_init(), like other *_init() routines, does not run under
a lock (that we control). Unlike them, it runs later, at late_init.
I dont know whether this is pertinent to the kernel panic.
ddebug_callsite_get/put() are called as a pair under mutex-lock for
all 3 callsite users; dynamic_emit_prefix() does its own ABBA-ish LGPU
(Lock-Get-Put-Unlock), as does ddebug_change().
ddebug_proc_show() does GP, ddebug_proc_start|stop() wrap it with LU.
ddebug_add_module() does LU to protect list_add(), HEAD~x added
ddebug_zpool_add() inside that protection.
This commit adds locking to ddebug_zpool_init(), around the loop of
ddebug_zpool_add(), to match the locking in ddebug_add_module().
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 9c51f24a9c66..716231a98910 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1187,8 +1187,10 @@ static void __init ddebug_zpool_init(void)
}
/* add-module normally does this, but not in time for builtins */
+ mutex_lock(&ddebug_lock);
for (iter = __start___dyndbg; iter < __stop___dyndbg; iter++)
ddebug_zpool_add(iter);
+ mutex_unlock(&ddebug_lock);
v2pr_info("total pages: %lu compaction: %lu\n",
zs_get_total_pages(dd_callsite_zpool),
@@ -1285,4 +1287,3 @@ early_initcall(dynamic_debug_init);
/* Debugfs setup must be done later */
fs_initcall(dynamic_debug_init_control);
-
--
2.26.2
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 2/8] dyndbg: motivate a diet plan
this throwaway patch demonstrates the extra weight:
dyndbg: 2605 entries. repeated entries: 2369 module 2231 file 1147 func
Thats (91%, 86%, 44%) repeated values in those pointers/columns.
This simple test also shows that a similarly simple run-length encoder
on those 3 columns would compress this table dramatically.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 01b7d0210412..691e79826fc2 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1059,11 +1059,12 @@ static int __init dynamic_debug_init_control(void)
static int __init dynamic_debug_init(void)
{
- struct _ddebug *iter, *iter_start;
+ struct _ddebug *iter, *iter_start, *prev = 0;
const char *modname = NULL;
char *cmdline;
int ret = 0;
int n = 0, entries = 0, modct = 0;
+ int modreps = 0, funcreps = 0, filereps = 0;
if (&__start___dyndbg == &__stop___dyndbg) {
if (IS_ENABLED(CONFIG_DYNAMIC_DEBUG)) {
@@ -1077,7 +1078,16 @@ static int __init dynamic_debug_init(void)
iter = __start___dyndbg;
modname = iter->modname;
iter_start = iter;
- for (; iter < __stop___dyndbg; iter++) {
+ for (prev = iter; iter < __stop___dyndbg; iter++) {
+ if (entries) {
+ if (prev->site->modname == iter->site->modname)
+ modreps++;
+ if (prev->site->function == iter->site->function)
+ funcreps++;
+ if (prev->site->filename == iter->site->filename)
+ filereps++;
+ prev++; /* one behind iter */
+ }
entries++;
if (strcmp(modname, iter->modname)) {
modct++;
@@ -1099,6 +1109,9 @@ static int __init dynamic_debug_init(void)
modct, entries, (int)(modct * sizeof(struct ddebug_table)),
(int)(entries * sizeof(struct _ddebug)));
+ vpr_info("%d entries. repeated entries: %d module %d file %d func\n",
+entries, modreps, filereps, funcreps);
+
/* apply ddebug_query boot param, dont unload tables on err */
if (ddebug_setup_string[0] != '\0') {
pr_warn("ddebug_query param name is deprecated, change it to
dyndbg\n");
--
2.26.2
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 3/8] dyndbg: select ZPOOL in Kconfig.debug
dyndbg will next need zs_malloc and friends, so add config reqs now, to avoid touching make-deps late in a patch-set. I used select in order not to hide dyndbg inadvertently. I want to say recommends, since it could be an optional feature. Whats the best way ? Signed-off-by: Jim Cromie --- lib/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 9ad9210d70a1..a7973063baf0 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -100,6 +100,7 @@ config DYNAMIC_DEBUG depends on PRINTK depends on (DEBUG_FS || PROC_FS) select DYNAMIC_DEBUG_CORE + select ZPOOL help Compiles debug level messages into the kernel, which would not -- 2.26.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 7/8] dyndbg: enable 'cache' of active pr_debug callsites
breakpoints because program is no longer writable.
Further execution is probably impossible.
1331pr_debug("%s\n", *p);
(gdb)
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
1330for (p = envp_init; *p; p++)
(gdb)
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
1331pr_debug("%s\n", *p);
(gdb)
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
1330for (p = envp_init; *p; p++)
(gdb)
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
1331pr_debug("%s\n", *p);
(gdb)
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
1330for (p = envp_init; *p; p++)
(gdb)
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
1332return do_execve(getname_kernel(init_filename),
(gdb)
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
kernel_init (unused=) at ../init/main.c:1435
1435if (!ret)
(gdb) n
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
1437panic("Requested init %s failed (error %d).",
(gdb)
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 102f47b2a439..9c51f24a9c66 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -174,7 +174,9 @@ static void ddebug_callsite_put(struct _ddebug *dp)
/* no site to unmap, or no means to restore */
return;
- /* always unmap for now. if !pr-debug was too hard */
+ if (dp->flags & _DPRINTK_FLAGS_PRINT)
+ return; /* keep maps of enabled pr_debugs */
+
zs_unmap_object(dd_callsite_zpool, dp->zhandle);
dp->site = NULL;
}
--
2.26.2
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH 4/8] dyndbg: split struct _ddebug in 2, creating _ddebug_callsite
Split the struct into 2 linked parts (head & body) so that next,
struct _ddebug_callsite can be off-lined to zram, and only mapped in
as needed. The split increases overall memory use by 1 pointer per
callsite, but 4 pointers and a short are now 99% likely to be off-line
(once implemented).
dyndbg: 264 modules, 2541 entries and 10560 bytes in ddebug tables,\
81312 bytes in __dyndbg section, 101640 bytes in __dyndbg_callsites section
zram should give us some compression on the _ddebug_callsite data, and
if it doesn't, a simple run-length-encoder would be effective enough,
given the repetition on (modname,filename,function) of (90%,84%,45%)
and the highly ordered contents of the __ddebug_callsites section.
I wanted to also put the key field into _ddebug_callsite, since its
use is super rare; it is only used when enabling/disabling a callsite,
ie only when >control is being actively exersized. But that blew up
with asm goto errors, so I punted.
So struct _ddebug_callsite is all const, RO data. Maybe thats
advantageous later, but with key there too, we can shrink the online
struct _ddebug further.
details of how:
dynamic_debug.h:
I literally cut struct _ddebug in half, renamed top-half, kept
__align(8) on both, added forward decl for unified comment (not needed
by compiler), and a site pointer from _ddebug to _ddebug_callsite, and
a few "->site" additions.
DECLARE_DYNAMIC_DEBUG_METADATA does the rest; it declares and
initializes both static struct vars together, and refs one to the
other. Note: this may conflict with new guards against cross-linked
sections, but __init work on __initdata seems a fair loophole.
dynamic_debug.c:
dynamic_debug_init() gets "->site" added everywhere needed.
Other 3 runtime users get a new _ddebug_callsite *dc pointer,
initialized with a single dp->site deref, and s/dp/dc/ as needed.
These one per func dp->site derefs are a setup for the next commit.
vmlinux.lds.h:
add __ddebug_callsites section, with the same align(8) and KEEP as
used in the __ddebug section. I suspect keep may go as a part of
causing the section reclaim.
Signed-off-by: Jim Cromie
---
include/asm-generic/vmlinux.lds.h | 4 +++
include/linux/dynamic_debug.h | 38 --
lib/dynamic_debug.c | 52 +--
3 files changed, 60 insertions(+), 34 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index c78629ec79b6..c874216c01f5 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -320,6 +320,10 @@
*(__tracepoints)\
/* implement dynamic printk debug */\
. = ALIGN(8); \
+ __start___dyndbg_callsites = .; \
+ KEEP(*(__dyndbg_callsites)) \
+ __stop___dyndbg_callsites = .; \
+ . = ALIGN(8); \
__start___dyndbg = .; \
KEEP(*(__dyndbg)) \
__stop___dyndbg = .;\
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index aa9ff9e1c0b3..1bf52952df69 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -7,11 +7,15 @@
#endif
/*
- * An instance of this structure is created in a special
- * ELF section at every dynamic debug callsite. At runtime,
- * the special section is treated as an array of these.
+ * a pair of these structs are created in 2 special ELF sections
+ * (__dyndbg, __dyndbg_callsites) for every dynamic debug callsite.
+ * During init, __dyndbg_callsites is copied to zram, and links to
+ * them in _ddebug are updated. At runtime, the __dyndbg section is
+ * treated as an array of struct _ddebugs.
*/
-struct _ddebug {
+struct _ddebug;
+struct _ddebug_callsite {
+
/*
* These fields are used to drive the user interface
* for selecting and displaying debug callsites.
@@ -20,7 +24,12 @@ struct _ddebug {
const char *function;
const char *filename;
const char *format;
- unsigned int lineno:18;
+ const unsigned int lineno:16;
+} __aligned(8);
+
+struct _ddebug {
+ struct _ddebug_callsite *site;
+
/*
* The flags field controls the behaviour at the callsite.
* The bits here are changed dynamically when the user
@@ -32,21 +41,26 @@ struct _ddebug {
#define _DPRINTK_FLAGS_INCL_FUNCNAME (1<<2)
#define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
#define _DPRINTK_FLAGS_INCL_TID(1<<4)
+#define _DPRINTK_FLAGS_MAPPED (1<<7) /* reserved */
#if defined DEBUG
Re: [PATCH 0/8] dyndbg: WIP diet plan
> Im sending to kernelnewbies 1st, to see if theres any low-speed
> test-crashes I can get post-mortems of, before I take it to the races.
>
>
So, I might as well narrate a bit here, see if I can get to a
compelling story ..
$ gdb -x ../cmds vmlinux
$ more ../cmds
target remote :1234
# hbreak ddebug_zpool_init
# c
# return
hbreak run_init_process
break dynamic_emit_prefix
break __dynamic_pr_debug
c
OK, so in the middle of stepping / nexting I get into apic-* stuff
its hard to read w/o the colorized context..
ddebug_callsite_put (dp=) at ../lib/dynamic_debug.c:650
650 ddebug_callsite_put(dp);
(gdb) s
177 if (dp->flags & _DPRINTK_FLAGS_PRINT)
(gdb)
dynamic_emit_prefix (dp=0x827a7458 <__UNIQUE_ID_ddebug356.11>,
buf=0xc9013ea0 "main:run_init_process: ") at
../lib/dynamic_debug.c:652
652 return buf;
(gdb)
printk (fmt=0x824773b6 "\001\067%s%pV") at
../kernel/printk/printk.c:2069
2069 va_start(args, fmt);
(gdb)
2070 r = vprintk_func(fmt, args);
(gdb)
vprintk_func (fmt=0x824773b6 "\001\067%s%pV", args=0xc9013e18)
at ../kernel/printk/printk_safe.c:374
374 if ((this_cpu_read(printk_context) & PRINTK_NMI_DIRECT_CONTEXT_MASK) &&
(gdb) bt
#0 vprintk_func (fmt=0x824773b6 "\001\067%s%pV",
args=0xc9013e18)
at ../kernel/printk/printk_safe.c:374
#1 0x811475bc in printk (fmt=) at
../kernel/printk/printk.c:2070
#2 0x814aec2a in __dynamic_pr_debug (descriptor=, fmt=)
at ../lib/dynamic_debug.c:669
#3 0x810010a1 in run_init_process
(init_filename=0x888007fd6545 "/bin/sh")
at ../init/main.c:1326
#4 0x81c64741 in kernel_init (unused=) at
../init/main.c:1434
#5 0x81001f62 in ret_from_fork () at ../arch/x86/entry/entry_64.S:293
#6 0x in ?? ()
(gdb) ret
Make vprintk_func return now? (y or n) y
#0 printk (fmt=) at ../kernel/printk/printk.c:2073
2073 return r;
HERE, I NEXT INTO LAPIC, SHUTDOWN mumble.
is there anything I can unconfigure to avoid
how can I avoid these kind of things ?
is there something I can un-configure for a virtual kernel
(gdb) n
lapic_timer_shutdown (evt=) at ../arch/x86/kernel/apic/apic.c:490
490 apic_write(APIC_LVTT, v);
(gdb) n
491 apic_write(APIC_TMICT, 0);
(gdb)
492 return 0;
(gdb)
clockevents_switch_state (dev=0x888007a174c0,
state=CLOCK_EVT_STATE_ONESHOT_STOPPED)
at ../kernel/time/clockevents.c:154
154 clockevent_set_state(dev, state);
(gdb)
152 return dev->state_use_accessors == CLOCK_EVT_STATE_ONESHOT;
(gdb)
tick_program_event (expires=9223372036854775807, force=)
at ../kernel/time/tick-oneshot.c:32
32 dev->next_event = KTIME_MAX;
(gdb)
33 return 0;
(gdb)
remove_hrtimer (restart=, base=,
timer=)
at ../kernel/time/hrtimer.c:1038
1038 return 1;
(gdb)
__hrtimer_start_range_ns (timer=0x888007a1e5c0, tim=1101350314, delta_ns=0,
mode=, base=0x888007a1e0c0) at
../kernel/time/hrtimer.c:1093
1093 if (mode & HRTIMER_MODE_REL)
(gdb)
1098 hrtimer_set_expires_range_ns(timer, tim, delta_ns);
(gdb)
1101 new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
(gdb)
334 return res;
(gdb)
1101 new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
(gdb)
1103 return enqueue_hrtimer(timer, new_base, mode);
(gdb)
hrtimer_start_range_ns (timer=0x888007a1e5c0, tim=1101350314,
delta_ns=,
mode=HRTIMER_MODE_ABS_PINNED_HARD) at ../kernel/time/hrtimer.c:1134
1134 hrtimer_reprogram(timer, true);
(gdb)
1136 unlock_hrtimer_base(timer, &flags);
(gdb)
898 raw_spin_unlock_irqrestore(&timer->base->cpu_base->lock, *flags);
(gdb)
__tick_nohz_idle_stop_tick (ts=) at
../kernel/time/tick-sched.c:978
978 if (!was_stopped && ts->tick_stopped) {
(gdb)
979 ts->idle_jiffies = ts->last_jiffies;
(gdb)
980 nohz_balance_enter_idle(cpu);
(gdb)
cpuidle_idle_call () at ../kernel/sched/idle.c:161
161 rcu_idle_enter();
(gdb)
163 default_idle_call();
(gdb)
164 goto exit_idle;
(gdb)
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH 0/8] dyndbg: WIP diet plan
On Thu, Aug 6, 2020 at 4:40 AM Greg KH wrote: > > On Wed, Aug 05, 2020 at 12:30:15PM -0600, Jim Cromie wrote: > > dynamic-debug metadata is bloated; the __dyndbg linker section is > > effectively an array of struct _ddebugs, its 1st 3 members are highly > > repetetive, with 90%, 84%, 45% repeats. Total reported usage ~150kb > > for ~2600 callsites on my laptop config. > > > > This patchset is one diet plan. it all holds together nicely until the > > "cache" commit, when it blows up starting init (or right after freeing > > unused kernel image, which Im hoping to do...). The following commit > > tweaks locking in an attempt to recover, but fails. > > > > Any reason this went to kernelnewbies, and not lkml so that other > developers could see it? > > thanks, > > greg k-h Mostly cuz its broken. and I feel like I have dumb questions I was hoping to repair the stupid errors before going to LKML trade dumb questions for considered answers, and hopefully reply with progress But I'll take your question as advice. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
what are all the .cold symbols in system.map?
Ive been seeing these in my backtraces they seem to come in both .cold and not cold flavors are they related to unlikely() code blocks ? 81001820 t calibrate_delay_direct 81001a90 t calibrate_delay_converge 81001bb0 W calibration_delay_done 81001bc0 T calibrate_delay 81001cc3 t calibrate_delay_direct.cold 81001df7 t calibrate_delay.cold ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Help to test the powerpc architecture
On Mon, Aug 10, 2020 at 3:15 AM Santosh S wrote: > > On Sunday, 2 August, 2020 7:57:03 PM IST Oscar Carter wrote: > > Hi, > > > > I'm working in a new feature for the powerpc (64 bits little endian) > > architecture. Since I can't test it in a real environment, I need to > > emulate this arch. To do this I use qemu-ppc. My problem is that the > > built kernel don't boot in qemu. > > > > To build the kernel: > > I would recommend you try virtme, particularly virtme-config-kernel [jimc@frodo build-v1]$ virtme-configkernel --help usage: virtme-configkernel [-h] [--arch ARCHITECTURE] [--allnoconfig | --defconfig | --update] Configure a kernel for virtme optional arguments: -h, --help show this help message and exit --arch ARCHITECTURE Target architecture Mode: --allnoconfigOverwrite configuration with a virtme-suitable allnoconfig (unlikely to work) --defconfig Overwrite configuration with a virtme-suitable defconfig --update Update existing config for virtme > > make defconfig ARCH=powerpc > > > > Then I set to NO the CONFIG_KEXEC option as I found that qemu can't > > boot a KEXEC kernel. And now: > > > > make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 > > > > Finally I obtain a zImage in arch/powerpc/boot/ directory. > > > > Before to run qemu I create a rootfs with debootstrap. Then I run qemu > > with the following parameters: > > > > qemu-system-ppc -kernel /media/ubuntu/Data/linux/arch/powerpc/boot/zImage \ > > -append "root=/dev/sda console=ttyS0" \ > > -drive file=qemu_image.img,index=0,media=disk,format=raw \ > > --nographic > > > > If I add the "-prom-env boot-args=-v" to the end of the last command I get > > > > the same result. The qemu always stops at this point: > > >> = > > >> OpenBIOS 1.1 [Dec 27 2018 23:11] > > >> Configuration device id QEMU version 1 machine id 2 > > >> CPUs: 1 > > >> Memory: 128M > > >> UUID: ---- > > >> CPU type PowerPC,750 > > > > milliseconds isn't unique. > > Welcome to OpenBIOS v1.1 built on Dec 27 2018 23:11 > > > > >> [ppc] Kernel already loaded (0x0100 + 0x009085d8) (initrd 0x > > >> + 0x) [ppc] Kernel command line: root=/dev/sda console=ttyS0 > > > > >> switching to new context: > > Also, I've tried to build the kernel with a DTB embedded in the image, > > but not luck. The same result again. > > > > make ps3_defconfig ARCH=powerpc > > make ARCH=powerpc simpleImage.ps3 CROSS_COMPILE=powerpc-linux-gnu- -j4 > > > > I'm stuck at this point. I don't know how to configure the kernel to be > > able to boot with qemu. Any help to point me to the right direction > > will be greatly appreciated. > > I used `pseries_defconfig` and have also used `pseries_le_defconfig` and > have done successful boots. You should probably give the machine type in > your qemu command line. > > `-M pseries` > > or whatever is the machine type is for ps3 > > Thanks, > Santosh > > > > > Thank's in advance. > > Oscar Carter > > > > ___ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Compiled Kernel stuck in booting
On Wed, Jul 29, 2020 at 2:54 AM Yashodhan Joshi wrote: > > Hello, > > I use a dual boot laptop with windows and Ubuntu,with grub2. > > I Followed the instruction in > https://kernelnewbies.org/OutreachyfirstpatchSetup to clone the source code > and compile the kernel, which was done without any errors. > When I tried to install the kernel using 'sudo make modules_install install' > it showed a warning when updating initramfs, that it will attempt to resume > from UUID, which is my SWAP space, > but other than that it showed no other errors. > > When I tried to boot into it from the grub menu after restarting, it showed > message of loading the kernel and then 'setting up intitial ramdisk', after > which nothing further happend. off the top of my head, try editing the boot-config in grub, add a "1" or "S" on old redhat distros to end of command line args. that should drop you to root shell in emergency / maintenance mode. (or it used to, I dont recall last time I did it, I suspect you might hit that hang 1st, but its an easy enough test. > The default kernel that came with ubuntu is still working and boots up into > desktop environment withing 2-3 minutes after the 'ramdisk' message, > but even though I kept the system running for 20 minutes after the 'ramdisk' > message for the compiled kernel, niether any further proccess seems to be > happening nor any error messages are shown. > Can someone help me figuring out what is wrong and how can I run the kernel? > > Thank You. > > Also can someone point me in right direction to send suggestions about > updating the information on kernelnewbies website? > The information about connecting mutt to Gmail is quite outdated, and I would > like to help updating it. > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Cannot boot kernel 2.6.35 or 2.6.24 with qemu 5.1
On Thu, Aug 27, 2020 at 6:45 AM Cao Nitro wrote: > > Hi all, > > > > As the title mentions, I cannot boot Linux kernel 2.6.35 or 2.6.24 with QEMU > 5.1 on Arch Linux. QEMU hasn’t any output when running. > > that is ancient. why dont you try a new one, see if that works. if it doesnt, youre working a smaller problem. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
opaque "pointer" API, model, best practice ?
hi all, is there an api / usage model / or best practice for opaque "handles" ? Im aware of 1 case: the handle returned by zs_malloc I have tried to use it, and have run into locking conflicts when trying to keep the memory zs_mapped longer than the duration of a function. OTOH, if I map and unmap within the function, things work, but this is unacceptable overhead. so I figure I should read some good code, rather than keep hacking at bad code. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: opaque "pointer" API, model, best practice ?
On Wed, Oct 14, 2020 at 9:21 AM Greg KH wrote: > > On Wed, Oct 14, 2020 at 09:09:11AM -0600, jim.cro...@gmail.com wrote: > > hi all, > > > > is there an api / usage model / or best practice > > for opaque "handles" ? > > "it depends" :) > > What are you wanting to do exactly? > > > Im aware of 1 case: > > the handle returned by zs_malloc > > I have tried to use it, and have run into locking conflicts > > when trying to keep the memory zs_mapped > > longer than the duration of a function. > > OTOH, if I map and unmap within the function, things work, > > but this is unacceptable overhead. > > > > so I figure I should read some good code, > > rather than keep hacking at bad code. > > Again, what are you trying to do? > > greg k-h Im trying to put dynamic-debug metadata on a diet. Ive split struct _ddebug into 2 (new part is struct -_ddebug_callsite) with a pointer linking them (intialied by DECLARE_DYNAMIC_DEUG_METADAT) The _callsite records have lots of redundancy in module, file, function pointers, so Im hoping rzram can compress that all away. Ive managed to zs_malloc and copy the _callsite recs, and to zs_map them in when executing pr_debug (and thereby ddebug_emit_prefix) as long as I unmap immediately afterwards. But if I try to keep the mapping for the next potential print, things blow up, with a lot of lockdep complaints and a panic. If I can make it work, we can retire the new section I created for the _callsite data, and reduce the ~160kb of table storage by 30% Ive been meaning to send it to mm-linux, but havent yet de-cluttered it enough ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
hot take question for the day
so I was looking at the following code, from dynamic_debug.c,
I saw a minor code optimization, and wondered whether
its already optimized away by compiler.
Instead of actually testing it ( I intend to eventually )
I figure Id ask if you all want to take an educated guess ?
or perhaps just do the test, and post results.
And since Im making a game of it, I might suggest a prize -
that by prepping a patch, showing its effect (none? tiny?
not observable in objdump?) and submitting it, I would ack it
I suspect that Greg might take it ; its a legit sub-optimality and
fix is at least decluttering and deobfuscating.
so heres the snippet.
if you got this far, you can find the prob (or 2)
static char *dynamic_emit_prefix(struct _ddebug *dp, char *buf)
{
int pos_after_tid;
int pos = 0;
*buf = '\0';
if (dp->flags & _DPRINTK_FLAGS_INCL_TID) {
if (in_interrupt())
pos += snprintf(buf + pos, remaining(pos), " ");
else
pos += snprintf(buf + pos, remaining(pos), "[%d] ",
task_pid_vnr(current));
}
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Failure debug messages
So Im seeing these pr_debug messages from kernel/module.c [ 624.32] dyndbg: 336 debug prints in module i915 [ 624.891526] module:find_symbol: Failed to find symbol i915_gpu_busy [ 624.891528] module:find_symbol: Failed to find symbol i915_gpu_lower [ 624.891530] module:find_symbol: Failed to find symbol i915_gpu_raise [ 624.891532] module:find_symbol: Failed to find symbol i915_gpu_turbo_disable [ 624.891534] module:find_symbol: Failed to find symbol i915_read_mch_val [ 624.891537] module:find_symbol: Failed to find symbol intel_gvt_register_hypervisor [ 624.891539] module:find_symbol: Failed to find symbol intel_gvt_unregister_hypervisor Best I can tell (from local experience, running this kernel) this is not a big-time hard failure. But what is going on? they all appear by name to be functions, not data ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
linker script hack - can it be made to work ?
Im attempting to conditionally link an input section. if the just linked similarly named section wasnt empty. __start___dyndbg = .; \ _ = .; \ \ KEEP(*(__dyndbg (.-_)? gnu.linkonce.d.__dyndbg)) \ __stop___dyndbg = .; it gives me an unspecified linker syntax error ld:./arch/x86/kernel/vmlinux.lds:46: syntax error its pretty clear that this experiment is failing, is there another way to do this ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
'-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ?
hi folks, In my hacking, Im finding this useful. it adds a version of KBUILD_MODNAME without the quotes --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -119,7 +119,7 @@ target-stem = $(basename $(patsubst $(obj)/%,%,$@)) # end up in (or would, if it gets compiled in) name-fix = $(call stringify,$(subst $(comma),_,$(subst -,_,$1))) basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget)) -modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) +modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) -DKBUILD_MODSYM=$(modname) Im suspicious however, KBUILD_MODNAME has the quotes for a reason; probably robustness at some level. Afterall, __stringify() could add the quotes for cases where it was needed. If there was an __unstringify_token( ) I could remove this Makefile hack, is such a construct possible ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ?
On Thu, Jan 28, 2021 at 4:57 PM Valdis Klētnieks
wrote:
> On Thu, 28 Jan 2021 12:11:54 -0700, jim.cro...@gmail.com said:
>
> > In my hacking, Im finding this useful.
> > it adds a version of KBUILD_MODNAME without the quotes
>
> OK, I'll bite. When and how is this useful?
>
>
heres my use
#define DEFINE_DYNAMIC_DEBUG_TABLE_(_sym_,_mod_) \
weak struct _ddebug \
__used __aligned(8) \
__section(".gnu.linkonce." _mod_ ".dyndbg") \
_sym_##_dyndbg_base = { \
.site = &_sym_##_dyndbg_site, \
.format = _mod_, \
.lineno = 0 \
}
#pragma message "OK<" KBUILD_MODNAME ">[" __stringify(KBUILD_MODSYM) "]
adding DYNDBG_TABLE"
#define DEFINE_DYNAMIC_DEBUG_TABLE() \
DEFINE_DYNAMIC_DEBUG_TABLE_(KBUILD_MODSYM, KBUILD_MODNAME);
that pragma does:
from /home/jimc/projects/lx/wk-next/init/version.c:14:
/home/jimc/projects/lx/wk-next/include/linux/dynamic_debug.h:172:9: note:
‘#pragma message: OK[version] adding DYNDBG_TABLE’
172 | #pragma message "OK<" KBUILD_MODNAME ">["
__stringify(KBUILD_MODSYM) "] adding DYNDBG_TABLE"
| ^~~
CC init/do_mounts.o
IOW the _sym_ works better for ## token-joining
> KBUILD_MODNAME has the quotes for a reason;
>
> Hint: do a "git grep KBUILD_MODNAME", look at how it's used, and
> think about how invasive a patch to change it would be...
> (And pay heed to the comment in arch/sparc/include/asm/vio.h -
> it means that there's second-order effects to deal with as well...)
>
>
I have no intention of changing KBUILD_MODNAME.
I created a near-synonym to avoid exactly that.
> > Afterall, __stringify() could add the quotes for cases where it was
> needed.Afterall, __stringify() could add the quotes for cases where it was
> needed.
>
> How would it know?
>
It would not.
you would add it to create the quoted version, as I used in the pragma.
obviously theres no need, since KBUILD_MODNAME already exists.
So question reduces to:
is there anything brittle with the Makefile -DKBUILD_MODSYM=$modname
addition ?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ?
On Thu, Jan 28, 2021 at 5:16 PM wrote:
>
>
> On Thu, Jan 28, 2021 at 4:57 PM Valdis Klētnieks
> wrote:
>
>> On Thu, 28 Jan 2021 12:11:54 -0700, jim.cro...@gmail.com said:
>>
>> > In my hacking, Im finding this useful.
>> > it adds a version of KBUILD_MODNAME without the quotes
>>
>> OK, I'll bite. When and how is this useful?
>>
>>
>
Let me add more context here.
1st, the long saga.
v1 - here, back in august last year.
https://lore.kernel.org/kernelnewbies/20200805183023.586590-1-jim.cro...@gmail.com/
not really pertinent here.
gregkh pretty much said send it to lkml
v2 - RFC to LKML
https://lore.kernel.org/lkml/20201225201944.3701590-1-jim.cro...@gmail.com/
this didnt get much attention, no answers to my questions
the is still completely accurate, I cannot improve upon it,
though many questions in the commit messages Ive answered myself.
(or at least made some choices ;)
v3 - sits in github now
almost identical 1-16/19 with v2
https://github.com/jimc/linux.git dyndbg-next
I was hoping to pull off a context-free question,
focusing on just the Makefile.lib patch's suitability.
I could send the whole series here, or to LKML, or both.
I can hope a quick perusal will get you to the interesting parts
> heres my use
>
>
Im looking to define a module-unique header record,
and to create storage for it in a separate section.
Then append that section to the module's __dyndbg section.
The pragma is leftover scaffolding from trying to figure out
that I needed the _sym_ version also, without the quotes.
I un-commented for demo only.
#define DEFINE_DYNAMIC_DEBUG_TABLE_(_sym_,_mod_) \
> weak struct _ddebug \
> __used __aligned(8) \
> __section(".gnu.linkonce." _mod_ ".dyndbg") \
> _sym_##_dyndbg_base = { \
> .site = &_sym_##_dyndbg_site, \
> .format = _mod_, \
> .lineno = 0 \
> }
>
> #define DEFINE_DYNAMIC_DEBUG_TABLE() \
> DEFINE_DYNAMIC_DEBUG_TABLE_(KBUILD_MODSYM, KBUILD_MODNAME);
>
>
I cannot make the _mod_ ## work at the same time as
allowing "foo" _mod_ "buzz" catenation, therefore the new _sym_
This DEFINE is "called" from the bottom of include/linux/dynamic_debug.h
the combo of weak and ".gnu.linkonce." appear to resolve all
all the redundant definitions created by each C files' inclusion
of the header.
Inspiration came from .gnu.linkonce.this_module
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -329,10 +329,10 @@
#define DYNAMIC_DEBUG_DATA() \
. = ALIGN(8); \
__start___dyndbg_sites = .; \
- KEEP(*(__dyndbg_sites __dyndbg_sites.header)) \
+ KEEP(*(__dyndbg_sites .gnu.linkonce.*.dyndbg_site)) \
__stop___dyndbg_sites = .; \
__start___dyndbg = .; \
- KEEP(*(__dyndbg __dyndbg.header)) \
+ KEEP(*(__dyndbg .gnu.linkonce.*.dyndbg)) \
__stop___dyndbg = .;
#else
#define DYNAMIC_DEBUG_DATA()
that puts the header record into the output section, right after the
module's
set of ddebug's (pr_debug callsite descriptors)
By getting the header into a fixed position relative to a callsite,
its possible to go from callsite-descriptor to the header
(after .module_index is initialized with the offset, determined at _init),
then use a single per-module pointer to the separate vector of "decorator"
data.
Once the 2 vectors of __dyndbg and __dyndbg_site records are indexed by N,
I can drop the .site pointer from 1 to other, and shrink the footprint back
to
~parity (with + 1 record / module overhead) worst case.
with 2 vectors fully decoupled (pointer-wise),
the decorator records can be stuffed into compressed block storage,
zram, etc, then recovered when a callsite is enabled,
and saved into a hashtable, indexed by modname+module-index.
global/module hash per experiment.
Anyway, I appear to have gotten the header where I want it:
[0.315519] dyndbg: header: head64 0
[0.326702] dyndbg: header: ebda 0
[0.342521] dyndbg: header: platform_quirks 0
[0.373523] dyndbg: site.4: main run_init_process
[0.406518] dyndbg: site.5: main run_init_process
[0.437521] dyndbg: site.6: main run_init_process
[0.468521] dyndbg: site.7: main run_init_process
[0.500528] dyndbg: site.8: main initcall_blacklisted
[0.531519] dyndbg: site.9: main initcall_blacklist
[0.20] dyndbg: header: main 0
I have extra headers right now,
head64 ebda platform_quirks above,
for modules that have no pr-debug callsites.
Thats a problem for later,
though I posted here about conditional linkage earlier.
Im afraid it needs an ld linker language enhancement:
KEEP( IF *(__dyndbg) THEN (.gnu.linkonce.dyndbg) )
but Ive yet to try a simpler boolean algrebra
KEEP( *(__dyndbg && .gnu.linkonce.dyndbg))
if by some miracle that works, I'll report that shortly.
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: '-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ?
... and somethings not right. debugger KBUILD_SYM shows it:
these records are same as those shown in early boot output pasted previously
these records look right
(gdb) p *__start___dyndbg_sites@10
$2 = {{modname = 0x825a8ab9 "head64",
filename = 0x825a8ac0 "include/linux/dynamic_debug.h",
function = 0x825a8ab9 "head64"}, {modname = 0x825a8ade
"ebda",
filename = 0x825a8ac0 "include/linux/dynamic_debug.h", function
= 0x825a8ade "ebda"}, {
modname = 0x825a8ae3 "platform_quirks",
filename = 0x825a8ac0 "include/linux/dynamic_debug.h",
function = 0x825a8ae3 "platform_quirks"}, {modname =
0x825cac42 "main",
filename = 0x825a8afe "init/main.c",
function = 0x822000e0 <__func__.2> "run_init_process"},
{modname = 0x825cac42 "main",
filename = 0x825a8afe "init/main.c",
function = 0x822000e0 <__func__.2> "run_init_process"},
{modname = 0x825cac42 "main",
filename = 0x825a8afe "init/main.c",
function = 0x822000e0 <__func__.2> "run_init_process"},
{modname = 0x825cac42 "main",
filename = 0x825a8afe "init/main.c",
function = 0x822000e0 <__func__.2> "run_init_process"},
{modname = 0x825cac42 "main",
filename = 0x825a8afe "init/main.c",
function = 0x822000a0 <__func__.0> "initcall_blacklisted"}, {
modname = 0x825cac42 "main", filename = 0x825a8afe
"init/main.c",
function = 0x822000c0 <__func__.1> "initcall_blacklist"}, {
modname = 0x825cac42 "main", filename = 0x825a8ac0
"include/linux/dynamic_debug.h",
function = 0x825cac42 "main"}}
Theres evidently something wrong with my KBUILD_MODSYM _dyndbg_site here,
the site pointers in all the headers appear the same,
but maybe its just an effect of initialization,
which I expect to reshape with a union - struct to use the space efficiently
(gdb) p *__start___dyndbg@10
$3 = {{site = 0x82b252e8 , format =
0x825a8ab9 "head64",
lineno = 0, flags = 0, module_index = 0, key = {dd_key_true = {key =
{enabled = {counter = 0}, {
type = 0, entries = 0x0 , next = 0x0
}}},
dd_key_false = {key = {enabled = {counter = 0}, {type = 0, entries =
0x0 ,
next = 0x0 }, {site = 0x82b252e8
,
format = 0x825a8ade "ebda", lineno = 0, flags = 0, module_index
= 0, key = {dd_key_true = {
key = {enabled = {counter = 0}, {type = 0, entries = 0x0
,
next = 0x0 }}}, dd_key_false = {key =
{enabled = {counter = 0}, {type = 0,
entries = 0x0 , next = 0x0
}, {
site = 0x82b252e8 , format =
0x825a8ae3 "platform_quirks",
lineno = 0, flags = 0, module_index = 0, key = {dd_key_true = {key =
{enabled = {counter = 0}, {
type = 0, entries = 0x0 , next = 0x0
}}},
dd_key_false = {key = {enabled = {counter = 0}, {type = 0, entries =
0x0 ,
next = 0x0 }, {
site = 0x82b25330 <__UNIQUE_ID_ddebug468_site.13>, format =
0x82653f07 "%s\n",
lineno = 1349, flags = 1, module_index = 0, key = {dd_key_true = {key =
{enabled = {counter = 1}, {
type = 18446744071602861249, entries = 0x826e74c1, next
= 0x826e74c1}}},
dd_key_false = {key = {enabled = {counter = 1}, {type =
18446744071602861249,
entries = 0x826e74c1, next = 0x826e74c1}, {
site = 0x82b25348 <__UNIQUE_ID_ddebug467_site.15>,
format = 0x825a8b59 " with environment:\n", lineno = 1347,
flags = 1, module_index = 0,
key = {dd_key_true = {key = {enabled = {counter = 1}, {type =
18446744071602861265,
entries = 0x826e74d1, next = 0x826e74d1}}},
dd_key_false = {key = {enabled = {
counter = 1}, {type = 18446744071602861265, entries =
0x826e74d1,
next = 0x826e74d1}, {site = 0x82b25360
<__UNIQUE_ID_ddebug466_site.17>,
format = 0x82653f07 "%s\n", lineno = 1346, flags = 1,
module_index = 0, key = {
dd_key_true = {key = {enabled = {counter = 1}, {type =
18446744071602861281,
entries = 0x826e74e1, next = 0x826e74e1}}},
dd_key_false = {key = {enabled = {
counter = 1}, {type = 18446744071602861281, entries =
0x826e74e1,
next = 0x826e74e1}, {site = 0x82b25378
<__UNIQUE_ID_ddebug465_site.19>,
format = 0x825a8b46 " with arguments:\n", lineno = 1344, flags
= 1, module_index = 0, key = {
dd_key_true = {key = {enabled = {counter = 1}, {type =
18446744071602861297,
at any rate, I'll probly work this a bit, see if I can resolve a few
problems
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbi
Re: Does 'make oldconfig' work across different architectures?
On Thu, Feb 18, 2021 at 8:07 PM wrote: > Hello folks, > > When we want to use an old .config file for a new kernel build, we can use > (place in build location) that .config and do ‘make oldconfig’ so that the > build system lets us to fill the new config variables. > > I'm curious if this 'make oldconfig' will work if the old .config is from > different architecture (like sparc) and I have to configure it for aarch64. > > The old .config file is a minimal configuration with timer, interrupt > controller and uart for minimal linux booting. > > Thanks! > Chan Kim > __ you need to define "working". I bet it would work to produce a config that is syntactically correct. whether it builds a bootable kernel is less clear. Ive only built and installed to hw 1 non-x86 kernel, so my experience isnt relevant to other arches, ymmv ISTM you should try defconfig for aarch64 your .config, updated with oldconfig diff them, see whats happened to various CONFIG vars ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
is there an efficient module_is_builtin() test ?
Im trying to reduce memory used by internal tables built into DYNAMIC_DEBUG the main savings available is in the per pr_debug* callsite data: modname, filename, funcname. I have segregated those fields to a new __dyndbg_sites section, described by struct _ddebug_site, and now refd by new ptr in struct _ddebug That new ptr enlarges the memory footprint, so I want to replace it with an integer index into the section / array. Existing padding could hold the index. To use the index, I need &dyndbg_sites[], and that only works for builtin-module's callsites. For loaded modules, I can/have added a pointer to the section into module load_info, giving me the base I will need for the ! builtin branch. I just need a not expensive is-it-builtin (modref) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
help with linker script mods
so Im trying to constrain the linker to put ELF section pairs
into contiguous chunks of memory.
this is on top of:
https://lore.kernel.org/lkml/20210316050801.2446401-1-jim.cro...@gmail.com/
The macro below works when used in vmlinux.lds.h,
it does pack the sections as desired.
but same macro, when reused in module.lds.h, fails.
The version below links ok, but appears to absorb the __dyndbg* sections
into the .data section, which works for vmlinux.lds.h, cuz there we use the
__start/stop ___dyndbg* symbols to use the section.
In contrast, for modules, I want to preserve the named sections
as proper elf sections in the ko, so that loader picks them up
and saves them into struct load-info
Anyone got some deep linker-fu ?
[jimc@frodo wk-next]$ git diff
diff --git a/include/asm-generic/module.lds.h
b/include/asm-generic/module.lds.h
index f210d5c1b78b..4840f01a0828 100644
--- a/include/asm-generic/module.lds.h
+++ b/include/asm-generic/module.lds.h
@@ -4,7 +4,26 @@
/*
* can specify arch-specific sections for linking
modules.
- * Empty for the asm-generic header.
+ * DYNAMIC_DEBUG needs its header sections contiguous with its data
sections.
*/
+#if defined(CONFIG_DYNAMIC_DEBUG) ||\
+(defined(CONFIG_DYNAMIC_DEBUG_CORE) \
+ && defined(DYNAMIC_DEBUG_MODULE))
+#define DYNAMIC_DEBUG_DATA()\
+. = ALIGN(8); \
+__start___dyndbg_sites = .; \
+KEEP(*(__dyndbg_sites .gnu.linkonce.dyndbg_site)) \
+__stop___dyndbg_sites = .; \
+__start___dyndbg = .; \
+KEEP(*(__dyndbg .gnu.linkonce.dyndbg)) \
+__stop___dyndbg = .;
+#else
+#define DYNAMIC_DEBUG_DATA()
+#endif
+
+SECTIONS {
+ .data : { DYNAMIC_DEBUG_DATA() }
+}
+
#endif /* __ASM_GENERIC_MODULE_LDS_H */
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is there an efficient module_is_builtin() test ?
On Tue, Mar 9, 2021 at 3:25 PM Valdis Klētnieks wrote: > On Tue, 09 Mar 2021 12:55:14 -0700, jim.cro...@gmail.com said: > > > To use the index, I need &dyndbg_sites[], and that only works > > for builtin-module's callsites. For loaded modules, I can/have > > added a pointer to the section into module load_info, giving me > > the base I will need for the ! builtin branch. > > > > I just need a not expensive is-it-builtin (modref) > thanks Valdis, the back and forth helped. So, to follow up, the above is embodied here; https://lore.kernel.org/lkml/20210316050801.2446401-1-jim.cro...@gmail.com/ in the add index patch, near 13/18 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: are 1-wire devices "discoverable"?
On Sat, Feb 13, 2021 at 11:58 AM Trevor Woerner wrote: > Hi, > > It's true that you do need a device tree overlay to tell the kernel that > you > want to use the 1-wire bus, and you have to tell the kernel which GPIO pin > you > want to use as the 1 wire, but after that, attaching DS18B20 devices to a > running system works quite magically.[4] > > Each DS18B20 has a unique 64-bit number burned into it, the first 8 bits > specify the device type (i.e. the DS18B20), the next 48 bits are a unique > serial number, and the last 8 bits are a CRC of the previous 56 bits. Due > to > the inclusion of the 8-bit device type, when I plug a DS18B20 into my > board, > the kernel automatically creates a sysfs entry for it with a "temperature" > file that I can read to obtain the temperature in Celcius. > > so, this device looks discoverable on a bus, once you know the bus is there. thats the 1st distinction to make. there are degrees/features. Id also ask: is that ID at a standard location ? via some base transaction that all devices support ? in my own house, I can find a switch in the dark. I dont have Alexa listening to render help. > I don't know if that qualifies as "discoverable"? It's certainly a lot more > discoverable than I2C or SPI, although maybe not quite as discoverable as, > say, PCI. Specifying the 1 wire is not discoverable, but plugging 1-wire > devices into my board is maybe something that could be described as > discoverable? > > Best regards, > Trevor > > [1] https://www.youtube.com/watch?v=a9CZ1Uk3OYQ > [2] > https://twoerner.blogspot.com/2020/12/temperature-readings-with-ds18b20-and.html > [3] > https://twoerner.blogspot.com/2021/01/sensing-temperature-with-raspberrypi.html > [4] > https://twoerner.blogspot.com/2020/12/multiple-ds18b20-temperature-probes.html > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
"module:find_symbol: Failed to find symbol ....." not so bad.
so when I enable the pr_debug()s in kernel/module, and boot that kernel, I get a raft of messages (~800), like : [ 110.072535] module:find_symbol: Failed to find symbol drm_scdc_get_scrambling_status [ 110.072538] module:find_symbol: Failed to find symbol drm_scdc_read [ 110.072541] module:find_symbol: Failed to find symbol drm_scdc_set_high_tmds_clock_ratio [ 110.072545] module:find_symbol: Failed to find symbol drm_scdc_set_scrambling [ 110.072548] module:find_symbol: Failed to find symbol drm_scdc_write [ 110.072551] module:find_symbol: Failed to find symbol drm_self_refresh_helper_alter_state [ 110.072553] module:find_symbol: Failed to find symbol drm_self_refresh_helper_cleanup What is the potential importance of these ? clearly if it were a real problem, it wouldnt just be a debug message. Is there anything to fix here, either in local config, or in code ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: pid start time and new display field in proc pid stat
On Thu, Mar 25, 2021 at 6:53 AM Navin P wrote: > Hi, > > As of 5.11 kernel (pid,pid_start_time) is not unique /monotonic even > though the underlying counters are . > I chose start_boottime because i wanted the counter to increase > during suspend as well. > > 1. Is there any case where task->start_boottime or > ktime_get_boottime_ns doesn't become monotonic i.e increasing ? > > 2. If start_boottime is not monotonic which counter to use ? > > 3. If i create a new field in task_struct , then i can use a > atomic_add_return(1,&v) to fill in the task->new_field. Will this also > work ? > > Its my understanding that task-struct is a highly "contended" resource. its a basic element, its size matters everybody wants a bit/byte for something special, conflicts ensue (or could). nobody gets them without a real good reason. I dont know what youre trying to achieve, but i suspect that youll need to find a more subtle way of doing it. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to switch between installed kernel and developed kernel
>
>
>
> I've found running a kernel under qemu with my normal rootfs to be quite
> useful to quickly try out things. See the qemu-test script in the RAUC
> project
> for an example: https://github.com/rauc/rauc/blob/master/qemu-test
>
>
I would agree.
I find "virtme" tool to be super simple and effective.
It reuses your running system install, mounted with 9P,
no need to futz with a 2nd system image.
I barely had to tinker with all the qemu options and args...
heres my every-day usage (w my own boring shell funcs wrapping)
function krun () {
echo vm$KRUN_SHOW $KRUN_STDS $KDBG_OPTS $QM_OPTS $*
virtme-run $KRUN_SHOW $KRUN_STDS $KDBG_OPTS $QM_OPTS $*
# -qmp tcp:localhost:,server,nowait
}
[jimc@frodo local-i915m]$ krun
vm --show-command --show-boot-console --kdir . --mods=auto --kopt nokaslr
--kopt dynamic_debug.verbose=3 --kopt module.dyndbg=+pmf --qemu-opts
-machine dump-guest-core=on -m 2G
./.virtme_mods/lib/modules/0.0.0
/usr/bin/qemu-system-x86_64 -fsdev
local,id=virtfs1,path=/,security_model=none,readonly,multidevs=remap
-device virtio-9p-pci,fsdev=virtfs1,mount_tag=/dev/root -fsdev
local,id=virtfs5,path=/usr/local/lib/python3.9/site-packages/virtme-0.1.1-py3.9.egg/virtme/guest,security_model=none,readonly,multidevs=remap
-device virtio-9p-pci,fsdev=virtfs5,mount_tag=virtme.guesttools -machine
accel=kvm:tcg -watchdog i6300esb -cpu host -parallel none -net none -echr 1
-serial none -chardev stdio,id=console,signal=off,mux=on -serial
chardev:console -mon chardev=console -vga none -display none -kernel
./arch/x86/boot/bzImage -append
'virtme_link_mods=/home/jimc/projects/lx/wk-next/builds/local-i915m/.virtme_mods/lib/modules/0.0.0
earlyprintk=serial,ttyS0,115200 console=ttyS0 psmouse.proto=exps
"virtme_stty_con=rows 24 cols 141 iutf8" TERM=xterm-256color rootfstype=9p
rootflags=version=9p2000.L,trans=virtio,access=any raid=noautodetect ro
nokaslr dynamic_debug.verbose=3 module.dyndbg=+pmf init=/bin/sh -- -c
"mount -t tmpfs run /run;mkdir -p /run/virtme/guesttools;/bin/mount -n -t
9p -o ro,version=9p2000.L,trans=virtio,access=any virtme.guesttools
/run/virtme/guesttools;exec /run/virtme/guesttools/virtme-init"' -machine
dump-guest-core=on -m 2G
Wrong EFI loader signature.
early console in extract_kernel
input_data: 0x047a340d
input_len: 0x009f7f00
output: 0x0100
output_len: 0x04139814
kernel_total_size: 0x0363
needed_size: 0x0420
trampoline_32bit: 0x0009d000
KASLR disabled: 'nokaslr' on cmdline.
..
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: make menuconfig
On Sat, Mar 20, 2021 at 1:07 PM Martin Herdeis wrote: > Hello, > > I am trying to learn more about the kernel build system and due to that I > tried the following in the top level Kconfig file right at the beginning: > > config FOO > tristate > prompt "FOO" > config BAR > tristate "BAR" if FOO > i suspect that last line - it feels like a thinko, combining a declaration and a dependency. moreover, `ack tristate` (recursive grep w other nicetohaves) shows 0 such uses. heres typical usage drivers/infiniband/hw/hfi1/Kconfig 3: tristate "Intel OPA Gen1 support" drivers/infiniband/hw/vmw_pvrdma/Kconfig 3: tristate "VMware Paravirtualized RDMA Driver" drivers/infiniband/hw/mlx4/Kconfig 3: tristate "Mellanox ConnectX HCA support" drivers/infiniband/hw/mthca/Kconfig 3: tristate "Mellanox HCA support" drivers/infiniband/hw/qib/Kconfig 3: tristate "Intel PCIe HCA support" > default y > > Then I do a make menuconfig and choose the config option FOO with "m" then > the config option BAR shows up with "y". if I exit and save this > constellation m/y shows up in the .config file. But as I understand the > logic the value of the config option FOO defines the upper level for the > value of the config option BAR. > > When I do just a make menuconfig again both options show up as m even > though in the .config file they are still saved as y/m. > > Is that a problem with the default value of BAR? Am I not supposed to give > it a default value out of range when FOO is m? > > > Thank you, > > Martin > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
patchset grooming question.
I have a patchset which touches vmlinux.lds.h 2x 1st inserts a few lines, 2nd moves them and related to a separate macro. this is sub-optimal, if new macro is warranted, it should just do that in 1st change. or maybe 3rd option. move existing to macro- no functional change then do 2 changes, separately. Whats best approach, considering history and blamelog ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Unable to boot to kernel built from stable 5.11.y
On Tue, Mar 30, 2021 at 7:16 AM Andrew Adamson wrote: > Hi Everyone, > > I tried to build the kernel myself for the first a few days ago. While the > build was successful, I am unable to boot to it. After grub I get a > blinking cursor for 15 to 30 minutes, and then a message that says "Please > reboot and select proper boot device." > > I dont know your higher mission, but I'll suggest: punt on grub install at least temporarily, Try virtme. its a super-easy way to run your built kernel on a VM the VM is setup to use your existing installation so theres no extra configuration to fuss with. [jimc@frodo t2]$ virtme- virtme-configkernelvirtme-mkinitramfs virtme-prep-kdir-mods virtme-run this is probably all you need to enable the right features in your built kernel, basically VIRTIO + NET [jimc@frodo t2]$ virtme-configkernel --update GEN Makefile .config:3468:warning: override: reassigning to symbol UEVENT_HELPER .config:3469:warning: override: reassigning to symbol VIRTIO .config:3472:warning: override: reassigning to symbol NET .config:3482:warning: override: reassigning to symbol BINFMT_SCRIPT .config:3486:warning: override: reassigning to symbol MODULE_SIG_FORCE .config:3487:warning: override: reassigning to symbol DEVTMPFS .config:3488:warning: override: reassigning to symbol TTY .config:3492:warning: override: reassigning to symbol INOTIFY_USER .config:3495:warning: override: reassigning to symbol BLOCK .config:3505:warning: override: reassigning to symbol WATCHDOG .config:3506:warning: override: reassigning to symbol WATCHDOG_CORE .config:3509:warning: override: reassigning to symbol SERIO .config:3511:warning: override: reassigning to symbol INPUT .config:3518:warning: override: reassigning to symbol FB .config:3521:warning: override: reassigning to symbol RTC_CLASS .config:3525:warning: override: reassigning to symbol PARAVIRT # # configuration written to .config # Configured. Build with 'make ARCH=x86 -j8' [jimc@frodo t2]$ there are options to let you mount directories, to keep your VMs work, so this might satisfy your itch. then, you can decide whether you need to mess with grub, and if you do, youll have some own-kernel experience to help. > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Device driver .shutdown() VS .remove()
On Thu, Apr 22, 2021 at 1:37 AM Luca Ceresoli wrote: > Hello, > > despite having been searching for documentation I couldn't find out the > exact and detailed difference between the .shutdown() and .remove() > calls in struct device_driver. > > so, I'll start by saying I know next to nothing, but most of what you said sounds good > From the above it looks like the shutdown() actions must be a subset of > remove() actions. > > but subset is a bit vague. theres 2 dimensions to think about. lifetime - shutdown/startup is surely the longer window, add/remove happen within that hierarchy - subsystems must be ready to handle add / remove fwiw, I 'grepped' (with ack), it shows a few drivers with both functions, many others with just remove you could see in detail what the difference is. $> ack '(\.remove|\.shutdown)\b' drivers/ drivers/rtc/rtc-twl.c 645: .remove = twl_rtc_remove, 646: .shutdown = twl_rtc_shutdown, > > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Test if a socket accept is from external network
On Sun, Apr 25, 2021 at 6:02 AM Jeffrey Walton wrote: > > On Sun, Apr 25, 2021 at 7:09 AM John Wood wrote: > > > > I'm working in a LSM to detect and mitigate fork brute force attacks > > against vulnerable userspace applications. Now, to fine tuning the > > detection I want to detect a network activity. ... > > How can I detect that an external connection (using a net device) is > > accepted and avoid internal network communication? > > One caveat that may (or may not) apply... > > Systemd opens sockets for services even when a service is disabled. It > could appear that a system is accepting traffic even when the service > is unavailable. > > Jeff > this is interesting, it lets systemd add a tarpit to stall those SYN connections. But maybe bpf will do this soon. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does FreeRTOS works on Linux?
On Sun, May 9, 2021 at 12:41 AM loïc tourlonias wrote: > > > if using a posix thread full fills the requirement of RTOS. The reason > > I want to use RTOS is , I am porting a Microcontroller code using RTOS > > (free RTOS) to Linux and > > afaik FreeRTOS doesnt work on Linux. > > > FreeRTOS is a standalone OS and depending on your system there may be > > > an example running on your architecture in parallel of your embedded > > > Linux. For example, on one of my project with have an ARM Cortex-A7 > > > with Linux running in Normal World and FreeRTOS running in Trusted > > > world. > > This is interesting , do you have something to share? > Sorry, this is intellectual property from my company so I can't share > source code but we have started from the FreeRTOS porting sample > related to our architecture. We are working on a ARM Cortex-A7 which > have an isolation between a normal world and a secure world. Linux is > working on the normal world for the UI and FreeRTOS is running on the > secure world. Communication between the two worlds is made by SMC. > > Regards > Loïc > You should look at Xenomai it uses the Adeos interrupt pipeline to pick off and handle certain interrupts and events in real-time, and pass the rest off to the linux kernel that does all setup and housekeeping they have API interfaces for VXworks, and other commercial RTOSs one of those APIs is probably your path of least portage. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
kernel module parameter API ala drm.debug
so as a proof of concept, Ive converted drm to use dynamic-debug
drm has ~dozen categories of debug messages, mapped to bits
in drm.debug, aka /sys/module/drm/parameters/debug
these bits are checked at runtime by drm_debug_enabled()
to do drm debug printing.
my patchset updates users of drm_debug_enabled()
to call pr_debug instead, avoiding lots of bit-checking.
it maps bits of drm.debug using dynamic_debug_exec_queries(),
a recently exported function to support this sort of thing.
you can see it here
https://github.com/jimc/linux/tree/dd-drm
A narrower interface than dynamic_debug_exec_queries() is possible:
+static char *format_prefix_classes[] = {
+ "gvt: cmd: ",
+ "gvt: core: ",
+ "gvt: dpy: ",
+ "gvt: el: ",
+ "gvt: irq: ",
+ "gvt: mm: ",
+ "gvt: mmio: ",
+ "gvt: render: ",
+ "gvt: sched: "
+};
+static const struct kernel_param_ops param_ops_dyndbg = {
+ .set = param_set_dyndbg,
+ .get = param_get_dyndbg,
+};
+
+#define info_ln(hexi, prefix) "\n\t0x" __stringify(hexi) "\t" prefix
+
+MODULE_PARM_DESC(debug_gvt, " gvt debug categories:"
+info_ln(1, "gvt: cmd:")
+info_ln(2, "gvt: core:")
+info_ln(4, "gvt: dpy:")
+info_ln(8, "gvt: el:")
+info_ln(10, "gvt: irq:")
+info_ln(20, "gvt: mm:")
+info_ln(40, "gvt: mmio:")
+info_ln(80, "gvt: render:")
+info_ln(100, "gvt: sched:"));
+
+module_param_cb(debug_gvt, ¶m_ops_dyndbg, &__gvt_debug, 0644);
this is useful in that it shows up in modinfo output
but there could be better presentation,
maybe /sys/module/drm/parameters/debug.help
param_set_dyndbg could be moved into dynamic-debug proper,
instead of reimplemented everywhere debug bits control debug prints
(currently drm, maybe others, could be i915/gvt)
the point is that this integer parameter maps consecutive bits to "classes"
named in an input vector. these "classes" are just format ^prefix queries
clearly we shouldnt need the 1,2,4...
whats a good interface design for this module-param-bitmap ?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to test device driver?
On Mon, May 17, 2021 at 9:28 AM Hyeonggon Yoo <42.hye...@gmail.com> wrote: > > Hello, there are lots of drivers in linux. > > My questions are: > > - how can we test driver? is it just using that device for a long > time as a user? > testing is hard. Having the device is highly recommended. ISTM essential if adding a Tested-by: tag Do you have a particular device in mind ? > - what to do if there's a bug (like syzbot report), fixed it, > but if we don't have that device? > You could reply to that report email, with your patch included. 0day/lkp robot watches many email lists, and might test your patch automatically, for you on different architectures at least Ive seen it happening on kbuild, kbuild-all lists > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to test device driver?
On Mon, May 17, 2021 at 5:54 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote: > > On Mon, May 17, 2021 at 12:48:38PM -0600, jim.cro...@gmail.com wrote: > > On Mon, May 17, 2021 at 9:28 AM Hyeonggon Yoo <42.hye...@gmail.com> wrote: > > > > > > Hello, there are lots of drivers in linux. > > > > > > My questions are: > > > > > > - how can we test driver? is it just using that device for a long > > > time as a user? > > > > > testing is hard. Having the device is highly recommended. > > ISTM essential if adding a Tested-by: tag > > Do you have a particular device in mind ? > > I recently was tracking syzbot report that is occured in > sound driver. I don't have the device, but was curious about > what the test method is. well, it surely depends on the bug - and whether its reproducible. if you could defend the patch as "obviously correct" you could reasonably send it without extensive testing, case by case Id guess. > > > You could reply to that report email, with your patch included. > > 0day/lkp robot watches many email lists, and might test your patch > > automatically, for you on different architectures > > > > at least Ive seen it happening on kbuild, kbuild-all lists > > well, build tests are useful but it is not enough, we should run the > code on actual device. is it possible to make the bot test the device > (which I don't have) even if there is no syzbot reproducer? > its possible / practical to disqualify patches robotically, but to bless them takes a priest. Robots win by prequalifying submissions. > I think I need to learn about bots more.. > Now think about how its a real-life turing test. 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ kbuild-all mailing list -- kbuild-...@lists.01.org To unsubscribe send an email to kbuild-all-le...@lists.01.org theres also a wiki, which helped me make sense of things a bit better than the torrent of reports > Thanks, > Hyeongogn Yoo > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
how to return unneeded init-data to kernel ?
hi all, When one builds with CONFIG_DYNAMIC_DEBUG=y one consumes extra memory for kernel data Ive managed to coax dyndbg into "not needing" about 30KiB in a __dyndbg* section, how can I return it to the kernel ? https://lore.kernel.org/lkml/20210529200029.205306-1-jim.cro...@gmail.com/ b4: dyndbg: 284 modules, 3013 entries and 11360 bytes in ddebug tables, 168728 bytes in __dyndbg section after: dyndbg: 2900 prdebugs in 277 modules, 12 KiB in ddebug tables, 90 KiB in __dyndbg section, 67 KiB in __dyndbg_sites section about 30Kib of the 67 is recoverable patchset, the short version: A- split __dyndbg in 2, isolate repeating module,file,function data. reach by new .site ptr. B- be safe if !.site C- work towards replacing .site with indexing on vectors: __dyndbgs & __dyndbg_sites c1 add ._index c2 use .index to get to __dyndbgs[0] ( then -> sites[._index] ) c3 insert header record at __dyndbgs[0] c4 rework header to differentiate from struct _ddebug, keep .site c5 drop .site, use indirection to get sites[._index] D- split _index into 2 jobs; _back (to [0]) and _map (to [N]) E- find duplicate site recs e1 - use just 1st of duplicate blocks e2 - in modules, move new site recs into front of sites vector e3 - in builtins, pack the whole sites vector, not just within the module-blocks So that leaves about 40% of __dyndbg_sites unneeded. How to return this to free memory ? FWIW, I tried krealloc on a module's chunk of memory (as attached by module:load_info()) it might have worked if that chunk was kallocd separately by elf-loader code. It evidently was not. PS: questions welcome here, reviews probably best at lkml ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
why does an in-tree loadable module taint the kernel
serio_raw is apparently tainting the kernel when its modprobed. why ? other modules load properly, no code changes to this module bash-5.1# dmesg | grep -i taint [6.517150] serio_raw: module verification failed: signature and/or required key missing - tainting kernel [7.449072] CPU: 0 PID: 203 Comm: systemd-udevd Tainted: G E 5.13.0-rc6-lm1-4-g28dc6f490a7f #106 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: why does an in-tree loadable module taint the kernel
On Mon, Jun 14, 2021 at 1:20 AM Greg KH wrote:
>
> On Mon, Jun 14, 2021 at 01:09:25AM -0600, jim.cro...@gmail.com wrote:
> > serio_raw is apparently tainting the kernel when its modprobed.
> > why ? other modules load properly, no code changes to this module
> >
> > bash-5.1# dmesg | grep -i taint
> > [6.517150] serio_raw: module verification failed: signature and/or
> > required key missing - tainting kernel
>
> You did not build this with the correct module signing key that your
> kernel was built with. That is what this warning is showing you, try
> building all modules with the same key as your kernel had and you should
> be fine.
>
OK, I understand better now -
its nothing wrong with serio_raw, its just the 1st module to load,
and warning comes just once.
kernel/module.c
3962: pr_notice_once("%s: module verification failed: signature "
Whats odd is that the same module has a signature when modinfo'd in
the kernel running the laptop, but not from the same kernel running inside a VM.
Does this constitute a bug of some sort ?
A pretty small one, likely fixable by changing CONFIG_SECURITY etc.
For anyone else needing to decode a taint:
https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html
> thanks,
>
> greg k-h
thank you
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: why does an in-tree loadable module taint the kernel
On Tue, Jun 15, 2021 at 10:24 AM Greg KH wrote:
>
> On Tue, Jun 15, 2021 at 10:06:08AM -0600, jim.cro...@gmail.com wrote:
> > On Mon, Jun 14, 2021 at 1:20 AM Greg KH wrote:
> > >
> > > On Mon, Jun 14, 2021 at 01:09:25AM -0600, jim.cro...@gmail.com wrote:
> > > > serio_raw is apparently tainting the kernel when its modprobed.
> > > > why ? other modules load properly, no code changes to this module
> > > >
> > > > bash-5.1# dmesg | grep -i taint
> > > > [6.517150] serio_raw: module verification failed: signature and/or
> > > > required key missing - tainting kernel
> > >
> > > You did not build this with the correct module signing key that your
> > > kernel was built with. That is what this warning is showing you, try
> > > building all modules with the same key as your kernel had and you should
> > > be fine.
> > >
> >
> > OK, I understand better now -
> >
> > its nothing wrong with serio_raw, its just the 1st module to load,
> > and warning comes just once.
> > kernel/module.c
> > 3962: pr_notice_once("%s: module verification failed: signature "
> >
> > Whats odd is that the same module has a signature when modinfo'd in
> > the kernel running the laptop, but not from the same kernel running inside
> > a VM.
> > Does this constitute a bug of some sort ?
>
> I do not understand, what is different here and what is not working
> properly?
>
I have built and installed 5.13-rc6 onto my laptop, Im running it now.
When I modinfo something, it shows a signature
[jimc@frodo ~]$ modinfo pcspkr
filename:
/lib/modules/5.13.0-rc6-lm1-4-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
alias: platform:pcspkr
license:GPL
description:PC Speaker beeper driver
author: Vojtech Pavlik
depends:
retpoline: Y
intree: Y
name: pcspkr
vermagic: 5.13.0-rc6-lm1-4-g28dc6f490a7f SMP mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key:73:9F:4D:24:D7:05:0A:55:AE:5C:B1:F6:52:B1:BA:E0:5C:68:32:36
sig_hashalgo: sha512
signature: 47:10:D7:A0:79:BE:B5:24:B1:BE:7F:53:8D:EF:4E:73:BD:39:5C:B4:
CB:7A:CD:3F:C8:96:E4:7A:72:17:A0:2B:42:63:5A:0F:F6:8B:70:7E:
...
when I run precisely the same kernel inside a virtme/kvm/qemu VM,
the same modinfo lacks that sig stuff
Note that vermagic matches exactly
bash-5.1# modinfo pcspkr
filename:
/lib/modules/5.13.0-rc6-lm1-4-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
alias: platform:pcspkr
license:GPL
description:PC Speaker beeper driver
author: Vojtech Pavlik
depends:
retpoline: Y
intree: Y
name: pcspkr
vermagic: 5.13.0-rc6-lm1-4-g28dc6f490a7f SMP mod_unload
bash-5.1#
> If you rebuild modules for a kernel without having the key, yes, you
> will get this warning. You have to have the same key here.
heres how Ive configured:
- copy distro .config from /boot (Fedora)
- make localmodconfig (to drop building parts I wont need)
- virtme-configkernel --update (to get support for 9P, virtio etc to
mount host disks)
all the SECURITY stuff came from the distro config,
I havent yet tried to unconfigure it.
I havent done anything specific with keys, I dont know why whatever
key is involved
is not available for both scenarios.
here's the relevant (I hope) config items:
[jimc@frodo local-i915m]$ grep SALT .config
CONFIG_BUILD_SALT="5.8.12-200.fc32.x86_64"
[jimc@frodo local-i915m]$ grep _KEY .config | grep -v '#'
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y
CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYS=y
CONFIG_KEYS_REQUEST_CACHE=y
CONFIG_PERSISTENT_KEYRINGS=y
CONFIG_ENCRYPTED_KEYS=y
CONFIG_KEY_DH_OPERATIONS=y
CONFIG_KEY_NOTIFICATIONS=y
CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
CONFIG_INTEGRITY_TRUSTED_KEYRING=y
CONFIG_INTEGRITY_PLATFORM_KEYRING=y
CONFIG_LOAD_UEFI_KEYS=y
CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
CONFIG_SECONDARY_TRUSTED_KEYRING=y
CONFIG_SYSTEM_BLACKLIST_KEYRING=y
[jimc@frodo local-i915m]$
[jimc@frodo local-i915m]$ grep SECURITY .config | grep -v '#'
CONFIG_IP_NF_SECURITY=m
CONFIG_IP6_NF_SECURITY=m
CONFIG_EXT4_FS_SECURITY=y
CONFIG_SECURITY=y
CONFIG_SECURITY_WRITABLE_HOOKS=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0
CONFIG_SECURITY_SELINUX_SIDTAB_HASH_BITS=9
CONFIG_SECURITY_SELINUX_SID2STR_CACHE_SIZE=256
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
CONFIG_DEFAULT_SECURITY_SELINUX=y
_
Re: why does an in-tree loadable module taint the kernel
On Wed, Jun 16, 2021 at 2:05 AM Greg KH wrote:
>
> On Tue, Jun 15, 2021 at 12:26:19PM -0600, jim.cro...@gmail.com wrote:
> > On Tue, Jun 15, 2021 at 10:24 AM Greg KH wrote:
> > >
> > > On Tue, Jun 15, 2021 at 10:06:08AM -0600, jim.cro...@gmail.com wrote:
> > > > On Mon, Jun 14, 2021 at 1:20 AM Greg KH wrote:
> > > > >
> > > > > On Mon, Jun 14, 2021 at 01:09:25AM -0600, jim.cro...@gmail.com wrote:
> > > > > > serio_raw is apparently tainting the kernel when its modprobed.
> > > > > > why ? other modules load properly, no code changes to this module
> > > > > >
> > > > > > bash-5.1# dmesg | grep -i taint
> > > > > > [6.517150] serio_raw: module verification failed: signature
> > > > > > and/or
> > > > > > required key missing - tainting kernel
> > > > >
> > > > > You did not build this with the correct module signing key that your
> > > > > kernel was built with. That is what this warning is showing you, try
> > > > > building all modules with the same key as your kernel had and you
> > > > > should
> > > > > be fine.
> > > > >
> > > >
> > > > OK, I understand better now -
> > > >
> > > > its nothing wrong with serio_raw, its just the 1st module to load,
> > > > and warning comes just once.
> > > > kernel/module.c
> > > > 3962: pr_notice_once("%s: module verification failed: signature "
> > > >
> > > > Whats odd is that the same module has a signature when modinfo'd in
> > > > the kernel running the laptop, but not from the same kernel running
> > > > inside a VM.
> > > > Does this constitute a bug of some sort ?
> > >
> > > I do not understand, what is different here and what is not working
> > > properly?
> > >
> >
> > I have built and installed 5.13-rc6 onto my laptop, Im running it now.
> > When I modinfo something, it shows a signature
> >
> > [jimc@frodo ~]$ modinfo pcspkr
> > filename:
> > /lib/modules/5.13.0-rc6-lm1-4-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
> > alias: platform:pcspkr
> > license:GPL
> > description:PC Speaker beeper driver
> > author: Vojtech Pavlik
> > depends:
> > retpoline: Y
> > intree: Y
> > name: pcspkr
> > vermagic: 5.13.0-rc6-lm1-4-g28dc6f490a7f SMP mod_unload
> > sig_id: PKCS#7
> > signer: Build time autogenerated kernel key
> > sig_key:73:9F:4D:24:D7:05:0A:55:AE:5C:B1:F6:52:B1:BA:E0:5C:68:32:36
> > sig_hashalgo: sha512
> > signature: 47:10:D7:A0:79:BE:B5:24:B1:BE:7F:53:8D:EF:4E:73:BD:39:5C:B4:
> > CB:7A:CD:3F:C8:96:E4:7A:72:17:A0:2B:42:63:5A:0F:F6:8B:70:7E:
> > ...
> >
> > when I run precisely the same kernel inside a virtme/kvm/qemu VM,
> > the same modinfo lacks that sig stuff
> > Note that vermagic matches exactly
> >
> > bash-5.1# modinfo pcspkr
> > filename:
> > /lib/modules/5.13.0-rc6-lm1-4-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
> > alias: platform:pcspkr
> > license:GPL
> > description:PC Speaker beeper driver
> > author: Vojtech Pavlik
> > depends:
> > retpoline: Y
> > intree: Y
> > name: pcspkr
> > vermagic: 5.13.0-rc6-lm1-4-g28dc6f490a7f SMP mod_unload
> > bash-5.1#
>
>
> Are you sure the modinfo you are running inside the vm knows to read the
> signature information? Odds are a busybox/toybox modinfo does not know
> this type of thing. Let me check:
>
> $ ./busybox modinfo visor | grep signature
> $ modinfo visor | grep signature
> signature: 51:F5:13:E1:F9:49:FA:20:68:45:F8:32:67:E2:4D:9C:DD:B6:55:EA:
>
> Yup, busybox does not know about these things.
>
that is interesting. Its not the reason here, IIUC.
Im using virtme for my VM,
its big advantage is that it remounts the host system disks,
so you get your whole home/host environment unchanged.
Theres also no need to install a kernel to run it in the VM,
I just happen to have installed the same kernel to run the whole laptop,
(more to test my patches than to chase down this particular weirdness)
> Is the md5sum the same for these modules?
Yes. module is same, so is cksum /sbin/modinfo
> > > If you rebuild modules for a kernel without having the key, yes, you
> > > will get this warning. You have to have the same key here.
> >
> > heres how Ive configured:
> > - copy distro .config from /boot (Fedora)
> > - make localmodconfig (to drop building parts I wont need)
> > - virtme-configkernel --update (to get support for 9P, virtio etc to
> > mount host disks)
> >
> > all the SECURITY stuff came from the distro config,
> > I havent yet tried to unconfigure it.
> >
> > I havent done anything specific with keys, I dont know why whatever
> > key is involved
> > is not available for both scenarios.
> > here's the relevant (I hope) config items:
>
> Look at the CONFIG_MODULE_SIG* items, that's the relevant ones.
>
> Here's what I use in my custom kernels for my systems:
>
> $ zcat /proc/config.gz | grep MODULE_SIG
> CONFIG_MODULE_SIG_FORMAT=y
> CONFIG_MODULE_SIG=y
> CONFIG_MODULE_SIG_FORCE=y
> CONFIG_MODULE
Re: why does an in-tree loadable module taint the kernel
On Wed, Jun 16, 2021 at 11:50 AM wrote:
>
> On Wed, Jun 16, 2021 at 2:05 AM Greg KH wrote:
> >
> > On Tue, Jun 15, 2021 at 12:26:19PM -0600, jim.cro...@gmail.com wrote:
> > > On Tue, Jun 15, 2021 at 10:24 AM Greg KH wrote:
> > > >
> > > > On Tue, Jun 15, 2021 at 10:06:08AM -0600, jim.cro...@gmail.com wrote:
> > > > > On Mon, Jun 14, 2021 at 1:20 AM Greg KH wrote:
> > > > > >
> > > > > > On Mon, Jun 14, 2021 at 01:09:25AM -0600, jim.cro...@gmail.com
> > > > > > wrote:
> > > > > > > serio_raw is apparently tainting the kernel when its modprobed.
> > > > > > > why ? other modules load properly, no code changes to this module
> > > > > > >
> > > > > > > bash-5.1# dmesg | grep -i taint
> > > > > > > [6.517150] serio_raw: module verification failed: signature
> > > > > > > and/or
> > > > > > > required key missing - tainting kernel
> > > > > >
> > > > > > You did not build this with the correct module signing key that your
> > > > > > kernel was built with. That is what this warning is showing you,
> > > > > > try
> > > > > > building all modules with the same key as your kernel had and you
> > > > > > should
> > > > > > be fine.
> > > > > >
> > > > >
> > > > > OK, I understand better now -
> > > > >
> > > > > its nothing wrong with serio_raw, its just the 1st module to load,
> > > > > and warning comes just once.
> > > > > kernel/module.c
> > > > > 3962: pr_notice_once("%s: module verification failed: signature "
> > > > >
> > > > > Whats odd is that the same module has a signature when modinfo'd in
> > > > > the kernel running the laptop, but not from the same kernel running
> > > > > inside a VM.
> > > > > Does this constitute a bug of some sort ?
> > > >
> > > > I do not understand, what is different here and what is not working
> > > > properly?
> > > >
> > >
> > > I have built and installed 5.13-rc6 onto my laptop, Im running it now.
> > > When I modinfo something, it shows a signature
> > >
> > > [jimc@frodo ~]$ modinfo pcspkr
> > > filename:
> > > /lib/modules/5.13.0-rc6-lm1-4-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
> > > alias: platform:pcspkr
> > > license:GPL
> > > description:PC Speaker beeper driver
> > > author: Vojtech Pavlik
> > > depends:
> > > retpoline: Y
> > > intree: Y
> > > name: pcspkr
> > > vermagic: 5.13.0-rc6-lm1-4-g28dc6f490a7f SMP mod_unload
> > > sig_id: PKCS#7
> > > signer: Build time autogenerated kernel key
> > > sig_key:
> > > 73:9F:4D:24:D7:05:0A:55:AE:5C:B1:F6:52:B1:BA:E0:5C:68:32:36
> > > sig_hashalgo: sha512
> > > signature:
> > > 47:10:D7:A0:79:BE:B5:24:B1:BE:7F:53:8D:EF:4E:73:BD:39:5C:B4:
> > > CB:7A:CD:3F:C8:96:E4:7A:72:17:A0:2B:42:63:5A:0F:F6:8B:70:7E:
> > > ...
> > >
> > > when I run precisely the same kernel inside a virtme/kvm/qemu VM,
> > > the same modinfo lacks that sig stuff
> > > Note that vermagic matches exactly
> > >
> > > bash-5.1# modinfo pcspkr
> > > filename:
> > > /lib/modules/5.13.0-rc6-lm1-4-g28dc6f490a7f/kernel/drivers/input/misc/pcspkr.ko
> > > alias: platform:pcspkr
> > > license:GPL
> > > description:PC Speaker beeper driver
> > > author: Vojtech Pavlik
> > > depends:
> > > retpoline: Y
> > > intree: Y
> > > name: pcspkr
> > > vermagic: 5.13.0-rc6-lm1-4-g28dc6f490a7f SMP mod_unload
> > > bash-5.1#
> >
> >
> > Are you sure the modinfo you are running inside the vm knows to read the
> > signature information? Odds are a busybox/toybox modinfo does not know
> > this type of thing. Let me check:
> >
> > $ ./busybox modinfo visor | grep signature
> > $ modinfo visor | grep signature
> > signature: 51:F5:13:E1:F9:49:FA:20:68:45:F8:32:67:E2:4D:9C:DD:B6:55:EA:
> >
> > Yup, busybox does not know about these things.
> >
>
> that is interesting. Its not the reason here, IIUC.
>
> Im using virtme for my VM,
> its big advantage is that it remounts the host system disks,
> so you get your whole home/host environment unchanged.
> Theres also no need to install a kernel to run it in the VM,
> I just happen to have installed the same kernel to run the whole laptop,
> (more to test my patches than to chase down this particular weirdness)
>
virtme-init: basic initialization done
virtme-init: running systemd-tmpfiles
Failed to create directory or subvolume "/var/spool/cups/tmp": Permission denied
Failed to open directory 'portables': Permission denied
Failed to open directory 'machines': Permission denied
Failed to open directory 'private': Permission denied
Failed to open directory 'private': Permission denied
systemd-tmpfile (184) used greatest stack depth: 26448 bytes left
virtme-init: starting udevd
Starting version v248.3-1.fc34
Im gonna handwave a key visibilty problem causing my wierdness
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
advice on a bisect
I have an old 686 machine, running fedora 30 (last fedora supporting 686) processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz stepping : 10 microcode : 0xa0b cpu MHz : 1614.044 cache size : 3072 KB I generally keep it with a fresh kernel at least, [jimc@popeye linux]$ uname -a Linux popeye 5.13.0-rc5-j1-00030-g4c8684fe555e #210 SMP Tue Jun 15 16:56:40 MDT 2021 i686 i686 i386 GNU/Linux recently, I found it wouldnt boot, so bisected. [jimc@popeye linux]$ git bisect log git bisect start # bad: [009c9aa5be652675a06d5211e1640e02bbb1c33d] Linux 5.13-rc6 git bisect bad 009c9aa5be652675a06d5211e1640e02bbb1c33d # good: [8124c8a6b35386f73523d27eacb71b5364a68c4c] Linux 5.13-rc4 git bisect good 8124c8a6b35386f73523d27eacb71b5364a68c4c # good: [bd7b12aa6081c3755b693755d608f58e13798a60] Merge tag 'powerpc-5.13-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux git bisect good bd7b12aa6081c3755b693755d608f58e13798a60 # bad: [fd2cd569a4363581c00b8a2f4f26275e5562] Merge tag 'sound-5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad fd2cd569a4363581c00b8a2f4f26275e5562 # good: [9bfa80df22c8cb6f9f8634693812cb958f4f] Merge tag 'regulator-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator git bisect good 9bfa80df22c8cb6f9f8634693812cb958f4f # bad: [cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9] Merge tag 'platform-drivers-x86-v5.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 git bisect bad cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9 # bad: [2f673816b2db30ce6122fe0e5e6a00de20e8d99a] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect bad 2f673816b2db30ce6122fe0e5e6a00de20e8d99a # bad: [368094df48e680fa51cedb68537408cfa64b788e] Merge tag 'for-linus-5.13b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip git bisect bad 368094df48e680fa51cedb68537408cfa64b788e # good: [4c8684fe555e95100030bd330d0a2780ac27952e] Merge tag 'spi-fix-v5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi git bisect good 4c8684fe555e95100030bd330d0a2780ac27952e # good: [d4c6399900364facd84c9e35ce1540b6046c345f] vmlinux.lds.h: Avoid orphan section with !SMP git bisect good d4c6399900364facd84c9e35ce1540b6046c345f # good: [374aeb91db48bb52216bb9308d611c816fb6cacb] Merge tag 'orphans-v5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux git bisect good 374aeb91db48bb52216bb9308d611c816fb6cacb # good: [107866a8eb0b664675a260f1ba0655010fac1e08] xen-netback: take a reference to the RX task thread git bisect good 107866a8eb0b664675a260f1ba0655010fac1e08 # first bad commit: [368094df48e680fa51cedb68537408cfa64b788e] Merge tag 'for-linus-5.13b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip [jimc@popeye linux]$ after bisecting (long time, not much effort) I booted the "bad" kernel to single user (added 'S' to end of bootline - is this universal ?) and poked around, so failure is more subtle than total. by casual observation, boot hangs at dbus startup the bad-booting kernel does manage to log its progress, journalct -b-1 shows : Jun 17 03:06:11 popeye kernel: Run /init as init process Jun 17 03:06:11 popeye kernel: with arguments: Jun 17 03:06:11 popeye kernel: /init Jun 17 03:06:11 popeye kernel: rhgb Jun 17 03:06:11 popeye kernel: 2 Jun 17 03:06:11 popeye kernel: with environment: Jun 17 03:06:11 popeye kernel: HOME=/ Jun 17 03:06:11 popeye kernel: TERM=linux Jun 17 03:06:11 popeye kernel: BOOT_IMAGE=/vmlinuz-5.13.0-rc6-cln Jun 17 03:06:14 popeye systemd[1]: Started Plymouth switch root service. Jun 17 03:06:14 popeye audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-switch> Jun 17 03:06:14 popeye audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-switch-> Jun 17 03:06:14 popeye systemd[1]: Starting Switch Root... Jun 17 03:06:14 popeye systemd[1]: Switching root. Jun 17 03:06:14 popeye systemd-journald[131]: Journal stopped Jun 17 09:06:22 popeye systemd-journald[131]: Received SIGTERM from PID 1 (systemd). Jun 17 09:06:22 popeye kernel: printk: systemd: 18 output lines suppressed due to ratelimiting Jun 17 09:06:22 popeye kernel: kauditd_printk_skb: 21 callbacks suppressed Jun 17 09:06:22 popeye kernel: audit: type=1404 audit(1623920776.499:32): enforcing=1 old_enforcing=0 auid=4294967295 ses=42949> Jun 17 09:06:22 popeye kernel: SELinux: Permission watch in class filesystem not defined in policy. Jun 17 09:06:22 popeye kernel: SELinux: Permission watch in class file not defined in policy. (at end) Jun 17 09:06:33 popeye systemd-logind[617]: Watching system buttons on /dev/input/event0 (Power Button) Jun 17 09:06:33 popeye systemd-logind[617]: Watching system buttons on /dev/input/event2 (USB USB Keykoard) Jun 17 09:06:33 popeye systemd-l
Re: Seeking advice on "monkey patching" a driver
On Thu, Jul 1, 2021 at 2:03 PM Ian Pilcher wrote: > > On 7/1/21 12:59 PM, Greg KH wrote: > > Oh that's horrible, please no, do not do that :) > > Indeed it is, but it works, and it meets my main objective, which is to > allow the use of distribution kernel packages and modules. > > > How about a third option, the correct one: > > - submit your code changes upstream and they get merged into the > > main kernel tree and no monkeypatching is ever needed at all! > > > > Have you submitted your changes upstream to the existing drivers? What > > is preventing that from happening today? > > There are a couple of reasons that I've never attempted to do this. > > * Scope of work - Currently, there is simply no mechanism to call an LED > * (Probable) lack of upstream interest - As I mentioned, disk activity >LEDs really ought to be handled by the hardware. Are LEDs really that important? Unless theyre rigged intrinsically into the operation, it seems tertiary I don't know of any >other system that suffers from this particular limitation. So this >is a very, very niche use case. (Most users of this hardware use the >manufacturer's "firmware".) > >I did ask about this on the linux-ide mailing list long ago when I >first wrote the modules, but I don't think that I ever received a >response, which reinforces my belief that upstream isn't likely to be >receptive. > theres a firehose of patches. FWIW, now robots watch the list, and will grind your patches on lots of configs. arches > I've invested significant time in kernel patches in the past, only to > see them ultimately not be accepted, so I would need to know that > upstream was truly interested in such a feature before I would consider > making such a commitment. > no guarantees, but there is staging. (here, more or less) provisional home for code while quality develops once youre in-tree, warts and all (to some extent, I dont know) you may well get help (patches) improving it, surely lots of feedback. elsewhere, nobody knows it exists. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
laptop iwlwifi suddenly not working
while fumbling to pause grub during boot, I think I managed to disable the wifi. its affecting distro kernel, and my own booting with iwlwifi.debug=0xff on command line shows me iwl_pcie_apm_init Init card's basic functions reporting RF_KILL (radio disabled) It is reading that from somewhere, but where ? F12 has radio-beacon icon, pressing it causes WM to show Airplane mode, so that appears to be the rfr-kill switch dmesg -w shows me bluetooth going on and off, but no try to do so on iwlwifi are there other rf-switches ? I also tried reboot, F2 - (uefi bios) reset factory, reboot that obviously didnt help FWIW this laptop exhibits pcie correctable errors, I have pci=noaer in my boot line to ignore it. too long ? iirc, it was on same pcie port removing it doesnt help now, ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: laptop iwlwifi suddenly not working
On Thu, Jul 1, 2021 at 3:49 PM wrote: > > while fumbling to pause grub during boot, > I think I managed to disable the wifi. > and booting a live usb gets same result ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
