Re: Linux Kernel readlink equivalent
>>
> Hello,
>
> I'm working on some linux kernel driver stuff and I have a fake path
> called /dev/blah/whatever that points to /dev/block/real_device.
>
> The issue is that lookup_bdev will fail to follow the symlink so I'd like
> to massage the path upfront by getting the real path
> (/dev/block/real_device) so I can hand that off to lookup_bdev so it
> returns successfully instead of an error.
>
> Or any other kernel call that would correctly retrieve the block_device
> information given the initial path which is a symlink.
>
> Note: I saw that the tomoyo module has something like that but I was
> looking for the generic implementation of the kernel if one exists.
>
> Thanks
>
> David
>
> David,
1 - Please read through: *man 2 readlink* ( yes please read it *all* very
carefully !
2 - There is a system call readlink study it...
declared here: http://code.woboq.org/linux/include/unistd.h.html#809
exported here:
http://code.woboq.org/linux/linux/arch/um/os-Linux/user_syms.c.html#83
3 grep through the kernel and see where and how readlink is used.
Try : find . -name "*.[ch]" | xargs grep "readlink"
and : find . -name "*.[ch]" | xargs grep " readlink("
and : find . -name "*.[ch]" | xargs grep ">readlink"
4 - This will help you figure how to work things out
use at
your own risk :)
Good luck - Aruna
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Kernel 2.6.32.60 64bit Crash/Hung
All, I Changed CONFIG_NR_CPUS=64 to CONFIG_NR_CPUS=128 and kernel did not panic. Please note my setup has 4CPUs , each has 10 cores and supports Hyper threading. So, linux creates 4 x 10 x 2 logical CPUs. Thanks Giri ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Propper use of pci_map_sg
Hi,
I am trying to use pci_map_sg in combination with get_user_pages_fast
for a driver. However my code screws the processes memory map over. For
easier testing I bundled the piinin/unpinning and mapping unmapping into
one ioctl call. The following code misses all the checks on return
values, since it is only inteneded as a MWE.
When I run my code I get a "*BUG: Bad page map in process ...*", after
"Done" is printed.
I tried following DMA-API-howto.txt and looking at other code, but I
fail to see where I go wrong.
Regards, Ted
Code from the IOCTL handler:
case IOCTL_FPGA_PIN_PAGE:
{
struct pageInfo pageInfo;
dev_dbg(&pcidev->dev, pr_fmt("IOCTL: IOCTL_FPGA_PIN_PAGE\n"));
if(!copy_from_user(&pageInfo, (void*)arg, sizeof(struct
pageInfo))) {
//horrible test
const int noPages = pageInfo.size/PAGE_SIZE;
int pinned;
int mapped = 0;
struct scatterlist* scatterlist;
printk("Test start\n");
//userspacestartpointer, nopages, write?, page* array
struct page** pages=kmalloc(sizeof(struct
page*)*noPages, GFP_KERNEL);
pinned=*get_user_pages_fast*((unsigned
long)pageInfo.start, noPages, 1, pages);
scatterlist = kmalloc(sizeof(struct
scatterlist)*pinned, GFP_KERNEL);
for(int i=0; imapped =*pci_map_sg*(pcidev, scatterlist, pinned,
DMA_BIDIRECTIONAL);
*pci_unmap_sg*(pcidev, scatterlist, pinned, DMA_BIDIRECTIONAL);
for(int i=0; i*put_page*(pages[i]); //I did place a print here and got two pages
unpinned as I expected
}
kfree(scatterlist);
kfree(pages);
printk("Done\n");
/*pageInfo.pageId = getPageId(getArea(&pageInfo));
copy_to_user((void*)arg, &pageInfo, sizeof(struct
pageInfo));*/
return pageInfo.pageId;
} else {
return -EFAULT;
}
}
break;
P.S.: I used the following code to allocate the memory in userspace, and
I use chunk and chunksize to fill pageInfo.start and pageInfo.size
respectivly:
const int pagesize = sysconf(_SC_PAGESIZE);
const int chunksize = 2*pagesize;
void* chunk;
if(int error = posix_memalign(&chunk, pagesize, chunksize)) {
std::cout << "Could not get a page." << std::endl;
return error;
}
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Linux Kernel readlink equivalent
On Thu, Jan 29, 2015 at 01:11:13PM -0500, David Legault wrote: > Hello, > > I'm working on some linux kernel driver stuff and I have a fake path called / > dev/blah/whatever that points to /dev/block/real_device. That's a userspace "path", right? Why would the kernel care about this? > The issue is that lookup_bdev will fail to follow the symlink so I'd like to > massage the path upfront by getting the real path (/dev/block/real_device) so > I > can hand that off to lookup_bdev so it returns successfully instead of an > error. Why are you calling this from within the kernel? You should have a bdev already directly within the kernel, no need to muck around in /dev/ What exactly are you doing that you feel you need access to a block device node? thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Linux Kernel readlink equivalent
On Thu, 29 Jan 2015 13:11:13 -0500, David Legault said: > I'm working on some linux kernel driver stuff and I have a fake path called > /dev/blah/whatever that points to /dev/block/real_device. And *why* is kernel code trying to follow a symlink, anyhow? (Hint: there's probably (a) data you want at the other end of the symlink and (b) a better kernel API for getting at that data, which is why you can't find examples of following symlinks. ;) pgp5W6l6EnnG2.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Linux Kernel readlink equivalent
Hello, I'm working on some linux kernel driver stuff and I have a fake path called /dev/blah/whatever that points to /dev/block/real_device. The issue is that lookup_bdev will fail to follow the symlink so I'd like to massage the path upfront by getting the real path (/dev/block/real_device) so I can hand that off to lookup_bdev so it returns successfully instead of an error. Or any other kernel call that would correctly retrieve the block_device information given the initial path which is a symlink. Note: I saw that the tomoyo module has something like that but I was looking for the generic implementation of the kernel if one exists. Thanks David ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Is this a good first patch for enabling screen rotation?
On Fri, 30 Jan 2015 00:45:30 +0800, Brock York said: (Note, I don't have an Acer, nor am I an HID expert... so take this all with a grain of salt...) > Swap the x and y values and negate the x value converting the > accelerometers coordinate system into the coordinate system > userspace udev expects. This part looks fishy... 1) I wasn't aware that udev had a coordinate system. I think you meant that something *else* was using values that udev passed to userspace. You probably want to clarify what you meant. 2) There obviously was *some* consumer of the input_report_abs() value before you added the kobject_uevent() call - convince us that said consumer is OK with its axes being twiddled like this. > input_report_abs(acer_wmi_accel_dev, ABS_X, > - (s16)out_obj->package.elements[0].integer.value); > + -(s16)out_obj->package.elements[1].integer.value); > input_report_abs(acer_wmi_accel_dev, ABS_Y, > - (s16)out_obj->package.elements[1].integer.value); > + (s16)out_obj->package.elements[0].integer.value); Other issues: 3) "when accelerometer position is updated." Is that going to generate a flood of events if (for example) you're walking with the device and it's swinging back and forth a bit? It's one thing to have HID devices generating a near-constant stream of updates for mouse tracking and so on - it's a whole 'nother can of worms to additionally bash udev with an update stream. Perhaps udev events should be clamped to only trigger when it's time for an actual axis swap? 4) This should probably be 2 patches - one to swap the input_report_abs() values, and a second to add the kobject_uevent() call. 5) I almost have to wonder if the input_report_abs() part is sufficient, and udev events aren't needed? pgpKwgImaRCTj.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Is this a good first patch for enabling screen rotation?
Hello This is my first patch and after speaking to a few kernel devs at LCA2015 I thought I would ask here for some advice on if I have followed the newbie guide correctly. The patch is to get automatic screen rotation working on a acer iconia w500 tablet. The patch was made against linux-next branch next-20150129 and successfully built and ran. Do you think this is a succificient patch to get accepted by the platform-x86 maintainers? I used get_maintainer.pl and it suggested the platform-x86 mailing list. Thank you, any help is much appreciated. Regards Brock York. BEGIN PATCH BELOW Subject: [PATCH] acer-wmi: Enable screen auto-rotation via udev Emit udev event via kobject_uevent when accelerometer position is updated. This is to allow userspace to grab the accelerometer position and rotate the screen accordingly. Swap the x and y values and negate the x value converting the accelerometers coordinate system into the coordinate system userspace udev expects. Accelerometer Expected Coordinates Coordinates x+ y+ ^ ^ | | | | y+</ />x+ / / z+ z+ Screen Orientation || || || Tested on a Acer Iconia W500 tablet with Gnome 3 Signed-off-by: Brock York --- drivers/platform/x86/acer-wmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c index 3ac29a1..d5678e4 100644 --- a/drivers/platform/x86/acer-wmi.c +++ b/drivers/platform/x86/acer-wmi.c @@ -1491,12 +1491,14 @@ static int acer_gsensor_event(void) return -1; input_report_abs(acer_wmi_accel_dev, ABS_X, - (s16)out_obj->package.elements[0].integer.value); + -(s16)out_obj->package.elements[1].integer.value); input_report_abs(acer_wmi_accel_dev, ABS_Y, - (s16)out_obj->package.elements[1].integer.value); + (s16)out_obj->package.elements[0].integer.value); input_report_abs(acer_wmi_accel_dev, ABS_Z, (s16)out_obj->package.elements[2].integer.value); input_sync(acer_wmi_accel_dev); + + kobject_uevent(&acer_wmi_accel_dev->dev.kobj, KOBJ_CHANGE); return 0; } -- 2.2.2 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Can I submit simple patches like this to the primary ML?
On Thu, Jan 29, 2015 at 09:27:48AM -0200, Vinícius Tinti wrote: > On Thu, Jan 29, 2015 at 3:07 AM, Greg KH wrote: > >> In fact it causes a warning on Clang which complains that: > >> > >>arch/x86/tools/relocs.c:977:6: warning: variable 'do_reloc' is used > >> uninitialized whenever 'if' condition is false > >> [-Wsometimes-uninitialized] > > > > I suggest you file a bug with clang, gcc doesn't have this problem at > > all as obviously, if you look at the code, that variable can never be > > used uninitialized. > > I can simply turn down this kind of warning. Or you can send a bug report to the clang developers so they can fix it, which would be best in the end, right? > >> I think there is not a problem on the current code but to avoid > >> further problems I believe it is worth to initialize this function > >> with NULL. > >> What do you think? > > > > Don't paper over bugs in the compiler with kernel code changes for no > > good reason :) > > Agreed. But whenever I find a warning in GCC during the build what > should I do with it? Depends on the specific warning, and what type of fix it requires. If you do see them, and you are running with the latest version of gcc, and the warning is for a problem that is real (hint, this problem was not real as the code showed), then yes, of course submit a patch for it. > Can I simply send it to the main ml? Use the scripts/get_maintainer.pl tool on your patch to determine who to send it to and what mailing lists to copy. Hope this helps, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Can I submit simple patches like this to the primary ML?
On Thu, Jan 29, 2015 at 12:27 PM, Vinícius Tinti wrote: > On Thu, Jan 29, 2015 at 3:07 AM, Greg KH wrote: > > On Thu, Jan 29, 2015 at 02:16:51AM -0200, Vinícius Tinti wrote: > >> On Thu, Jan 29, 2015 at 2:08 AM, Greg KH wrote: > >> > On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vinícius Tinti wrote: > >> >> This is a simple patch that initializes a function with NULL to > avoid some > >> >> compiler warnings. In such cases should I proceed as a normal patch > or it is > >> >> better to send to another ML like to one for trivial patches? > >> >> > >> >> Thanks, > >> >> > >> >> Tinti > >> > > >> >> >From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 > 2001 > >> >> From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= > >> >> Date: Thu, 29 Jan 2015 01:35:34 -0200 > >> >> Subject: [PATCH] x86: LLVMLinux: Fix uninitialized function do_reloc > >> >> MIME-Version: 1.0 > >> >> Content-Type: text/plain; charset=UTF-8 > >> >> Content-Transfer-Encoding: 8bit > >> >> > >> >> Explicit initializes do_reloc function with NULL. Later the function > is > >> >> either proper initialized of an error issued. > >> >> > >> >> Signed-off-by: Vinícius Tinti > >> >> --- > >> >> arch/x86/tools/relocs.c | 2 +- > >> >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> >> > >> >> diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c > >> >> index 0c2fae8..1d533f1 100644 > >> >> --- a/arch/x86/tools/relocs.c > >> >> +++ b/arch/x86/tools/relocs.c > >> >> @@ -971,7 +971,7 @@ static void emit_relocs(int as_text, int > use_real_mode) > >> >> int i; > >> >> int (*write_reloc)(uint32_t, FILE *) = write32; > >> >> int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym > *sym, > >> >> - const char *symname); > >> >> + const char *symname) = NULL; > >> > > >> > I think you need to get an updated version of the compiler as this > patch > >> > should not be needed at all. It doesn't cause a warning here for me > >> > without it. > >> > >> In fact it causes a warning on Clang which complains that: > >> > >>arch/x86/tools/relocs.c:977:6: warning: variable 'do_reloc' is used > >> uninitialized whenever 'if' condition is false > >> [-Wsometimes-uninitialized] > > > > I suggest you file a bug with clang, gcc doesn't have this problem at > > all as obviously, if you look at the code, that variable can never be > > used uninitialized. > > I can simply turn down this kind of warning. > > >> I think there is not a problem on the current code but to avoid > >> further problems I believe it is worth to initialize this function > >> with NULL. > >> What do you think? > > > > Don't paper over bugs in the compiler with kernel code changes for no > > good reason :) > > Agreed. But whenever I find a warning in GCC during the build what > should I do with it? > Can I simply send it to the main ml? > If you believe your patch is correct, and if checkpatch.pl doesn't complain about your patch, then get_maintainers.pl will tell you the people and mailing lists you should send your patch to. > > > thanks, > > > > greg k-h > > > > -- > Simplicity is the ultimate sophistication > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Peter ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Can I submit simple patches like this to the primary ML?
On Thu, Jan 29, 2015 at 3:07 AM, Greg KH wrote: > On Thu, Jan 29, 2015 at 02:16:51AM -0200, Vinícius Tinti wrote: >> On Thu, Jan 29, 2015 at 2:08 AM, Greg KH wrote: >> > On Thu, Jan 29, 2015 at 01:48:43AM -0200, Vinícius Tinti wrote: >> >> This is a simple patch that initializes a function with NULL to avoid some >> >> compiler warnings. In such cases should I proceed as a normal patch or it >> >> is >> >> better to send to another ML like to one for trivial patches? >> >> >> >> Thanks, >> >> >> >> Tinti >> > >> >> >From a391789bf44afbdbe2a7b3c76301b5ece9f72475 Mon Sep 17 00:00:00 2001 >> >> From: =?UTF-8?q?Vin=C3=ADcius=20Tinti?= >> >> Date: Thu, 29 Jan 2015 01:35:34 -0200 >> >> Subject: [PATCH] x86: LLVMLinux: Fix uninitialized function do_reloc >> >> MIME-Version: 1.0 >> >> Content-Type: text/plain; charset=UTF-8 >> >> Content-Transfer-Encoding: 8bit >> >> >> >> Explicit initializes do_reloc function with NULL. Later the function is >> >> either proper initialized of an error issued. >> >> >> >> Signed-off-by: Vinícius Tinti >> >> --- >> >> arch/x86/tools/relocs.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c >> >> index 0c2fae8..1d533f1 100644 >> >> --- a/arch/x86/tools/relocs.c >> >> +++ b/arch/x86/tools/relocs.c >> >> @@ -971,7 +971,7 @@ static void emit_relocs(int as_text, int >> >> use_real_mode) >> >> int i; >> >> int (*write_reloc)(uint32_t, FILE *) = write32; >> >> int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym, >> >> - const char *symname); >> >> + const char *symname) = NULL; >> > >> > I think you need to get an updated version of the compiler as this patch >> > should not be needed at all. It doesn't cause a warning here for me >> > without it. >> >> In fact it causes a warning on Clang which complains that: >> >>arch/x86/tools/relocs.c:977:6: warning: variable 'do_reloc' is used >> uninitialized whenever 'if' condition is false >> [-Wsometimes-uninitialized] > > I suggest you file a bug with clang, gcc doesn't have this problem at > all as obviously, if you look at the code, that variable can never be > used uninitialized. I can simply turn down this kind of warning. >> I think there is not a problem on the current code but to avoid >> further problems I believe it is worth to initialize this function >> with NULL. >> What do you think? > > Don't paper over bugs in the compiler with kernel code changes for no > good reason :) Agreed. But whenever I find a warning in GCC during the build what should I do with it? Can I simply send it to the main ml? > thanks, > > greg k-h -- Simplicity is the ultimate sophistication ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
