And though scary is exciting nice is different than good

| categories: uncategorized

I've been at Flock all week. This morning I was on a panel with other mentors/organizers for Fedora's outreach programs (Outreachy/Google Summer of Code). One of the questions for the panel was about career advice for getting a job in open source. Everyone had thoughtful responses. There was a lot of discussion about making sure you had good communication skills. There was also a quote about how there are enough smart people on the planet we need more friendly people. This felt really weird to me and I didn't say anything more on stage because I didn't really have my thoughts organized. I think it boils down to that phrase is a good goal but there's more to unpack there.

"Wow Laura, are you saying we should all be mean to each other?" No. If that's your first thought you probably should think about being friendlier. It's the fact that this seems to be a dichotomy. You either get to be smart or you get to be friendly, not both at the same time. This goes double (at least) for under represented groups in tech. I get depressed every time I read about another women in tech who is told she isn't "technical enough" (whatever that means) because she has good public speaking skills. I'm very tired of being told I'm intimidating for reasons that seem to boil down to I'm pretty good at my job. "Is this e-mail too aggressive because I didn't use emoji or am I not going to be taken seriously if I do use emoji" is always a fun thought process when attempting to write e-mail. Telling people to be "friendly" is lousy advice if you are from a group whose is penalized for not being friendly vs. a group who is rewarded when they are friendly.

The overall point about communication skills is generally good advice. I'd also couple it with advice for under represented groups to not sell yourself short in other areas too, you can have all the skills! I really liked the suggestion from the panel about blog posts. Writing gives you the chance to demonstrate your skills by showing how well you can communicate your ideas. What also needs to be emphasized is that communication skills are skills. You can learn communication skills. You can learn technical skills. You can learn non-technical skills. You can learn skills that don't fit into either of those boxes. Have a lot of skills and be friendly. Demand both from your coworkers, managers, and managees.


kmalloc and vmalloc

| categories: uncategorized

The kernel has the responsibility of setting up virtual to physical mappings for the system. This is something userspace processes take for granted and don't really think about. Most kernel drivers don't think about this either, except when it matters. Yes, that's delightfully vague and useless. One of the most common lines of code you will see in the kernel is an allocation from kmalloc:

struct foo *p = kmalloc(sizeof(*p), GFP_KERNEL);

There are assumptions that can be made about a pointer returned from kmalloc1. The pointer is a virtual address. This sounds obvious but it's important to keep in mind what that actually means. A pointer returned from kmalloc is going to be linearly mapped in the page tables. This means the physical address of a linear virtual address can be found by doing simple arithmetic. A pointer returned from kmalloc is going to be physically contiguous. Contrast that with vmalloc:

void *p = vmalloc(SZ_512K);

The virtual address returned from vmalloc is going to be virtually contiguous but physically discontiguous. The physical pages that are backing vmalloc have no relation to the virtual address. Instead of simple arithmetic to get the physical address, you have to walk the page table to get the physical address for a particular PAGE_SIZE.

Both vmalloc and kmalloc have their uses. kmalloc is generally preferred as the overhead is lower. The linear mapping is set up at boot time and generally not adjusted. vmalloc is allocated and mapped and mapped at run time. Because kmalloc is physically contiguous, it's subject to fragmentation. As allocation size goes up, it may be necessary to switch to vmalloc for the allocation to succeed.

Unexpected behavior happens if you pass a vmalloc address to an API that's not expecting it. Unexpected really means unexpected here. arm64 will happily take a non-linear address and perform a linear translation on it. What you get back may be a physical address but it has no relation to the virtual address you passed in. There are some debug options to catch bad uses of the API and BUG out, but those are expensive and not commonly turned on.

In conclusion, know what type of memory you are allocating and where it can be used. Don't blindly call virt_to_phys on random pointers unless you like debugging subtle problems.


  1. I'm mostly going to be talking about x86 and arm64 with CONFIG_MMU here. Most of this should hold for other architectures but I learn something new and exciting every day. 


Hello World!

| categories: uncategorized

This is the start of my blog. I expect it will be updated as often as most of the blogs out there on the internet.