Another thing that could be done is to move the parsing function outside the ISR...
That is the recommended method and the "party line" on this forum. I don't necessarily follow the party line because all situations are different and it can make sense to have a lot of code in an ISR, after all if there is nothing else to do why not?
Maybe you should look at your timing to see if it's worth the risk of enabling nested interrupts, if the data is coming in at 300 baud you have about a week and a half to parse the packet before the next character comes in anyway.
I have to say though that in this case I will follow the party line, I think the ISR should just add chars to a FIFO and the main code should take chars from that FIFO and parse as required. That is a simple and compartmentalised interface.
What about noblock and Priority handling?
I've never heard of noblock so can't comment on that. The priority of interrupts is as per their order shown in the data sheet, and as I said before if you enable interrupts in the ISR then they will be handled, but if you are both adding and removing bytes from a FIFO you have to be very careful about all non-atomic instructions that deal with global elements of the FIFO, head and tail pointers are probably OK in themselves but any operations that use both have to be protected and as do things like counters that hold the number of bytes in the FIFO.
As for malloc(), are all the blocks the same size? If so why not just have an array of arrays for the data? If not how will you free the blocks without getting fragmentation?
If you have a FIFO of pointers to arrays there is no need to move data around at all, in general you try to avoid physically moving bytes, it's better to change a pointer.
Rob