When to use smart pointers?

I find my code is full of shared_ptrs and weak_ptrs, i literally use NO raw pointers, and i find myself in doubt: Is this good practice?
I've googled this abit, and i see some people swearing by smart-pointers everywhere, while others take a more subtle approach.
In the current iteration of my resourcemanager i create all my resources and then store shared_ptrs in a container, this makes sense ofcourse.

But what if i need my game-entities to have access to their parent game state: I can't pass a shared_ptr because that would give me a circular reference (the gamestate manages all entities with shared_ptrs i should say.), atm i'm just passing a weak_ptr and then lock()'ing it when i need to access the gamestate. Is this overkill, should i just use a raw pointer?

I'm concerned with the fact that the above approach means alot of temporaty shared_ptrs are created and destroyed each frame, how big is the overhead?

Some people seem to think that shared_ptr to some object, denounces "ownership" of that object, and that shared_ptrs should only be passed around when the intention is to change ownership of the object pointed to?

Also, will i be burned at the stake for typedefing the pointers? My code looks like a cross-section of times square at midnight with all the ugly template syntax.

Edit:

I felt so dirty when i put together the constructor for my rendercomponent:

Code:

---

RenderComponent(const std::string &p_PropertyName, boost::weak_ptr<Entity> p_Owner) : Component(p_PropertyName, p_Owner), m_Target(p_Owner.lock()->GetGameState().lock()->GetWindow())

---

I'm not even sure the above code isn't causing leaks or other nasty stuff, but it works, i just can't stand looking at it :-)

I don't recall any other performance-critical solutions besides storing a raw pointer, however, when I come across circular references and have to use weak pointers to break cyclic references, I have a quick look at the code and check whether I can perform the same operation the other way (by processing parent first, then child).
Also, when the constructor is going to lock the pointer, it should take a strong pointer, perform necessary operations, and then store it as a weak one. This avoids the unnecessary conversion: strong -> weak -> strong (assuming passing strong pointer is more frequent). Whenever you are forced to lock a weak pointer and use it more than one time, you should obviously use a local copy of shared_ptr.