Re: doubt about interrupts and spinlocks

[anish singh]

inline answers.

On Fri, Oct 24, 2014 at 8:04 AM, Oscar Salvador <
osalvador.vilard...@gmail.com> wrote:

> Hi!
>
> I have a doubt about interrupts and spin locks.
> I'm not sure if I'm in the good way:
>
> When an interrupt is raised, the kernel (through do_IRQ and etc)
> acknowledges the interrupt and locks this IRQ taking a spin lock, so any
> other cpu can not handle this interrupt, and then the kernel executes the
> handler, if there is a handler available for that interrupt.
>
> When we are on the handler interrupt , maybe we need to lock the cpu till
> we finish( if we are in a network driver, may we need to process some TX/RX
> packets ),
> so if we have to lock the code we can do a spin_lock().
> But with a spin_lock, even other CPU's can execute part of your code(code
> that is not part of the handler interrupt).
> For example:
>
> (this is an example in a network device driver)
> The system has to transmit a packet, so network subsystem calls
> ndo_start_xmit. Inside this function we take a lock disabling the
> interrupts(spin_lock_irqsave) because we have to do some private things,
> but suddenly an interrupt is raised and we go to the interrupt handler, we
> take a spin_lock, we do some work (processing some RX/TX packets), and
> exites from the interrupt handler, and then we come back to the
> ndo_start_xmit when we were.
>
> As far I could understand( I have read
> http://www.makelinux.net/ldd3/chp-5-sect-5 ), spin_lock_irqsave only
> disables the interrupts for the local cpu(where the code is executed),
> so I think that another cpu took the handler interrupt.
>
Yes this can happen and if you expect that the interrupt can come in other
CPU then you should handle that as well.
Generally interrupts are disabled so you won't get any interrupt on other
CPU if any cpu is currently handling the interrupt.
However your explained sceneraio happens for network packets and that is
why kernel uses  softirq mechanism for network
packets. Read about softirq.

> The problem is if I'm working with irq disabled, because I have to handle
> a private structure and suddenly interrupts is taking place, the interrupt
> can manipulate the code that I'm trying to keep safe.
> Is there any advice? Maybe that is happened because the code within my
> critical section on ndo_start_xmit has to be atomic? Otherwise it can go to
> sleep and I can lose my lock?
>
Your question is not quite coherent.

>
> Thank you very much
> Oscar Salvador
>
> ___
> 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: sendmmsg() Expected Behavior?

[Valdis . Kletnieks]

On Thu, 23 Oct 2014 23:41:41 -0400, valdis.kletni...@vt.edu said:

> Why were you expecting recvmsg() to return more than one message?

Bah. Ignore that.  you said recvmmsg() with *two* m's.


pgpYuxOQ9HTPG.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: doubt about interrupts and spinlocks

[Dave Tian]

If you are talking about the same spin_lock, once it is locked, it is locked. 
Others (even from other CPUs) have to ‘spin' util the lock is freed.

-daveti


> On Oct 24, 2014, at 11:04 PM, Oscar Salvador  
> wrote:
> 
> Hi!
> 
> I have a doubt about interrupts and spin locks.
> I'm not sure if I'm in the good way:
> 
> When an interrupt is raised, the kernel (through do_IRQ and etc) acknowledges 
> the interrupt and locks this IRQ taking a spin lock, so any other cpu can not 
> handle this interrupt, and then the kernel executes the handler, if there is 
> a handler available for that interrupt.
> 
> When we are on the handler interrupt , maybe we need to lock the cpu till we 
> finish( if we are in a network driver, may we need to process some TX/RX 
> packets ), 
> so if we have to lock the code we can do a spin_lock().
> But with a spin_lock, even other CPU's can execute part of your code(code 
> that is not part of the handler interrupt). 
> For example:
> 
> (this is an example in a network device driver)
> The system has to transmit a packet, so network subsystem calls 
> ndo_start_xmit. Inside this function we take a lock disabling the 
> interrupts(spin_lock_irqsave) because we have to do some private things, but 
> suddenly an interrupt is raised and we go to the interrupt handler, we take a 
> spin_lock, we do some work (processing some RX/TX packets), and exites from 
> the interrupt handler, and then we come back to the ndo_start_xmit when we 
> were.
> 
> As far I could understand( I have read 
> http://www.makelinux.net/ldd3/chp-5-sect-5 
>  ), spin_lock_irqsave only 
> disables the interrupts for the local cpu(where the code is executed), 
> so I think that another cpu took the handler interrupt.
> The problem is if I'm working with irq disabled, because I have to handle a 
> private structure and suddenly interrupts is taking place, the interrupt can 
> manipulate the code that I'm trying to keep safe.
> Is there any advice? Maybe that is happened because the code within my 
> critical section on ndo_start_xmit has to be atomic? Otherwise it can go to 
> sleep and I can lose my lock?
> 
> Thank you very much
> Oscar Salvador
> ___
> 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

doubt about interrupts and spinlocks

[Oscar Salvador]

Hi!

I have a doubt about interrupts and spin locks.
I'm not sure if I'm in the good way:

When an interrupt is raised, the kernel (through do_IRQ and etc)
acknowledges the interrupt and locks this IRQ taking a spin lock, so any
other cpu can not handle this interrupt, and then the kernel executes the
handler, if there is a handler available for that interrupt.

When we are on the handler interrupt , maybe we need to lock the cpu till
we finish( if we are in a network driver, may we need to process some TX/RX
packets ),
so if we have to lock the code we can do a spin_lock().
But with a spin_lock, even other CPU's can execute part of your code(code
that is not part of the handler interrupt).
For example:

(this is an example in a network device driver)
The system has to transmit a packet, so network subsystem calls
ndo_start_xmit. Inside this function we take a lock disabling the
interrupts(spin_lock_irqsave) because we have to do some private things,
but suddenly an interrupt is raised and we go to the interrupt handler, we
take a spin_lock, we do some work (processing some RX/TX packets), and
exites from the interrupt handler, and then we come back to the
ndo_start_xmit when we were.

As far I could understand( I have read
http://www.makelinux.net/ldd3/chp-5-sect-5 ), spin_lock_irqsave only
disables the interrupts for the local cpu(where the code is executed),
so I think that another cpu took the handler interrupt.
The problem is if I'm working with irq disabled, because I have to handle a
private structure and suddenly interrupts is taking place, the interrupt
can manipulate the code that I'm trying to keep safe.
Is there any advice? Maybe that is happened because the code within my
critical section on ndo_start_xmit has to be atomic? Otherwise it can go to
sleep and I can lose my lock?

Thank you very much
Oscar Salvador
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Documentation/DMA-API-HOWTO.txt 2

[Valdis . Kletnieks]

On Fri, 24 Oct 2014 15:09:45 +0200, Peter Senna Tschudin said:
> This was edited in 2010, but the original is more than 9 years old,
> and still there are some drivers using virt_to_bus() and
> bus_to_virt().
>
> -- // --
> All drivers should be using these interfaces with no exceptions.  It
> is planned to completely remove virt_to_bus() and bus_to_virt() as
> they are entirely deprecated.  Some ports already do not provide these
> as it is impossible to correctly support them.
> -- // --
>
> Files calling virt_to_bus:
> ./drivers/atm/ambassador.c
> ./drivers/atm/firestream.c
> ./drivers/atm/horizon.c
> ./drivers/atm/zatm.c
> ./drivers/block/swim3.c
> ./drivers/isdn/hisax/netjet.c
> ./drivers/media/pci/zoran/zoran_device.c
> ./drivers/media/pci/zoran/zoran_driver.c
> ./drivers/net/appletalk/ltpc.c
> ./drivers/net/ethernet/amd/au1000_eth.c
> ./drivers/net/ethernet/apple/bmac.c
> ./drivers/net/ethernet/apple/mace.c
> ./drivers/net/ethernet/dec/tulip/de4x5.c
> ./drivers/net/ethernet/i825xx/82596.c
> ./drivers/net/ethernet/sgi/ioc3-eth.c
> ./drivers/net/irda/au1k_ir.c
> ./drivers/net/irda/donauboe.c
> ./drivers/net/wan/cosa.c
> ./drivers/net/wan/lmc/lmc_main.c
> ./drivers/net/wan/z85230.c
> ./drivers/scsi/a2091.c
> ./drivers/scsi/a3000.c
> ./drivers/scsi/advansys.c
> ./drivers/scsi/gvp11.c
> ./drivers/scsi/mvme147.c
> ./drivers/staging/comedi/drivers/das1800.c
> ./drivers/staging/comedi/drivers/dt282x.c
> ./drivers/staging/comedi/drivers/ni_at_a2150.c
> ./drivers/staging/comedi/drivers/ni_labpc_isadma.c
> ./drivers/staging/comedi/drivers/pcl812.c
> ./drivers/staging/comedi/drivers/pcl816.c
> ./drivers/staging/comedi/drivers/pcl818.c
> ./drivers/staging/netlogic/xlr_net.c
> ./drivers/staging/slicoss/slicoss.c
> ./drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c
> ./drivers/vme/bridges/vme_ca91cx42.c
>
> Files calling bus_to_virt:
> ./drivers/atm/ambassador.c
> ./drivers/atm/firestream.c
> ./drivers/atm/horizon.c
> ./drivers/atm/zatm.c
> ./drivers/isdn/hisax/netjet.c
> ./drivers/media/pci/zoran/zoran_driver.c
> ./drivers/net/ethernet/apple/bmac.c
> ./drivers/net/ethernet/apple/mace.c
> ./drivers/scsi/BusLogic.c
> ./drivers/scsi/dpt_i2o.c
> ./drivers/staging/netlogic/xlr_net.c
>
> Should the 'with no exceptions' be enforced?

Feel free to create patches. :) (I'd contribute some myself if I had
any of the hardware to test against)



pgpjmXZExZ9O_.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Documentation/DMA-API-HOWTO.txt 2

[Peter Senna Tschudin]

This was edited in 2010, but the original is more than 9 years old,
and still there are some drivers using virt_to_bus() and
bus_to_virt().

-- // --
All drivers should be using these interfaces with no exceptions.  It
is planned to completely remove virt_to_bus() and bus_to_virt() as
they are entirely deprecated.  Some ports already do not provide these
as it is impossible to correctly support them.
-- // --

Files calling virt_to_bus:
./drivers/atm/ambassador.c
./drivers/atm/firestream.c
./drivers/atm/horizon.c
./drivers/atm/zatm.c
./drivers/block/swim3.c
./drivers/isdn/hisax/netjet.c
./drivers/media/pci/zoran/zoran_device.c
./drivers/media/pci/zoran/zoran_driver.c
./drivers/net/appletalk/ltpc.c
./drivers/net/ethernet/amd/au1000_eth.c
./drivers/net/ethernet/apple/bmac.c
./drivers/net/ethernet/apple/mace.c
./drivers/net/ethernet/dec/tulip/de4x5.c
./drivers/net/ethernet/i825xx/82596.c
./drivers/net/ethernet/sgi/ioc3-eth.c
./drivers/net/irda/au1k_ir.c
./drivers/net/irda/donauboe.c
./drivers/net/wan/cosa.c
./drivers/net/wan/lmc/lmc_main.c
./drivers/net/wan/z85230.c
./drivers/scsi/a2091.c
./drivers/scsi/a3000.c
./drivers/scsi/advansys.c
./drivers/scsi/gvp11.c
./drivers/scsi/mvme147.c
./drivers/staging/comedi/drivers/das1800.c
./drivers/staging/comedi/drivers/dt282x.c
./drivers/staging/comedi/drivers/ni_at_a2150.c
./drivers/staging/comedi/drivers/ni_labpc_isadma.c
./drivers/staging/comedi/drivers/pcl812.c
./drivers/staging/comedi/drivers/pcl816.c
./drivers/staging/comedi/drivers/pcl818.c
./drivers/staging/netlogic/xlr_net.c
./drivers/staging/slicoss/slicoss.c
./drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c
./drivers/vme/bridges/vme_ca91cx42.c

Files calling bus_to_virt:
./drivers/atm/ambassador.c
./drivers/atm/firestream.c
./drivers/atm/horizon.c
./drivers/atm/zatm.c
./drivers/isdn/hisax/netjet.c
./drivers/media/pci/zoran/zoran_driver.c
./drivers/net/ethernet/apple/bmac.c
./drivers/net/ethernet/apple/mace.c
./drivers/scsi/BusLogic.c
./drivers/scsi/dpt_i2o.c
./drivers/staging/netlogic/xlr_net.c

Should the 'with no exceptions' be enforced?

-- 
Peter

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Documentation/DMA-API-HOWTO.txt

[Peter Senna Tschudin]

There is a portion of DMA-API-HOWTO.txt that was not updated for a long time.

-- // --
This means specifically that you may _not_ use the memory/addresses
returned from vmalloc() for DMA.  It is possible to DMA to the
_underlying_ memory mapped into a vmalloc() area, but this requires
walking page tables to get the physical addresses, and then
translating each of those pages back to a kernel address using
something like __va().  [ EDIT: Update this when we integrate
Gerd Knorr's generic code which does this. ]
-- // --

Was Gerd Knorr's generic code integrated?



-- 
Peter

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies