Re: [PATCH] drivers: pnp: proc.c: Handle errors while attaching devices
On Thu, Apr 29, 2021 at 12:31:13AM -0400, Valdis Klētnieks wrote: > On Tue, 27 Apr 2021 07:26:27 +0300, Leon Romanovsky said: > > On Mon, Apr 26, 2021 at 11:20:32PM +0530, bkkarthik wrote: > > > These were only intended for a clean-up job, the idea of this function > > > came from how PCI handles procfs. > > > Maybe those should be changed? > > > > Probably, the CONFIG_PROC_FS around pci_proc_*() is not needed too. > > Will that actually build correctly if it's an embedded system or something > build with > CONFIG_PROC_FS=n? I'd expect that to die a horrid death while linking vmlinx > due > to stuff inside that #ifdef calling symbols only present with PROC_FS=m/y. We are talking about pci_proc_detach_device() and pci_proc_detach_bus() here. They will build perfectly without CONFIG_PROC_FS. Thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] MAINTAINERS: mark isapnp as obsolete
On Wed, Apr 28, 2021 at 02:17:00PM +0200, Jaroslav Kysela wrote: > Dne 28. 04. 21 v 13:11 Greg KH napsal(a): > > On Wed, Apr 28, 2021 at 04:35:36PM +0530, Anupama K Patil wrote: > >> isapnp code is very old and according to this link > >> https://en.wikipedia.org/wiki/Legacy_Plug_and_Play#Specifications > >> from Wikipedia, even Windows Vista disabled ISA PnP by default. > >> > >> This change is in follow up to > >> https://lore.kernel.org/lkml/20210422180322.7wlyg63kv3n2k6id@ubuntu/T/#u > >> and > >> https://lore.kernel.org/lkml/20210424194301.jmsqpycvsm7izbk3@ubuntu/T/#u > >> > >> Suggested-by: B K Karthik > >> Signed-off-by: Anupama K Patil > > > > Has the maintainer said this is unsupported? > > I've no idea, if there're any users at the time, but there are many drivers > which depend on this code. IMHO, this is exactly "Odd fixes" - code not really dead, but not really alive too. Thanks > > I'll try to reply to patch threads. > > Jaroslav > > -- > Jaroslav Kysela > Linux Sound Maintainer; ALSA Project; Red Hat, Inc. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] drivers: pnp: proc.c: Handle errors while attaching devices
On Wed, Apr 28, 2021 at 02:04:49PM +0200, Jaroslav Kysela wrote:
> Dne 26. 04. 21 v 19:50 bkkarthik napsal(a):
> > On 21/04/26 08:04AM, Leon Romanovsky wrote:
> >> On Sun, Apr 25, 2021 at 01:13:01AM +0530, Anupama K Patil wrote:
> >>> isapnp_proc_init() does not look at the return value from
> >>> isapnp_proc_attach_device(). Check for this return value in
> >>> isapnp_proc_detach_device().
> >>>
> >>> Cleanup in isapnp_proc_detach_device and
> >>> isapnp_proc_detach_bus() for cleanup.
> >>>
> >>> Changed sprintf() to the kernel-space function scnprintf() as it returns
> >>> the actual number of bytes written.
> >>>
> >>> Removed unnecessary variables de, e of type 'struct proc_dir_entry' to
> >>> save memory.
> >>
> >> What exactly do you fix for such an old code?
> >
> > I was not aware that this code is so old. This fix was made after
> > checkpatch reported assignment inside an if-statement.
> > Please ignore this patch if th change is not necessary as the code is
> > probably not being used anywhere :)
> >
> > Maybe the code has to be marked as obsolete in the MAINTAINERS file to
> > prevent patches being sent?
> >
> >>
> >>>
> >>> Suggested-by: Shuah Khan
> >>> Co-developed-by: B K Karthik
> >>> Signed-off-by: B K Karthik
> >>> Signed-off-by: Anupama K Patil
> >>> ---
> >>> drivers/pnp/isapnp/proc.c | 40 +--
> >>> 1 file changed, 30 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/pnp/isapnp/proc.c b/drivers/pnp/isapnp/proc.c
> >>> index 785a796430fa..46ebc24175b7 100644
> >>> --- a/drivers/pnp/isapnp/proc.c
> >>> +++ b/drivers/pnp/isapnp/proc.c
> >>> @@ -54,34 +54,54 @@ static const struct proc_ops isapnp_proc_bus_proc_ops
> >>> = {
> >>> .proc_read = isapnp_proc_bus_read,
> >>> };
> >>>
> >>> +static int isapnp_proc_detach_device(struct pnp_dev *dev)
> >>> +{
> >>> + proc_remove(dev->procent);
> >>> + dev->procent = NULL;
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int isapnp_proc_detach_bus(struct pnp_card *bus)
> >>> +{
> >>> + proc_remove(bus->procdir);
> >>> + return 0;
> >>> +}
> >>
> >> Please don't add one line functions that are called only once and have
> >> return value that no one care about it.
> >
> > These were only intended for a clean-up job, the idea of this function came
> > from how PCI handles procfs.
> > Maybe those should be changed?
>
> Which code you refer? I see:
>
>for_each_pci_dev(dev)
> pci_proc_attach_device(dev);
He talks about isapnp_proc_detach_*() functions.
>
>
> The error codes are ignored, too. It does not harm, if proc entries are not
> created (in this case - the system is unstable anyway). We should concentrate
> only to the wrong pointers usage.
>
> Jaroslav
>
> --
> Jaroslav Kysela
> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] MAINTAINERS: mark isapnp as obsolete
On Wed, Apr 28, 2021 at 05:43:29PM +0530, Anupama K Patil wrote: > On 21/04/28 02:48PM, Leon Romanovsky wrote: > > On Wed, Apr 28, 2021 at 05:10:57PM +0530, Anupama K Patil wrote: > > > On 21/04/28 01:11PM, Greg KH wrote: > > > > On Wed, Apr 28, 2021 at 04:35:36PM +0530, Anupama K Patil wrote: > > > > > isapnp code is very old and according to this link > > > > > https://en.wikipedia.org/wiki/Legacy_Plug_and_Play#Specifications > > > > > from Wikipedia, even Windows Vista disabled ISA PnP by default. > > > > > > > > > > This change is in follow up to > > > > > https://lore.kernel.org/lkml/20210422180322.7wlyg63kv3n2k6id@ubuntu/T/#u > > > > > and > > > > > https://lore.kernel.org/lkml/20210424194301.jmsqpycvsm7izbk3@ubuntu/T/#u > > > > > > > > > > Suggested-by: B K Karthik > > > > > Signed-off-by: Anupama K Patil > > > > > > > > Has the maintainer said this is unsupported? > > > > > > > > That's who you should take suggestions from :) > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > Leon said he thinks it is unsupported (I've also cc'd him). So, I've sent > > > this patch > > > to get the feedback from the maintainer. > > > > Leon said something different. > > https://lore.kernel.org/lkml/20210422180322.7wlyg63kv3n2k6id@ubuntu/T/#m6c837180c8d6496d5bcbb8526e274c4239844be0 > > -- > > > If changes to ISA code aren't welcomed, should these be marked obsolete > > > in the MAINTIANERS file? > > > > I think so, but think that "Odd Fixes" better describes that Rafael wrote. > > -- > Sorry about that! but does checkpatch tell people not to send patches if it's > 'Odd fixes'? I don't think so, but people should check MAINTIANERS file before they send patches and it has an explanation what "Odd fixes" means. > Should I wait for the maintainer's reply before doing anything else? Yes, please > > > > > > > > Thanks, > > > Anupama ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] MAINTAINERS: mark isapnp as obsolete
On Wed, Apr 28, 2021 at 05:10:57PM +0530, Anupama K Patil wrote: > On 21/04/28 01:11PM, Greg KH wrote: > > On Wed, Apr 28, 2021 at 04:35:36PM +0530, Anupama K Patil wrote: > > > isapnp code is very old and according to this link > > > https://en.wikipedia.org/wiki/Legacy_Plug_and_Play#Specifications > > > from Wikipedia, even Windows Vista disabled ISA PnP by default. > > > > > > This change is in follow up to > > > https://lore.kernel.org/lkml/20210422180322.7wlyg63kv3n2k6id@ubuntu/T/#u > > > and > > > https://lore.kernel.org/lkml/20210424194301.jmsqpycvsm7izbk3@ubuntu/T/#u > > > > > > Suggested-by: B K Karthik > > > Signed-off-by: Anupama K Patil > > > > Has the maintainer said this is unsupported? > > > > That's who you should take suggestions from :) > > > > thanks, > > > > greg k-h > > Leon said he thinks it is unsupported (I've also cc'd him). So, I've sent > this patch > to get the feedback from the maintainer. Leon said something different. https://lore.kernel.org/lkml/20210422180322.7wlyg63kv3n2k6id@ubuntu/T/#m6c837180c8d6496d5bcbb8526e274c4239844be0 -- > If changes to ISA code aren't welcomed, should these be marked obsolete in > the MAINTIANERS file? I think so, but think that "Odd Fixes" better describes that Rafael wrote. -- > > Thanks, > Anupama ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] drivers: pnp: proc.c: Handle errors while attaching devices
On Mon, Apr 26, 2021 at 11:20:32PM +0530, bkkarthik wrote:
> On 21/04/26 08:04AM, Leon Romanovsky wrote:
> > On Sun, Apr 25, 2021 at 01:13:01AM +0530, Anupama K Patil wrote:
> > > isapnp_proc_init() does not look at the return value from
> > > isapnp_proc_attach_device(). Check for this return value in
> > > isapnp_proc_detach_device().
> > >
> > > Cleanup in isapnp_proc_detach_device and
> > > isapnp_proc_detach_bus() for cleanup.
> > >
> > > Changed sprintf() to the kernel-space function scnprintf() as it returns
> > > the actual number of bytes written.
> > >
> > > Removed unnecessary variables de, e of type 'struct proc_dir_entry' to
> > > save memory.
<...>
> > > +static int isapnp_proc_detach_device(struct pnp_dev *dev)
> > > +{
> > > + proc_remove(dev->procent);
> > > + dev->procent = NULL;
> > > + return 0;
> > > +}
> > > +
> > > +static int isapnp_proc_detach_bus(struct pnp_card *bus)
> > > +{
> > > + proc_remove(bus->procdir);
> > > + return 0;
> > > +}
> >
> > Please don't add one line functions that are called only once and have
> > return value that no one care about it.
>
> These were only intended for a clean-up job, the idea of this function came
> from how PCI handles procfs.
> Maybe those should be changed?
Probably, the CONFIG_PROC_FS around pci_proc_*() is not needed too.
Thanks
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] drivers: pnp: proc.c: Removed unnecessary varibles
On Mon, Apr 26, 2021 at 11:22:54PM +0530, bkkarthik wrote: > On 21/04/26 03:50PM, Leon Romanovsky wrote: > > On Mon, Apr 26, 2021 at 02:00:58PM +0200, Rafael J. Wysocki wrote: > > > On Mon, Apr 26, 2021 at 6:57 AM Leon Romanovsky wrote: > > > > > > > > On Fri, Apr 23, 2021 at 03:08:03PM -0600, Shuah Khan wrote: > > > > > On 4/22/21 12:03 PM, Anupama K Patil wrote: > > > > > > de, e are two variables of the type 'struct proc_dir_entry' > > > > > > which can be removed to save memory. This also fixes a coding style > > > > > > issue reported by checkpatch where we are suggested to make > > > > > > assignment > > > > > > outside the if statement. > > > > > > > > > > > > > > > > Sounds like a reasonable change. > > > > > > > > It is unclear how much changes to ISA code are welcomed. > > If changes to ISA code aren't welcomed, should these be marked obsolete in > the MAINTIANERS file? I think so, but think that "Odd Fixes" better describes that Rafael wrote. Thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] drivers: pnp: proc.c: Removed unnecessary varibles
On Mon, Apr 26, 2021 at 02:00:58PM +0200, Rafael J. Wysocki wrote: > On Mon, Apr 26, 2021 at 6:57 AM Leon Romanovsky wrote: > > > > On Fri, Apr 23, 2021 at 03:08:03PM -0600, Shuah Khan wrote: > > > On 4/22/21 12:03 PM, Anupama K Patil wrote: > > > > de, e are two variables of the type 'struct proc_dir_entry' > > > > which can be removed to save memory. This also fixes a coding style > > > > issue reported by checkpatch where we are suggested to make assignment > > > > outside the if statement. > > > > > > > > > > Sounds like a reasonable change. > > > > It is unclear how much changes to ISA code are welcomed. > > Real fixes and obvious cleanups are, not much more than that. While first part is easy to determine, the second one is more blurry. > > > According to the Wikipedia, even Windows Vista disabled ISA PnP by default. > > https://en.wikipedia.org/wiki/Legacy_Plug_and_Play#Specifications > > It is indeed unclear how many systems with this interface still run > Linux, but as long as the code is in the tree, there's nothing wrong > with attempting to improve it. There's no assurance that all such > patches will be applied, though. > > Thanks! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] drivers: pnp: proc.c: Handle errors while attaching devices
On Sun, Apr 25, 2021 at 01:13:01AM +0530, Anupama K Patil wrote:
> isapnp_proc_init() does not look at the return value from
> isapnp_proc_attach_device(). Check for this return value in
> isapnp_proc_detach_device().
>
> Cleanup in isapnp_proc_detach_device and
> isapnp_proc_detach_bus() for cleanup.
>
> Changed sprintf() to the kernel-space function scnprintf() as it returns
> the actual number of bytes written.
>
> Removed unnecessary variables de, e of type 'struct proc_dir_entry' to
> save memory.
What exactly do you fix for such an old code?
>
> Suggested-by: Shuah Khan
> Co-developed-by: B K Karthik
> Signed-off-by: B K Karthik
> Signed-off-by: Anupama K Patil
> ---
> drivers/pnp/isapnp/proc.c | 40 +--
> 1 file changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pnp/isapnp/proc.c b/drivers/pnp/isapnp/proc.c
> index 785a796430fa..46ebc24175b7 100644
> --- a/drivers/pnp/isapnp/proc.c
> +++ b/drivers/pnp/isapnp/proc.c
> @@ -54,34 +54,54 @@ static const struct proc_ops isapnp_proc_bus_proc_ops = {
> .proc_read = isapnp_proc_bus_read,
> };
>
> +static int isapnp_proc_detach_device(struct pnp_dev *dev)
> +{
> + proc_remove(dev->procent);
> + dev->procent = NULL;
> + return 0;
> +}
> +
> +static int isapnp_proc_detach_bus(struct pnp_card *bus)
> +{
> + proc_remove(bus->procdir);
> + return 0;
> +}
Please don't add one line functions that are called only once and have
return value that no one care about it.
Thanks
> +
> static int isapnp_proc_attach_device(struct pnp_dev *dev)
> {
> struct pnp_card *bus = dev->card;
> - struct proc_dir_entry *de, *e;
> char name[16];
>
> - if (!(de = bus->procdir)) {
> - sprintf(name, "%02x", bus->number);
> - de = bus->procdir = proc_mkdir(name, isapnp_proc_bus_dir);
> - if (!de)
> + if (!bus->procdir) {
> + scnprintf(name, 16, "%02x", bus->number);
> + bus->procdir = proc_mkdir(name, isapnp_proc_bus_dir);
> + if (!bus->procdir)
> return -ENOMEM;
> }
> - sprintf(name, "%02x", dev->number);
> - e = dev->procent = proc_create_data(name, S_IFREG | S_IRUGO, de,
> + scnprintf(name, 16, "%02x", dev->number);
> + dev->procent = proc_create_data(name, S_IFREG | S_IRUGO, bus->procdir,
> _proc_bus_proc_ops, dev);
> - if (!e)
> + if (!dev->procent) {
> + isapnp_proc_detach_bus(bus);
> return -ENOMEM;
> - proc_set_size(e, 256);
> + }
> + proc_set_size(dev->procent, 256);
> return 0;
> }
>
> int __init isapnp_proc_init(void)
> {
> struct pnp_dev *dev;
> + int dev_attach;
>
> isapnp_proc_bus_dir = proc_mkdir("bus/isapnp", NULL);
> protocol_for_each_dev(_protocol, dev) {
> - isapnp_proc_attach_device(dev);
> + dev_attach = isapnp_proc_attach_device(dev);
> + if (!dev_attach) {
> + pr_info("procfs: pnp: Unable to attach the device, not
> enough memory");
> + isapnp_proc_detach_device(dev);
> + return -ENOMEM;
> + }
> }
> return 0;
> }
> --
> 2.25.1
>
> ___
> 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: [PATCH] drivers: pnp: proc.c: Removed unnecessary varibles
On Fri, Apr 23, 2021 at 03:08:03PM -0600, Shuah Khan wrote:
> On 4/22/21 12:03 PM, Anupama K Patil wrote:
> > de, e are two variables of the type 'struct proc_dir_entry'
> > which can be removed to save memory. This also fixes a coding style
> > issue reported by checkpatch where we are suggested to make assignment
> > outside the if statement.
> >
>
> Sounds like a reasonable change.
It is unclear how much changes to ISA code are welcomed.
According to the Wikipedia, even Windows Vista disabled ISA PnP by default.
https://en.wikipedia.org/wiki/Legacy_Plug_and_Play#Specifications
>
> > Signed-off-by: Anupama K Patil
> > ---
> > drivers/pnp/isapnp/proc.c | 13 ++---
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/pnp/isapnp/proc.c b/drivers/pnp/isapnp/proc.c
> > index 785a796430fa..1ae458c02656 100644
> > --- a/drivers/pnp/isapnp/proc.c
> > +++ b/drivers/pnp/isapnp/proc.c
> > @@ -57,21 +57,20 @@ static const struct proc_ops isapnp_proc_bus_proc_ops =
> > {
> > static int isapnp_proc_attach_device(struct pnp_dev *dev)
> > {
> > struct pnp_card *bus = dev->card;
> > - struct proc_dir_entry *de, *e;
> > char name[16];
> > - if (!(de = bus->procdir)) {
> > + if (!bus->procdir) {
> > sprintf(name, "%02x", bus->number);
>
> It would make sense to change this to scnprintf()
>
> > - de = bus->procdir = proc_mkdir(name, isapnp_proc_bus_dir);
> > - if (!de)
> > + bus->procdir = proc_mkdir(name, isapnp_proc_bus_dir);
> > + if (!bus->procdir)
> > return -ENOMEM;
> > }
> > sprintf(name, "%02x", dev->number);
>
> It would make sense to change this to scnprintf()
>
> > - e = dev->procent = proc_create_data(name, S_IFREG | S_IRUGO, de,
> > + dev->procent = proc_create_data(name, S_IFREG | S_IRUGO, bus->procdir,
> > _proc_bus_proc_ops, dev);
> > - if (!e)
> > + if (!dev->procent)
> > return -ENOMEM;
>
> Shouldn't the procdir be deleted when proc_create_data() fails?
It needs but only if proc_mkdir() was called in this function.
Thanks
>
> > - proc_set_size(e, 256);
> > + proc_set_size(dev->procent, 256);
> > return 0;
> > }
> >
>
> Note that isapnp_proc_init() doesn't check isapnp_proc_attach_device()
> return and handle errors and cleanup.
>
> thanks,
> -- Shuah
>
>
>
> ___
> 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: Confused about which branch to patch against
On Tue, Sep 22, 2020 at 09:39:41PM -0500, Gustavo A. R. Silva wrote: > Hi, > > On 9/22/20 21:08, James Browning wrote: > > Hi all, > > > > After reading through the kernel documentation about submitting pathces, > > and reading through the kernel newbies guide to submitting patches, I > > still have some confusion. > > > > Should I be doing all of my patching against linux-next as opposed to > > the mainline tree? I tried submitting a patch to some typos I found on > > the mainline tree, but they were rejected because they had already been > > fixed in linux-next. > > Yes; bleeding edge development happens in linux-next. Just notice that > there is a new linux-next everyday. This is, linux-next is merely a daily > merge of all the individual development '-next' trees. > > Don't get discouraged if your patches are not applied because someone > else already sent a patch to fix the same issue. That certainly happens > every now and then. > > I suggest you to start your journey by addressing issues in staging, first. > Especially, typos and coding style issues. Also, this is a great resource: > > https://kernelnewbies.org/Outreachyfirstpatch > > Read it thoroughly. :) > > > I guess I dont really understand what patches become part of the next > > mainline rc-x tree, and which patches become part of linux-next (which > > from what I understand, doesn't get merged until the next merge window when > > the current kernel version is finished being stabalized). > > I encourage you to enroll in this course: > > https://training.linuxfoundation.org/training/a-beginners-guide-to-linux-kernel-development-lfd103/ > > It's free and there is a section in the beginning that explains all > about the differences between mainline, -rc, linux-next and stable > trees and how they relate to each other. > > > Also, if I patch something in the linux-next tree, do I need to specify > > which tree it is when I send the patch the maintainers? > > Not necessarily. However, some people explicitly ask you to add 'next' to the > subject line. The networking people, in particular. > > In any case, you'll be safe by adding [next] to the subject line, as follows: > > [PATCH][next] subject IMHO it looks clumsy, why don't [PATCH -next]? > > and the maintainers will know that's for their -next tree. Just make sure you > CC all the file maintainers. > > I hope this helps. > > -- > Gustavo > > ___ > 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: Divide Error: 0000 [#1] SMP
On Sun, Jun 14, 2015 at 2:28 PM, Sioban sio...@sioban.net wrote: Hello, I have a problem with my server, it's several times I got Divide Error: [#1] SMP. I expect that patch [PATCH block/for-4.1-fixes] writeback: use |1 instead of +1 to protect against div by zero [1] will fix your issue. It is for 4.1 kernel. [1] https://lkml.org/lkml/2015/4/21/797 -- Leon Romanovsky | Independent Linux Consultant www.leon.nu | l...@leon.nu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question on checpatch.pl warning -- possible unnecessary 'out of memory' message.
Hi Bas, All instances of this warning refer to usage of alloc_skb using the GFP_ATOMIC flag. Why does checkpatch show this warning? Is it not good practice to _always_ check whether allocation succeeded or not? I hope someone can explain the nature of this warning and, if right, what it should look like. I suggest you to take a look at the following thread https://lkml.org/lkml/2014/6/10/382 As a short summary to that discussion: 1. You should check the NULL pointer. 2. You shouldn't print the error. With kind regards, Bas Peters ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Leon Romanovsky | Independent Linux Consultant www.leon.nu | l...@leon.nu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Page fault in kernel code
On Wed, Sep 10, 2014 at 5:52 PM, Manavendra Nath Manav mnm.ker...@gmail.com wrote: On 10-Sep-2014 6:24 pm, valdis.kletni...@vt.edu wrote: On Wed, 10 Sep 2014 14:45:23 +0530, Manavendra Nath Manav said: But if the total RAM is limited (less than 896MB LOWMEM), for example as in embedded devices how the kernel code be kept in RAM all the time. Am I correct to assume that the kernel pre-fetches all pages when entering kernel mode from user mode? No, kernel code is loaded by your boot loader, and *it stays there*. Similarly, if you modprobe something, the kernel allocates the page, loads the code, and leaves it there. Particularly in embedded devices, where you know all the modules the kernel may need, it's common to just create a kernel with everything built in, no module support, and when the system boots, it loads into memory and never moves again. Linux kernel memory is not page-able, but memory allocated through vmalloc can still cause page fault. How device drivers using vmalloc handle this? Pages allocated via vmalloc call won't generate page-faults. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Leon Romanovsky | Independent Linux Consultant www.leon.nu | l...@leon.nu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Invitation to connect on LinkedIn
On Tue, Apr 16, 2013 at 11:14 PM, rush deb...@irush.su wrote: Is it normal that somebody uses this kernelnewbies e-mail as its private address? I believe he answered YES for the linkedin proposal if it can send email to whole address book. @Deepak, if you're reading this, please could you change settings in linkedin? 17.04.2013, 00:10, Kumar Sukhani via LinkedIn mem...@linkedin.com: Deepak, Kumar Sukhani wants to connect with you on LinkedIn. Kumar Sukhani System Developer at Dreamz group View Profile » Accept You are receiving Invitation emails. Unsubscribe. This email was intended for Deepak Shah (Software Engineer at Barracuda Networks). Learn why we included this. © 2013, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA , ___ 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 -- Leon Romanovsky | Independent Linux Consultant www.leon.nu | l...@leon.nu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
